Nastny Poprzedni Spis Trei

3. Problemy podczas pracy

3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

Ta wiadomośæ jest drukowana przez kod NAT, ponieważ pakiety multicastowe trafiają do tabeli NAT, a connection tracking nie obsługuje teraz multicastów. Jeśli nie masz pojêcia co to jest multicast lub zupełnie nie potrzebujesz tego, używaj:

iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8

3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Mój syslog lub konsola pokazuje wiadomośæ:

NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Ta wiadomośæ jest drukowana przez kod NAT. Zrzuca pakiety, ponieważ by NATowaæ potrzebuje mieæ poprawne informacje o stanie połączenia. Ta wiadomośæ jest drukowana dla wszystkich pakietów, dla których connection tracking nie mógł uzyskaæ informacji o stanie połączenia.

Prawdopodobne powody to:

Jeśli chcesz bardziej szczegółowo logowaæ te pakiety (tj. jeśli podejrzewasz, że to zdalna sonda (remote probe) / pakiety skanujące), użyj nastêpującej regułki:

iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

Tak, musisz wstawiæ regułkê w tabeli mangle, ponieważ pakiety są zrzucane przez kod NAT zanim dotrą do tabeli filter.

3.3 ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Mój syslog lub konsola regularnie pokazuje mi napis w stylu:

ip_conntrack: max number of expected connections N of M reached for aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

3.4 foo

Zasadniczo nie ma siê czym przejmowaæ, szczególnie gdy N i M sa 1, a po tej wiadomości jest , reusing. W szczególności wersje jądra (2.4.19<=x<=2.4.21-pre3), ten komunikat był drukowany dla FTP - I faktycznie może siê zdarzyæ podczas normalnego działania FTP.

Z nadchodzącymi wersjami jądra (>=2.4.21-pre4) ta wiadomośæ nie jest drukowana by nie myliæ użytkownika. Jeśli nadal otrzymujesz takie wiadomości, skontaktuj siê z listą: http://lists.netfilter.org/mailman/listinfo/netfilter-devel.

3.5 Nie udaje mi siê użyæ netfiltra razem z Linux bridging code

Wiêc chcesz zbudowaæ całkowicie przezroczysty firewall? Świetny pomysł! Niestety bridging code pomija normalny stos sieci włącznie z netfilterem.

Ale ktoś pisze nowy bridging code, zerknij na http://bridge.sourceforge.net/

Zauważ, że wsparcie dla bridge'ującego firewalla jest uważane za skrajnie eksperymentalne.

3.6 Moduł IRC nie obsługuje DCC RESUME

Jest to połowiczna prawda. Tylko moduł NAT nie jest w stanie obsłużyæ ich. Jeśli jest to firewall bez NAT, powinno działaæ. Łatki mile widziane.

3.7 Jak działa SNAT do wielu adresów?

Netfilter stara siê jak najmniej zmieniaæ pakiety. Wiêc jeśli mamy świeżo-przeładowaną maszynê i ktoś za SNAT'em otwiera połączenie z loklanym portem 1234, netfilter tylko zmienia adres IP a port zostaje ten sam.

Jak tylko ktoś inny otworzy inne połączenie z tym samym źródłowym portem, netfilter musiałby zmieniæ IP i port jeśli ma tylko jeden IP dla SNAT.

Ale jeśli jest dostêpny wiêcej niż jeden, ponownie tylko musi zmieniaæ czêśæ IP.

3.8 ip_conntrack: maximum limit of XXX entries exceeded

Jeśli zauważysz nastêpujące wpisy w syslogu, wygląda na to, że baza danych conntrack nie ma wystarczającego miejsca na twoje środowisko. Connection tracking domyślnie obsługuje do pewnego poziomu liczbê współbieżnych połączeñ. Ta liczba zależy od rozmiaru pamiêci (przy 64MB: 4096, 128MB: 8192, ...).

Możesz z łatwością zwiêkszyæ maksymalną liczbê rejestrowanych połączeñ, ale miej na uwadze, że każde połączenie zjada około 350 bajtów nieswappowalnej pamiêci jądra.

By zwiêkszyæ ten limit do np 8192, wpisz:

echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max

By zoptymalizowaæ wydajnośæ, zwiêksz też ilośæ koszyków funkcji hashującej używając parametru hashsize podczas ładowania modułu ip_conntrack.o. Zwróæ uwagê na fakt, iż przez cechy obecnego algorytmu haszującego, parzysta liczba koszyków funkcji haszującej (i w szczególności potêgi liczby 2) są złym rozwiązaniem.

