laforge@gnumonks.orgOryginał tego dokumentu znajduje się pod adresem: http://netfilter.samba.org/
l.bromirski@mr0vka.eu.orgOryginał tego tłumaczenia znajduje się pod adresem: http://mr0vka.eu.org/tlumaczenia/netfilter-faq.html
Sekcja ta odpowiada na pytania ogólnie związane z netfilter, które pojawiają się bardzo często.
Netfilter i IPtables są zintegrowane w jądrach linuksa serii 2.4.x. Proszę ściągnij źródła ostatniego kernela z http://www.kernel.org/ lub jednego z jego mirrorów.
Narzędzie działające w przestrzeni użytkownika 'iptables' jest dostępne na stronie domowej netfilter, lub na jednym z mirrorów: http://www.netfilter.org/, http://www.iptables.org/, http://netfilter.samba.org/, http://netfilter.gnumonks.org/ lub http://netfilter.filewatcher.org/.
Nie, aktualnie nie ma. Ale, jeśli ktoś chciałby zacząć to pisać, nie powinno być to zbyt trudne z uwagi na jasny interfejs do stosu sieciowego.
Proszę, poinformujcie nas o jakiejś pracy w tym zakresie.
Jeśli jesteś przyzwyczajony do maskarady z Linuksa 2.2, używałeś zawsze modułu ip_masq_icq module by uzyskać bezpośrednie połączenie klient-klint dla ICQ.
Nikt nie przepisał tego modułu, ponieważ protokół ICQ jest zbyt brzydki :) Ale, jak sądzę jest to tylko kwestia czasu.
Rusty kiedyś stwierdził, że tylko protokoły z przynajmniej jednym darmowym klientem i jednym darmowym serwerem będą integrowane do głównej dystrybucji netfilter. Jeśli chodzi o ICQ, są tylko darmowe klienty, więc nie pasuje on do tych kryteriów (wolny jak wolność, nie jak wolne piwo, wg. definicji RMS)
Niektóre z nich nie są już potrzebne, a niektóre nie zostały jeszcze przeniesione do netfilter. Netfilter zapewnia aktualnie pełne śledzenie połączeń, nawet dla UDP, i generalnie będzie starał się zmieniać pakiety tak niewiele jak to tylko będzie możliwe, więc czasami programy "po prostu" pracują.
Kernele 2.4.x są wersją stabilną, więc nie możemy tak po prostu dołączań swoje aktualne poprawki do głównej dystrybucji. Cały nasz kod jest tworzony i testowany w netfilter patch-o-matic. Jeśli chcesz używać najnowszych funkcji netfilter, będziesz musiał użyć jednego z patchy z patch-o-matic. Możesz znaleźć program patch-o-matic w najnowszej paczce iptables (lub, oczywiście na CVS), którą ściągnąć można ze strony WWW netfilter.
patch-o-matic ma obecnie trzy dostępne opcje:
Pierwsza opcja ma na celu dołożenie wszystkich istotnych poprawek (które i tak zostały wysłane koordynatorom kernela) na twój kernel. Druga, `most-of-pom` dodaje dodatkowo wszystkie nowe opcje, które mogą zostać dodane bez konfliktów z już istniejącymi. Trzecia opcja jest dla prawdziwych ekspertów, którzy chcą przejrzeć wszystkie poprawki - ale weźcie pod uwagę, że mogą nie być między sobą zgodne.
patch-o-matic ma miły interfejs. Wprowadź po prostu
make most-of-pom (lub pending-patches czy patch-o-matic, zajrzyj wyżej)
lub, jeśli źródła twojego kernela nie są w /usr/src/linux użyj
make KERNEL_DIR={katalog-ze-źródłami} most-of-pom
w głównym katalogu paczki iptables. patch-o-matic sprawdza każdy patch pod kątem możliwości zaaplikowania do źródeł kernela. Jeśli uzna że można go użyć, zobaczysz znak zachęty, z poziomu którego możesz uzyskać więcej informacji o patchu, zaaplikwać go, przejść do następnego, ...
Po więcej informacji dotyczących patch-o-matic, zajrzyj na stronę rozszerzeń netfilter, która znajduje się pod adresem http://www.netfilter.org/documentation/index.html#HOWTO.
ipnatctl był używany do ustawiania reguł NAT w przestrzeni użytkownika w bardzo wczesnych wersjach netfilter (jeszcze w czasie prac z kernelami serii 2.3.x). Nie jest już potrzebny, więc nie udostępniamy go. Całą jego funkcjonalność przejęło iptables. Obejrzyj NAT HOWTO na stronie domowej netfilter.
To znana sprawa. Mechanizm rozpoznający które patche są już zaaplikowane źle działa. Użyj "make build" zamiast "make".
Lepsze rozwiązanie: uaktualnij system do iptables-1.1.2 lub nowszych.
Wewnętrzne struktury w iptables zostały zmienione. Uaktualnij iptables do wersji >= 1.1.1
Proszę użyć najnowszej wersji iptables.
Najprawdopodobniej masz problemy ze skompilowaniem funkcji nazwanej ip_nat_setup_info.
Jeśli używasz iptables <= 1.2.2, MUSISZ zaaplikować łaty `dropped-table` i `ftp-fixes`.
Jeśli używasz iptables > 1.2.2 lub ostatniej wersji z CVS, proszę nie aplikuj patcha 'dropped-table', ponieważ jest niekompatybilny z BALANCE, NETMAP, irc-nat, SAME i talk-nat.
Podstawowy zespół netfilter bazuje na drzewie Linus'a, więc używasz wersji -ac na własne ryzyko.
Wiadomość taką generuje kod NAT, ponieważ pakiety multicastowe trafiają do tabeli NAT, a kod odpowiedzialny za śledzenie połączeń nie potrafi ich obsłużyć. Jeśli nie wiesz co to jest multicast, lub w ogóle tego nie potrzebujesz, użyj:
iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8
Mój syslog lub moja konsola pokazują taką wiadomość:
NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb
Wiadomość taką generuje kod NAT. Odrzuca pakiety, ponieważ by wykonać na nich NAT musi posiadać prawidłową informację o połączeniu. Wiadomość taka jest drukowana dla wszystkich pakietów, których kod śledzący połączenia nie był w stanie zidentyfikować.
Możliwe przyczyny to:
Jeśli chciałbyś prowadzić dużo bardziej szczegółowe logowanie tych pakietów (np. podejrzewasz że jest to zdalna próba skanowania), użyj następującej reguły:
iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID
I tak, musisz wstawić tą regułę do tabeli przekształceń (ang. mangle), ponieważ pakiety będą odrzucane przez NAT zanim osiągną tabelę filtrowania.
Chcesz stworzyć kompletnie transparentną ścianę ogniową? Wspaniały pomysł!
Począwszy od wersji kernela 2.4.16 musisz dodać tylko łatkę do kernela, dostępną pod adresem http://bridge.sourceforge.net/.
Cóż, to połowa prawdy. Tylko tabela NAT nie potrafi go obsłużyć. Jeśli użwasz filtrowania pakietów bez NAT wszystko powinno działać.
Netfilter stara się modyfikować pakiety minimalnie, na tyle ile to możliwe. Więc jeśli mamy maszynę po restarcie, i ktoś za komputerem robiącym SNAT otwiera połączenie do lokalnego portu 1234, netfilter zmienia jedynie adres IP a port zostaje ten sam.
Ale jeśli ktoś inny otworzy połączenie z tym samym portem źródłowym, netfilter musi zmienić i IP i port, jeśli ma tylko jedno IP dla SNAT.
Jeśli są dostępne inne, ponownie zmienia tylko adres IP.
Jeśli zobaczysz powyższy komunikat w syslog, wygląda na to że baza danych śledzenia połączeń nie ma wystarczająco dużo miejsca w twoim otoczeniu. Śledzenie połączeń domyślnie obsługuje tylko pewną liczbę jednoczesnych połączeń. Liczba ta jest zależna od ilości pamięci operacyjnej (przy 64MB: 4096, 128MB: 8192, ...).
Możesz łatwo zwiększyć numer maksymalnie śledzonych połączeń, ale zwróć uwagę że każde połączenie zabiera około 350 bajtów pamięci nie wymienialnej!
By zwiększyć limit to dnp. 8192, napisz:
echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max
Istnieje plik w systemie plików /proc, nazywa się /proc/net/ip_conntrack.
Możesz wydrukować go na wyjście używając komendy
cat /proc/net/ip_conntrack
Wszystkie dostępne tabele IP można wylistować przez
cat /proc/net/ip_tables_names
Znany błąd. Uaktualnij się do najnowszej wersji z CVS lub używaj iptables >= 1.2.1 jak tylko będzie dostępne.
Dzieję się tak ponieważ iptables sprawdza DNS przy każdym adresie IP. Ponieważ każda reguła składa się z jednego lub dwóch adresów, w najgorszym przypadku mamy dwa sprawdzenia na regułę.
Problem zaczyna się, gdy używasz prywatnych adresów IP (jak np. 10.x.x.x czy 192.168.x.x), a DNS nie jest w stanie ich rozwinąć i w końcu się poddaje. Suma tych wszystkich time-out'ów może trwać _bardzo_ długo, wszystko zależy od twojego zestawu reguł.
Użyj opcji -n (numerycznie) dla iptables, by zapobiec sprawdzaniu DNSu.
Musisz prawidłowo skonfigurować swój syslogd: Cel LOG loguje do facility kern z priorytetem ostrzeżenia (ang. warning, 4). Zajrzyj do podręcznika syslogd.conf by dowiedziec się więcej.
Domyślnie, wszystkie wiadomości kernela z priorytetem wyższym niż debug (7) wysyłane są na konsolę. Jeśli podniesiesz go do 4, zamiast 7, zapobiegniesz wysyłaniu informacji z LOG na konsole.
Zwróć jednak uwagę, że powstrzyma to również inne, istotne wiadomości od pojawiania się na konsoli (nie wpływa to na syslog).
Po pierwsze, potrzebujesz właściwej reguły DNAT lub REDIRECT. Użyj REDIRECT tylko jeśli squid pracuje na tej samej maszynie. Na przykład:
iptables -t nat -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128
Następnie, musisz właściwie skonfigurować squid'a. Możemy tu tylko dać krótkie wskazówki, zajrzyj do dokumentacji squid'a po dalsze informacje.
Plik squid.conf dla Squid'a 2.3 potrzebuje następujących linijek:
http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy on
httpd_accel_uses_host_header on
httpd_accel_single_host off
Cel LOG jest tym co nazywamy "nie-ostatecznym celem", tzn. nie kończy on sprawdzania pakietu. Jeśli używasz celu LOG, pakiet zostanie zalogowany, ale przeglądanie reguł odbywa się dalej.
Więc jak możesz zalogować i odrzucić pakiet jednocześnie? Nic prostszego, tworzysz osobny łańcuch który zawiera dwie reguły:
iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP
Teraz za każdym razem gdy chcesz zalogować i odrzucić pakiet, używasz celu "-j logdrop".
Możesz użyć patcha tcp-window-tracking patch z patch-o-matic, którego kod śledzi akceptowalne parametry dla przepuszczanych strumieni TCP zgodnie z numerami sekwencyjnymi/potwierdzeń, rozmiarami segmentów, itd. Kiedy wykryje że pakiet jest nie do zaakceptowania (poza oknem), zaznacza go jako INVALID i wypisuje wiadomość jak powyżej.
Nowsze wersje logują pakiet i dokładnie co spowodowało taką akcję:
Również w nowszych wersjach logowanie można całkowicie powstrzymać przez sysctl
echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window
Więc sprawdzałeś /proc/net/ip_conntrack i znalazłeś bardzo wysokie wpisy połączeń UNREPLIED (które nie są oczywiście połączeniami)?
Odpowiedź jest prosta: wpisy UNREPLIED są tymczasowe, tzn. jak tylko skończy się pula połączeń (osiągnięta zostanie granica /proc/sys/net/ipv4/ip_conntrack_max), kasujemy stare wpisy UNREPLIED. Innymi słowy, staramy się raczej by inne, prawidłowe i całe połączenia mogły dochodzić do skutku.
Dostępna jest biblioteka nazwana libipq, która służy do obsługi pakietów w przestrzeni użytkownika. Jest też dokumentacja dla niej w postaci stron podręcznikowych. Musisz zbudować i zainstalować komponenty programistyczne iptables:
make install-devel
a następnie sprawdź libipq(3).
Może cię również zainteresować Perlipq zawierająca powiązania dla Perla do libipq: http://www.intercode.com.au/jmorris/perlipq/. Same powiązania są przykładem jak używać biblioteki.
Inne przykłady kodu obejmują:
Główny zespół netfilter utrzymuje listę TODO (do zrobienia), gdzie wpisuje wszystkie najbardziej pożądane zmiany / nowe możliwości. Możesz ściągnąć tą listę przez anonimowy CVS, instrukcje znajdują się na stronie domowej netfilter. Możesz również udać się pod adres http://cvs.samba.org/cgi-bin/cvsweb/netfilter/TODO/ i obejrzeć plik przy użyciu CVSweb.
Jeśli chcesz je opublikować, wyślij pocztę pod adres listy netfilter-devel. Informacje o prenumeracie dostępne są pod adresem http://lists.samba.org/mailman/listinfo/netfilter-devel/.
Prawidłowy sposób na wysłanie patcha jest następujący :
Jeśli napisałeś nowe rozszerzenie, lub dodałeś coś do starych funkcji, dobrze jest również uzupełnić dokument netfilter-extensions HOWTO i zawrzeć w nim informacje o nowej funkcjonalności i zasadach działania rozszerzenia. Dodatkowo, zainteresuje to z pewnością większą liczbę użytkowników i zapewni więcej komentarzy.