Optymalizacja routera opartego o system Linux
Każdy admin pewnego dnia staje przed zadaniem optymalizacji reguł iptables celem ich optymalizacji. W moim przypadku problem pojawił się w momencie przekroczenia sumarycznego ruchu (do i z rutera) 360Mb/s. W tym Momocie sumaryczna ilość pakietów wzrosła do 31.8 k./s.
Efekt był taki, iż zaczęły się chwilami gubić pakiety, ponadto czas wczytywania stron www odczuwalnie się wydłużył, pomimo faktu, iż podczas ściągania danych w sieciach p2p nadal działały bez zakłóceń. Pakiety ICMP coraz częściej wypadały i/lub rosły ich czasy, load average routera dochodził do 1,5.
W związku z tym przystąpiłem do optymalizacji regułek iptables i innych drobnych zabiegów, kilka z nich przedstawiam poniżej.
1. Na początek dochodzimy do wniosku, w jakim celu filtrować po IP źródłowym połączenia, na które klient już wcześniej dostał zezwolenie. Przecież to bezsensu! Skoro już klient wysłał pakiet SYN kontrolowany na podstawie adresu IP oraz MAC i dostał zezwolenie na połączenie, to dalsze pakiety możemy spokojnie puścić bez tej kontroli, testujemy tylko stan połączenia:
iptables -A FORWARD -m state –state ESTABLISHED,RELATED -j ACCEPT
2. Najbardziej popularne porty puszczamy szybciutko na początku filtrowania, pozwoli to znacznie zwiększyć prędkość wczytywania danych, ktoś zapyta a co z adresami IP, które maja blokadę dostępu do Internetu? O tym później 
iptables -A FORWARD -i eth1 -p tcp -m multiport –dports 25,80,110 -j ACCEPT
3. Podobna sytuacja z pakietami UDP, gry on-line oraz telefonia internetowa znacznie przyśpieszy.
iptables -A FORWARD -i eth1 -p udp -j ACCEPT
4. Zmieniamy domyślne wartości dla protokołu IPV4, po prostu przyspieszamy pewne operacje.
echo 20 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close
echo 1800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_syn_sent
echo 60 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_close_wait
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_time_wait
echo 10 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout
echo 30 > /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
5. Przy tak skonstruowanych regułach iptables klienci, którzy, powinni mieć wycięty ruch do Internetu bez problemu mogą korzystać z www oraz poczty. Chcąc ich zablokować należy regułki DROP dać na początek, w efekcie pakiet autoryzowany musi pokonać regułki blokad i dopiero trafia na swoje zezwalające na dostęp do Internetu. Powoduje to oczywiste opóźnienie. Dlatego też wycinanie klientów realizowane będzie na poziomie routingu a nie filtrowania pakietów. Kolejne tysiące pakietów nie będą musiały być filtrowane:
route add -host ip_hosta reject
Połączenia z adresu ip_hosta nawet niedotrze do regułek filtrujących, chyba nie muszę mówić jak odpocznie nasz firewall.
Parę prostych zabiegów a Internet znowu zaczął u klientów szaleć aż miło, ponadto load average z 1,5 spadło do 0,05 czego życzę i Wam
Ostatnie komentarze