Przykład (z 1023 koszykami):

modprobe ip_conntrack hashsize=1023

3.9 Jak wylistowaæ śledzone / maskaradowane połączenia, podobnie jak 'ipchains -L -M' w 2.2.x

Jest plik w filesystemie proc, zwany /proc/net/ip_conntrack. Możesz wyświetliæ jego zawartośæ pisząc:

cat /proc/net/ip_conntrack

3.10 Jak wylistowaæ dostêpne tabele IP?

Wszystkie dostêpne tabele IP są w:

cat /proc/net/ip_tables_names

3.11 iptables-save / iptables-restore z iptables-1.2 wywala segfaulty

Znany błąd. Uaktualnij do najświeższego CVS lub użyj iptables >= 1.2.1 jak tylko bêdzie dostêpne.

3.12 Mijają wieki zanim iptables -L wyświetli regułki

To dlatego, że iptables robi DNS lookup dla każdego adresu. Jako że każda regułka składa siê z dwu adresów, w najgorszym przypadku wychodzi na 2 DNS lookupy na regułkê.

Problem jest, jeśli używasz prywatnych adresów IP (10.x.x.x lub 192.168.x.x), DNS nie jest w stanie rozwiązaæ nazwy hosta i czekamy na timeout. Suma wszystkich timeoutów może byæ bardzo duża, w zależności od zestawu regułek.

Używaj opcji -n (numeric) w iptables by pominąæ reverse DNS lookups.

3.13 Jak zrobiæ by target LOG nie logował na konsolê?

Musisz skonfigurowaæ syslogd odpowiednio: Target LOG loguje do facility kern przy priorytecie warning (4). Zobacz strony man od syslogd.conf by przeczytaæ wiêcej o facilities i priorytetach.

Domyślnie, wszystkie wiadomości na priorytecie bardziej poważnym niż debug (7) są wysyłane na konsole. Jeśli zwiêkszysz to do 4, zamiast 7, sprawisz, że logi nie bêdą siê pojawiały na konsoli.

Miej na uwadze, że to także pociąga za sobą inne ważne logi i nie pojawią siê na konsoli (to nie wpływa na syslog).

3.14 Jak zbudowaæ transparent proxy używając squida i iptables?

Na początku, oczywiście, potrzebujesz odpowiedniej regułki DNAT lub REDIRECT. Użyj REDIRECT tylko gdy squid chodzi na tej samej maszynie co NAT. Przykład:

iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128

Potem, musisz skonfigurowaæ odpowiednio squida. Możemy tylko daæ krótkie wskazówki, odsyłam do dokumentacji squida po szczegóły.

squid.conf dla Squid 2.3 powinien wyglądaæ podobnie do tego:

http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
Squid 2.4 potrzebuje dodatkowej linii:

httpd_accel_single_host off

3.15 Jak używaæ target LOG / Jak mogê LOGowac i DROPowac?

Target LOG jest czymś co nazywamy "niekoñczący target", tj. nie koñczy podróży pakietu. Jeśli użyjesz target LOG, pakiet bêdzie zalogowany i podróż bêdzie kontynuowana od nastêpnej regułki.

Wiêc jak mam logowaæ i zrzucaæ pakiet jednocześnie? Nic prostszego, możesz stworzyæ własny łañcuch, zawierający te dwie regułki:

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Teraz za każdym razem jak bêdziesz chciał logowaæ i zrzuciæ pakiet, możesz po prostu użyæ "-j logdrop".

3.16 Jak mogê zatrzymaæ robaka XYZ używajaæ netfiltra ?

Krótka odpowiedz brzmi: nie da siê tego zrobiæ prawidłowo używając netfiltra. Wiêkszośæ robaków używa prawidłowych protokołów wyższej warstwy (tj. HTTP, SMTP (np. VB script w załączniku listu), lub wykorzystuje jakąkolwiek inną znaną dziurê w demonie obsługującym protokół). Mówiąc protokół wyższych wartsw, mamy na myśli ponad TCP/IP. Jako że iptables nie rozumie protokołów wyższych wartsw, jest prawie nie możliwe filtrowanie ich prawidłowo. Do tego potrzeba proxy filtrujących na poziomie aplikacji.

Proszê nie używaj matchu string z patch-o-matic zamiast takiej aplikacji. Nie da rady sobie z fragmentowanymi pakietami (tj. zapytanie HTTP rozbite na dwa pakiety TCP), z technikami unikania systemów IDS, itd... zostałeś ostrzeżony! Match string jest przydatny ale w innych celach.

