Kiedy moduł conntrack iptable śledzi stany pakietów?
Najpierw musi przechowywać stany. Z jakąś starą zaporą BSD, której używałem, przypuszczalnie nazywała się IPFW, użyłem reguły, która nasycała "śledzenie stanu wychodzącego pakietu" i była umieszczana na wychodzącym kierunku interfejsów. Następnie kolejna reguła dotycząca kierunku przychodzącego, która porównywała je ze stanami, które zostały utworzone przez regułę dotyczącą kierunku wychodzącego. Więc kiedyś były 2 reguły: (1) do zapełniania tabeli stanów, to było w kierunku wychodzącym, i (2) do wyszukiwania tabeli stanów, to było w kierunku przychodzącym.
Ale w przypadku connntrack widzę, że jest to stosowane w łańcuchu INPUT, na przykład ta reguła:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
To sprawia, że zastanawiam się, co właściwie robi to stwierdzenie?
- Czy oznacza to, że rozpocznie śledzenie pakietów pasujących do tej reguły, umieszczając ich informacje w tabeli stanów?
- A może mówi, że ma już informacje o stanach i zamierza działać przeciwko wiadomościom przychodzącym na ich podstawie? (np. zaakceptować, jeśli należały do wcześniej zaakceptowanego połączenia?). Ale w tym przypadku, gdzie została wypełniona tabela stanów? Która reguła to robi? A może jest pozbawiony reguł i niejawny?
Odpowiedzi
Prezentacja wprowadzająca Netfilter i conntrack
Najpierw obowiązkowy schemat przepływu pakietów w Netfilter i General Networking:
Netfilter to struktura filtrowania pakietów, która umieszcza się nad pozostałą częścią stosu sieciowego (reprezentowana przez „decyzję o routingu” i inne białe, zaokrąglone pola). Netfilter udostępnia punkty zaczepienia i interfejsy API dla innych podsystemów i „klientów”. Wśród tych części są conntrack (śledzenie połączeń) i iptables (lub nftables ). Separacja między Netfilter i conntrack jest dość niejasna. Możesz po prostu rozważyć conntrack jako integralną część Netfiltera.
Na schemacie opisującym różne kroki, przez które przechodzi pakiet, można zobaczyć, że w pewnym momencie (między nieprzetworzonym / PREROUTING a mangle / PREROUTING lub między raw / OUTPUT i mangle / OUTPUT) pakiet przechodzi przez tor .
W tym momencie conntrack przeszuka swoje własne tabele wyszukiwania (mini baza danych wyszukiwania przechowywana w pamięci jądra):
- jeśli charakterystyka tego pakietu nie zostanie znaleziona (i jeśli nie zostanie zadeklarowana jako UNTRACKED w tabeli surowej), nowy wpis dwukierunkowej krotki połączenia (protokół, a następnie informacje o określonej rodzinie i protokole: początkowe źródło i port, początkowe miejsce docelowe i port, źródło odpowiedzi i port, miejsce docelowe odpowiedzi i port (te dwa ostatnie są zwykle odwrotne, chyba że zaangażowany jest NAT lub jakieś dziwne protokoły, takie jak odpowiedź echa pasująca do żądania echa dla ICMP)) opisujący przepływ jest tworzony ze stanem NOWY.
- jeśli pasuje (w dowolnym kierunku) do poprzedniego wpisu i jest zgodny ze stanem tego przepływu, stan przepływu może zostać zmieniony (np .: zmiana z NOWY na Ustanowiony, jeśli wcześniej tak nie było).
- jeśli z jakiegoś szczególnego powodu pakiet nie może dopasować się do istniejącego przepływu, mimo że ma swoje cechy (np .: późny pakiet TCP odebrany po udanej retransmisji, a więc jest poza oknem w odniesieniu do sekwencji i wartości SACK), pakiet zostanie oznaczony jako NIEWAŻNY.
- istnieje kilka innych przypadków, takich jak POKREWNE: dotyczy to pakietów, które nie są częścią samego przepływu, ale są związane z nowym przepływem, który może być powiązany z innym istniejącym przepływem (tj. w bazie danych). Dwa przykłady to błąd ICMP spowodowany odebraniem pakietu (np .: port UDP nieosiągalny) lub gdy specjalny pomocnik protokołu, taki jak moduł jądra
nf_conntrack_ftp, który jest wtyczką do podsystemu łączącego , wykrywa, że pakiet jest częścią oddzielnego powiązanego przepływu danych za pomocą poleceń FTP PASV / EPSV lub PORT / EPRT wykonanych w przepływie poleceń (na porcie 21).
Odpowiadając na pytanie
Biorąc to wszystko pod uwagę, oto odpowiedzi na twoje dwie kule:
w głównej przestrzeni nazw sieci conntrack rozpoczyna śledzenie połączeń, gdy tylko załadowane zostaną jego moduły (w tym ewentualne odpowiednie podmoduły specyficzne dla protokołu). W przypadku nie-początkowych sieciowych przestrzeni nazw (kontenerów ...) wymaga to również, aby jakiś inny podsystem odnosił się do niego (np. Moduł conntrack w iptables OP lub użycie polecenia
conntrackopisanego później). Jest to domyślny i pakiet musi być specjalnie oznaczone jako nieśledzonej przed conntrack podsystem widzi w tym pakiecie nie być śledzone. W Linuksie jest tylko kilka przypadków, w których śledzenie nie byłoby potrzebne, ale wtedy oczywiście stanowa zapora ogniowa i stanowy / dynamiczny NAT nie będą już dostępne (steless NAT, który może nawet wymagać użycia UNTRACKED w pierwszej kolejności, nadal może być gotowe, ale nie za pomocą iptables . tc lub nftables może). Aby uniknąć obsługi przez conntrack niektórych pakietów, można użyć tego rodzaju reguły iptables (np .: port 80 / tcp):iptables -t raw -A PREROUTING -p tcp --dport 80 -j CT --notrack iptables -t raw -A OUTPUT -p tcp --sport 80 -j CT --notrackGdy pakiet przechodzi przez filtr / INPUT i osiąga tę regułę:
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTW iptables „s moduł jądra specyficzny
xt_conntrackodpytuje conntrack podsystemu (obsługiwane przez różne odpowiednie moduły jądranf_conntrack*) i pyta o stan tego pakietu w swojej bazie danych wyszukiwania. Jeśli odpowiedź brzmiRELATEDlubESTABLISHEDpakiet pasuje i przechodzi do werdyktu AKCEPTUJ. Właściwie wynik jest już buforowany w pakiecie przy pierwszym wyszukiwaniu (zwykle przez conntrack ), więc jest to tanie „wyszukiwanie”. Jest to zatem ogólna zasada obsługi przepływów już wcześniej zaakceptowanych. Przepływy te można początkowo zaakceptować w regułach, które wyraźnie wspominają o tym-m conntrack --ctstate NEWlub po prostu w regułach, w których nie ma o nim wzmianki, ale są umieszczane po tej ogólnej regule (ale należy pamiętać o stanie NIEPRAWIDŁOWY, który zwykle powinien zostać DROP).dodając kulę: obchodzenia się z pakietów przychodzących i wychodzących pakietów jest dość symetryczna między PREROUTING i OUTPUT (nawet jeśli te nie wyglądają symetryczne): conntrack interfejsy w PREROUTING jak również na wyjściu (iw kilku innych miejscach, zważywszy NAT jest praca z conntrack , z wyjątkiem pierwszego pakietu w stanie NEW przechodzącym przez tablicę nat iptables ). Może się to nieco różnić od opisu, który napisałeś o IPFW. Jeśli serwer, na którym działają aplikacje, ogranicza również przepływy wychodzące, najprawdopodobniej potrzebuje tej samej ogólnej reguły iptables zarówno w filtrze / WYJŚCIU, jak iw filtrze / WEJŚCIU, aby przepuścić wychodzące pakiety odpowiedzi już zaakceptowanego ruchu przychodzącego.
Dodatkowe informacje
Są dedykowane narzędzia do interakcji z Conntrack podsystemu tabel odnośników z Conntrack-tools .
conntrack: do przeszukiwania, usuwania lub aktualizowania zawartości tabel przeglądowych obsługiwanych przez conntrack .
Kilka przykładów.
Możesz wyświetlić wszystkie śledzone wpisy (które mogą być duże bez dodatkowego filtra) za pomocą:
conntrack -LJeśli system robi NAT (np router przed prywatnej sieci LAN, lub systemem VMS i pojemniki) można użyć
--any-nat,--src-natalbo--dst-nattylko do wyświetlania wzgl. wszystkie NAT, wszystkie źródła NAT (maskarada) lub wszystkie docelowe NAT (zazwyczaj dla portów przekierowanych):Monitorowanie w czasie rzeczywistym Conntrack zdarzeń:
conntrack -Econntrackd: demon, którego dwoma głównymi celami są (łączenie) zliczanie i statystyki przepływu lub synchronizacja stanu klastra zapory o wysokiej dostępności .
Śledzenie połączeń jest oddzielną funkcją Netfilter i nie jest konfigurowane z IPTables.
Na rysunku są dwa conntrackkroki w ścieżce INPUT i jeden w ścieżce OUTPUT. Te kroki wiążą poszczególne pakiety z istniejącymi połączeniami śledzonymi w tabeli śledzenia połączeń lub tworzą nowe wpisy śledzenia połączeń w tabeli.
Funkcjonalność Conntrack jest modułem jądra Linuksa i często jest dołączona do jądra w domyślnej konfiguracji.
Operację łączenia można dostroić, dostosowując net.netfilter.nf_conntrackwartości sysctl.
Twoja druga alternatywa to to, co się dzieje. Informacje o stanie są rejestrowane przez funkcję Conntrack, a reguła IPTables po prostu sprawdza tabelę Conntrack w celu uzyskania informacji.