Optymalizacja routera opartego o system Linux<\/p>\n
Ka\u017cdy admin pewnego dnia staje przed zadaniem optymalizacji regu\u0142 iptables celem ich optymalizacji. W moim przypadku problem pojawi\u0142 si\u0119 w momencie przekroczenia sumarycznego ruchu (do i z rutera) 360Mb\/s. W tym Momocie sumaryczna ilo\u015b\u0107 pakiet\u00f3w wzros\u0142a do 31.8 k.\/s.
\nEfekt by\u0142 taki, i\u017c zacz\u0119\u0142y si\u0119 chwilami gubi\u0107 pakiety, ponadto czas wczytywania stron www odczuwalnie si\u0119 wyd\u0142u\u017cy\u0142, pomimo faktu, i\u017c podczas \u015bci\u0105gania danych w sieciach p2p nadal dzia\u0142a\u0142y bez zak\u0142\u00f3ce\u0144. Pakiety ICMP coraz cz\u0119\u015bciej wypada\u0142y i\/lub ros\u0142y ich czasy, load average routera dochodzi\u0142 do 1,5.
\nW zwi\u0105zku z tym przyst\u0105pi\u0142em do optymalizacji regu\u0142ek iptables i innych drobnych zabieg\u00f3w, kilka z nich przedstawiam poni\u017cej.<\/p>\n
1.\tNa pocz\u0105tek dochodzimy do wniosku, w jakim celu filtrowa\u0107 po IP \u017ar\u00f3d\u0142owym po\u0142\u0105czenia, na kt\u00f3re klient ju\u017c wcze\u015bniej dosta\u0142 zezwolenie. Przecie\u017c to bezsensu! Skoro ju\u017c klient wys\u0142a\u0142 pakiet SYN kontrolowany na podstawie adresu IP oraz MAC i dosta\u0142 zezwolenie na po\u0142\u0105czenie, to dalsze pakiety mo\u017cemy spokojnie pu\u015bci\u0107 bez tej kontroli, testujemy tylko stan po\u0142\u0105czenia:<\/p>\n
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT<\/p>\n
2.\tNajbardziej popularne porty puszczamy szybciutko na pocz\u0105tku filtrowania, pozwoli to znacznie zwi\u0119kszy\u0107 pr\u0119dko\u015b\u0107 wczytywania danych, kto\u015b zapyta a co z adresami IP, kt\u00f3re maja blokad\u0119 dost\u0119pu do Internetu? O tym p\u00f3\u017aniej \ud83d\ude09<\/p>\n
iptables -A FORWARD -i eth1 -p tcp -m multiport –dports 25,80,110 -j ACCEPT<\/p>\n
3.\tPodobna sytuacja z pakietami UDP, gry on-line oraz telefonia internetowa znacznie przy\u015bpieszy.<\/p>\n
iptables -A FORWARD -i eth1 -p udp -j ACCEPT<\/p>\n
4.\tZmieniamy domy\u015blne warto\u015bci dla protoko\u0142u IPV4, po prostu przyspieszamy pewne operacje.<\/p>\n
echo 20 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_tcp_timeout_close
\necho 1800 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_tcp_timeout_established
\necho 30 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_tcp_timeout_syn_sent
\necho 60 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_tcp_timeout_close_wait
\necho 30 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_tcp_timeout_time_wait
\necho 10 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_udp_timeout
\necho 30 > \/proc\/sys\/net\/ipv4\/netfilter\/ip_conntrack_udp_timeout_stream<\/p>\n
5.\tPrzy tak skonstruowanych regu\u0142ach iptables klienci, kt\u00f3rzy, powinni mie\u0107 wyci\u0119ty ruch do Internetu bez problemu mog\u0105 korzysta\u0107 z www oraz poczty. Chc\u0105c ich zablokowa\u0107 nale\u017cy regu\u0142ki DROP da\u0107 na pocz\u0105tek, w efekcie pakiet autoryzowany musi pokona\u0107 regu\u0142ki blokad i dopiero trafia na swoje zezwalaj\u0105ce na dost\u0119p do Internetu. Powoduje to oczywiste op\u00f3\u017anienie. Dlatego te\u017c wycinanie klient\u00f3w realizowane b\u0119dzie na poziomie routingu a nie filtrowania pakiet\u00f3w. Kolejne tysi\u0105ce pakiet\u00f3w nie b\u0119d\u0105 musia\u0142y by\u0107 filtrowane:<\/p>\n
route add -host ip_hosta reject<\/p>\n
Po\u0142\u0105czenia z adresu ip_hosta nawet niedotrze do regu\u0142ek filtruj\u0105cych, chyba nie musz\u0119 m\u00f3wi\u0107 jak odpocznie nasz firewall.<\/p>\n
Par\u0119 prostych zabieg\u00f3w a Internet znowu zacz\u0105\u0142 u klient\u00f3w szale\u0107 a\u017c mi\u0142o, ponadto load average z 1,5 spad\u0142o do 0,05 czego \u017cycz\u0119 i Wam \ud83d\ude09<\/p>\n","protected":false},"excerpt":{"rendered":"
Optymalizacja routera opartego o system Linux Ka\u017cdy admin pewnego dnia staje przed zadaniem optymalizacji regu\u0142 iptables celem ich optymalizacji. W moim przypadku problem pojawi\u0142 si\u0119 w momencie przekroczenia sumarycznego ruchu (do i z rutera) 360Mb\/s. W tym Momocie sumaryczna ilo\u015b\u0107 pakiet\u00f3w wzros\u0142a do 31.8 k.\/s. Efekt by\u0142 taki, i\u017c zacz\u0119\u0142y si\u0119 chwilami gubi\u0107 pakiety, ponadto […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_et_pb_use_builder":"","_et_pb_old_content":"","_et_gb_content_width":"","footnotes":""},"categories":[6,4],"tags":[],"class_list":["post-44","post","type-post","status-publish","format-standard","hentry","category-iptables","category-sciaga-admina"],"_links":{"self":[{"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/posts\/44","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/comments?post=44"}],"version-history":[{"count":2,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/posts\/44\/revisions"}],"predecessor-version":[{"id":46,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/posts\/44\/revisions\/46"}],"wp:attachment":[{"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/media?parent=44"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/categories?post=44"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.antynet.pl\/index.php\/wp-json\/wp\/v2\/tags?post=44"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}