NAT źródłowy ukrywa adresy klientów przed późniejszą zaporą

Reguła napisana dla klientów personelu i laboratorium trafia na nową zaporę brzegową i po cichu pasuje do wszystkiego albo do niczego. Przyczyna jest wyżej: brama już przepisała adresy klientów, więc reguła widzi jeden adres tranzytowy zamiast dwóch grup. Dodanie urządzenia nie przywraca informacji, którą usunęła ścieżka. Znajdź ostatni punkt, w którym rozróżnienie jeszcze istnieje, zanim napiszesz politykę.

Dlaczego reguła brzegowa widzi jeden adres

Tłumaczenie wielu na jeden przypisuje każdą wewnętrzną parę adresu i portu do wspólnego adresu zewnętrznego z przydzielonym portem. Rozmowy pozostają rozróżnialne dla translatora dzięki tym powiązaniom portów, ale urządzenie niżej, wykonujące proste dopasowanie prefiksu źródłowego, widzi tylko wspólny adres. To wystarcza, by dwie grupy były identyczne w regule. Pakiety nadal docierają; grupowanie nie.

Sprawdź, co interfejs zapory faktycznie obserwuje, a nie co obiecuje schemat. Oba różnią się częściej, niż ktokolwiek się spodziewa.

Znajdź ostatnią egzekwowalną tożsamość

Zacznij w punkcie egzekwowania i idź wstecz, aż pojawi się pierwotny prefiks. Granicę zwykle znajdują dwa polecenia.

iptables -t nat -L POSTROUTING -n -v
conntrack -L -s 10.90.0.2 | head

Tabela NAT pokazuje, który ruch jest tłumaczony i przez którą regułę, a lista conntrack pokazuje pierwotne i przetłumaczone pary dla aktywnych przepływów. Tam, gdzie zapora wyżej widzi zawsze tylko przetłumaczony adres, reguły źródłowe dla grup nie mogą działać, niezależnie od tego, jak są napisane. Idź ścieżką do przodu lub do tyłu, aż dotrzesz do urządzenia, na którym dwa prefiksy klientów pozostają różne. Zapisuj źródło na każdym skoku, zamiast ufać etykiecie wewnątrz lub na zewnątrz.

Trzy miejsca i ile kosztuje każde

Polityka może mieszkać na bramie tłumaczącej, gdzie pierwotne źródła są jeszcze widoczne. Może mieszkać na zaporze wyżej, jeśli tranzyt staje się routowany, a nie tłumaczony, co oznacza dodanie tras powrotnych i usunięcie przepisywania źródła. Albo można ją egzekwować na tożsamości, a nie na adresach, przez uwierzytelnioną kontrolę, która zna użytkownika lub urządzenie. Każdy wybór ma właściciela i tryb awarii, a tylko dwa pierwsze utrzymują regułę wyłącznie o adresach źródłowych.

Cokolwiek wybierzesz, udokumentuj regułę razem z adresem, do którego pasuje. Reguła, której założenie o adresie po cichu się zmieniło, jest gorsza niż brak reguły, bo nadal pasuje do ruchu, chroniąc coś zupełnie innego.

Akceptacja: jeden dozwolony i jeden odrzucony klient

Przetestuj z parą klientów, po jednym z każdej grupy, i zapisz, jak każdy dociera do punktu egzekwowania. Zachowaj obie pary obok wyniku reguły, aby dowód pokazał, że rozróżnienie przetrwało, a nie że istnieje inna zapora. Powtórz test po zmianie NAT lub routingu, bo przedstawiany adres to część, która po cichu się psuje. Utrzymuj uwierzytelnianie wszędzie tam, gdzie trzeba odróżnić ludzi, ponieważ adres źródłowy jest wejściem polityki, a nie dowodem tożsamości.

Zapisz punkt egzekwowania, zaobserwowane źródło i regułę w zgłoszeniu. Inaczej następny inżynier doda drugą zaporę i tę samą regułę.