3.17 jądro loguje: Out of windows data xxx

Używasz łaty tcp-window-tracking z patch-o-matic, którego kod śledzi czy pakiety dopuszczonych strumieni TCP mają zgodne numery sekwencji/potwierdzenia (sequence/acknowledgement), rozmiary segmentów, itd. pakietów. Kiedy wykryje, że pakiet jest nieakceptowalny (out of the window), zaznacza go jako INVALID i drukuje komunikat.

Nowsze wersje logują pakiet i dokładny warunek, którego nie spełnił:

Także, w nowszych wersjach logowanie można całkowicie wyłączyæ poprzez sysctl

echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window

3.18 Dlaczego system śledzenia połączeñ (connection tracking) śledzi połączenia UNREPLIED (bez odpowiedzi) z dużym timeoutem?

Wpierw, sprawdzy czy nie używasz jądra 2.4.20. Jeśli tak, zaplikuj natychmiast patch spod adresu: https://bugzilla.netfilter.org/cgi-bin/bugzilla/showattachment.cgi?attach_id=8! The 2.4.20 kernel did contain a bug resulting in lots of bogus UNREPLIED conntrack entries (see https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=56).

Sprawdziłeś /proc/net/ip_conntrack i znalazłeś wpisy połączeñ w stanie UNREPLIED o bardzo wysokim czasie (aż do piêciu dni) i zastanawiasz siê dlaczego marnujemy wpisy conntrack (które oczywiście nie są połączeniami)?

Odpowiedź jest prosta: wpisy UNREPLIED są tymczasowe, tj. jak tylko zabraknie miejsca (osiągniemy /proc/sys/net/ipv4/ip_conntrack_max), kasujemy stare wpisy UNREPLIED. Innymi słowy zamiast trzymaæ puste wpisy, wolimy trzymaæ prawdopodobnie cenne informacje dopóki wolne wpisy są naprawdê potrzebne.

3.19 Dlaczego nie zaimplementowano opcji 'iptables -C' (--check) ?

Po pierwsze dlatego, że jesteśmy leniwi ;). A szczerze mówiąc, implementacja opcji check jest prawie niemożliwa jak tylko zaczynamy stateful firewalling. Tradycyjne firewalle nie przetrzymujące informacji o stanie połączenia (są stateless) opierają swoje decyzje tylko w oparciu o informacje zawarte w nagłówkach pakietów. A że śledzeniem połączeñ (i regułami opartymi o '-m state'), decyzja o filtrowaniu zależy od nagłówka+dane, a także od nagłówka+dane poprzednich pakietów danego połączenia.

3.20 Czemu nie mogê użyæ REJECT w łañcuchach PREROUTING ?

REJECT stosuje siê do filtrowania. Tabela filter ma łañcuchy INPUT/OUTPUT/FORWARD, zatem REJECT może byæ użyty tylko w tych łañcuchach (i pod-łañcuchach, rzecz jasna).

Użytkownicy Netfiltra nie filtrują pakietów w tabelach nat lub mangle.

3.21 'iptables: Invalid argument' po aktualizacji jądra (tabela nat)

Własnie zaktualizowałeś jądro i nagle niektóre komendy (szczególnie w tabeli 'nat'), powodują ten komunikat, np:

# iptables -A POSTROUTING -t nat -o ppp0 -j MASQUERADE
iptables: Invalid argument

To siê zdarza gdy rozmiary struktur miêdzy przestrzenia jądra a użtykownika siê zmieniają. Bêdziesz musiał ponownie skompilowaæ program przestrzeni użtykownika używając plików nagłowkowych swojego nowego jądra. To siê zdarza tylko gdy zaaplikowałes (ty, lub dostawca twojego jądra) niektóre łaty do starego lub tylko do nowego jądra. Nie powinno to siê zdarzaæ z waniliowymi jądrami z kernel.org. Jeśli jednak, poinformuj proszê o tym listê netfilter-devel.

3.22 Dlaczego nie mogê używaæ REJECT w łañcuchu PREROUTING?

Target REJECT służy do filtrowania. Tabela filter ma łañcuchy INPUT/OUTPUT/FORWARD, zatem REJECT może byæ tylko używany w tych łañcuchach (i podłañcuchach, naturalnie).

Użytkownicy netfiltra nie filtrują pakietów w tabeli nat czy mangle.


Nastny Poprzedni Spis Trei