[Question] iptables connlimit và ip_vs |
11/06/2009 12:51:42 (+0700) | #1 | 183237 |
mình đang setup một hệ thống web cân bằng tải dựa trên ip_vs nhưng hiện tại đang gặp vấn đề khi sử dụng conlimit với iptables trên ip_vs server.
Code:
-A INPUT -i lo -j ACCEPT
iptables -A INPUT -i eth1 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type any -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# vì là trang ajax và multimedia nhiều nên limit là 24 ##
iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -m connlimit ! --connlimit-above 24 -j ACCEPT
iptables -A INPUT -j REJECT --reject-with icmp-net-prohibited
và cấu hình ip_vs như sau
Code:
Prot LocalAddressort Scheduler Flags
-> RemoteAddressort Forward Weight ActiveConn InActConn
TCP 192.168.1.112:80 wlc
-> 192.168.2.21:80 Masq 1 1 2
-> 192.168.2.22:80 Masq 0 0 0
1/ Khi dùng một số chương trình để benmark để tạo nhiều connection đến server thì không thấy iptables limit gì cả. Có phải vì kết nối ko thiết lập đến chính 192.168.1.112 mà được chuyển qua máy khác nên connlimit không "đếm" được hay không? liệu có cách nào để limit trên ip_vs server hay không?.
Hiện tại mình chạy iptables trên các máy nhận request thì thấy limit tốt.
2/ Sau khi limit trên các máy nhận request ( 2.21 và 2.22) mình thử dùng trình duyệt để kết nối thì thấy bình thường nhưng khi nhiều người ( nằm sau một proxy) duyệt thì cảm thấy rất chậm và hay bị lỗi. Khi đọc ký sự về HVA mình cũng đã thử cố phân tích và tính toán thì cảm thấy con số 24 connection là quá hợp lý nhưng tại sao kết quả lại không như ý muốn. nhưng trong các bài viết của bác conmale lý luận rằng nếu trình duyệt bị từ chối thì nó sẽ retry lại ngay. vậy thì với phản ứng nào của iptables thì trình duyệt sẽ retry ( REJECT VS DROP ), liệu dùng drop ( ở local webserver) thìconnection có bị hold ở ip_vs quá lâu không.
ngoài ra mình mở netstat của các máy webserver ra thì thấy rất nhiều connection ở trạng thái TIME_WAIT và FIN_WAIT, có cách nào để giảm bớt thời gian WAIT này ko?
Code:
REJECT
--reject-with type
The type given can be
icmp-net-unreachable
icmp-host-unreachable
icmp-port-unreachable
icmp-proto-unreachable
icmp-net-prohibited
icmp-host-prohibited or
icmp-admin-prohibited (*)
which return the appropriate ICMP error message (port-unreach-
able is the default). The option tcp-reset can be used on rules
which only match the TCP protocol: this causes a TCP RST packet
to be sent back. This is mainly useful for blocking ident
(113/tcp) probes which frequently occur when sending mail to
broken mail hosts (which won't accept your mail otherwise).
hay là DROP
Mong mọi người góp ý
|
|
|
|
|
[Question] iptables connlimit và ip_vs |
11/06/2009 14:10:45 (+0700) | #2 | 183242 |
mR.Bi
Member
|
0 |
|
|
Joined: 22/03/2006 13:17:49
Messages: 812
Offline
|
|
1. bạn dùng chương trình gì để benmark vậy? và bạn thiết lập các connection để benmark ra sao? vì cái rule của bạn chỉ đếm số tcp connections đi đến port 80 của server, nếu số request mà dưới 24 thì cho vào, lỡ như cái app bạn dùng đó nó tạo request đến cổng khác thì sao?
mà cái rule ấy sao không set --connlimit-above 24 -j DROP mà thêm ! để accept mình thấy nó hơi...lủng củng .
2.
a. nếu bạn dùng DROP, thì có nghĩa gói tin bị loại bỏ ngay tức khắc. lúc này client sẽ nghĩ rằng gói tin bị mất vì lí do nào đó không đến được server và tiếp tục gởi SYN packet cho đến khi timeout. Những SYN packets này gửi đi nếu may mắn thì nhận được trả lời, nếu không may mắn thì bị DROP tiếp.
b. nếu bạn dùng REJECt-with type ( theo mình nghĩ tcp-reset sẽ hợp lí nhất), thì gói tin bị loại bỏ kèm theo một error packet gửi về cho client "thông báo lí do", vì có gói tin trả lời từ server của bạn cho nên client biết rằng server "vẫn còn sống", và cố gắng kết nối lần nữa, sẽ nhanh hơn trường hợp a
tuy nhiên nếu dùng REJECT, trong trường hợp bị tấn công xối xả thì server sẽ tốn rất nhiều resource để trả lời cho mỗi gói tin bị DROP, không cần thiết mà còn mau die .
vậy câu trả lời của mình là..tùy tình huống.
Edit:có sửa đổi một vài chỗ |
|
All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children" |
|
|
|
[Question] iptables connlimit và ip_vs |
11/06/2009 14:43:27 (+0700) | #3 | 183245 |
1. bạn dùng chương trình gì để benmark vậy? và bạn thiết lập các connection để benmark ra sao? vì cái rule của bạn chỉ đếm số tcp connections đi đến port 80 của server, nếu số request mà dưới 24 thì cho vào, lỡ như cái app bạn dùng đó nó tạo request đến cổng khác thì sao?
mà cái rule ấy sao không set --connlimit-above 24 -j DROP mà thêm ! để accept mình thấy nó hơi...lủng củng .
mình dùng một chương trình để tự DDOS của Socketsoft nó mở ra 1000 socket (connection) và request server liên tục, mình cũng đã thử limit xuống 1 nhưng cũng không có xi nhê zì ==> die webserver (với trường hợp đặt connlimit trên ip_vs)
mình ko rõ lắm về connection limit của bác comale là connection limit bằng cách cấu hình apache hay là sử dụng iptables nhưng như đoạn bài viết dưới đây trích từ ký sự các vụ DDOS của HVA thì mình tự hỏi trình duyệt sẽ tự retry với phản ứng nào của iptable và trường hợp nào giải phóng socket (qua ipvs server và cho webserver đằng sau ipvs) nhanh hơn.
Nếu như theo lập luận của bạn thì có lẽ DROP là trường hợp người dùng ít bị ảnh hưởng nhất???
Nếu như kế tiếp có người thứ 7, 8 và 9 cùng truy cập thì sao? Chắc chắn là thiếu 2 connection. Tuy nhiên, anh chàng nào hơi chậm chân một tí thì trình duyệt sẽ "retry" ngay sau đó và khi "retry" packet này đụng đến server thì cơ hội có connection để vào rất cao vì khi ấy người thứ 3, 4, 5, 6 đã trả lại một loạt connection rồi. Đối với người dùng bình thường, đây là một "delay" rất nhỏ và có thể tiếp nhận được. Trên thực tế, chuyện này hiếm xảy ra. Theo thông tin đã thâu thập được từ log của web server thì cứ 30 giây mới có một xuất truy cập mới. Quy định 8 connections một lúc cho mỗi IP thật sự còn quá thư giãn so với hoàn cảnh thực tế. Tuy nhiên, cứ tạm dùng con số này làm điểm khởi đầu rồi chỉnh sửa sau vậy.
|
|
|
|
|
[Question] iptables connlimit và ip_vs |
11/06/2009 17:54:34 (+0700) | #4 | 183248 |
|
conmale
Administrator
|
Joined: 07/05/2004 23:43:15
Messages: 9353
Location: down under
Offline
|
|
Bồ thử nghiệm connlimit cho các packet ở "state" là NEW và các packets này đi từ 1 IP?
Bồ nên xét xem một packet được xếp loại "NEW" trên netfilter thường tồn tại bao nhiêu lâu và bồ cần phải flood ở mức độ thế nào để đạt được chỉ số > 24 "NEW" connections (để từ đó connlimit của bồ mới có tác dụng).
Bồ cho biết cụ thể hơn cái topology của hệ thống cân bằng tải ấy.
Với trích đoạn bồ đưa ra ở trên (từ loạt ký sự), "connection" ở đây hoàn toàn trên tầng netfilter / iptables chớ không phải trên apache. |
|
What bringing us together is stronger than what pulling us apart. |
|
|
|
[Question] iptables connlimit và ip_vs |
11/06/2009 22:50:45 (+0700) | #5 | 183258 |
|
sup3rmm
Member
|
0 |
|
|
Joined: 17/08/2006 22:14:28
Messages: 21
Offline
|
|
ip_vs hoạt động như 1 NAT gateway vì vậy các packet vào ra hoàn toàn không đi qua chain INPUT của netfilter mod connlimit không thể hoạt động hiệu quả với topology hiện nay. Bạn thử nghiệm connlimit ở các chain trước INPUT xem sao, đọc kĩ mối liên hệ giữ ip_vs và netfilter, có gì post kết quả lên để mọi người tham khảo nha. Ngoài ra nếu traffic và các site của bạn không cao. Bạn có thể sử dụng giải pháp haproxy http://haproxy.1wt.eu/. Soft này có ứu điểm về performance( dĩ nhiên không bằng được LVS ), giúp tương tác với packet ở mức application dễ dàng cản lọc, phân luồng traffic web theo ý muốn và bạn hoàn toàn có thể áp dụng connlimit ở topology này |
|
|
[Question] iptables connlimit và ip_vs |
12/06/2009 16:00:46 (+0700) | #6 | 183328 |
Users currently in here |
1 Anonymous
|
|
Powered by JForum - Extended by HVAOnline
hvaonline.net | hvaforum.net | hvazone.net | hvanews.net | vnhacker.org
1999 - 2013 ©
v2012|0504|218|
|
|