Dwaj klienci VPN, dwa publiczne adresy: dopasuj SNAT

Dwaj klienci VPN mogą wychodzić przez dwa różne publiczne adresy IPv4, a reguła, która to robi, jest krótsza, niż większość się spodziewa. Działa nie dzięki składni iptables, ale dzięki stanowi pakietu, gdy dociera on do łańcucha wyjścia: adres źródłowy musi tam nadal rozróżniać klientów. Jeśli wcześniejszy masquerade połączył już oba na jednym adresie, żadna reguła dla klienta nie odtworzy rozróżnienia. Najpierw rozstrzygnij tę kwestię, potem napisz tłumaczenie.

Która tożsamość dociera do bramy

Reguła dopasowuje adres źródłowy pakietu, a nie nazwę użytkownika VPN ani nazwę wyświetlaną przez aplikację klienta. Wszystko, co tłumaczy pakiet wcześniej na ścieżce, decyduje o tym, co reguła może jeszcze zobaczyć. Uruchom tabelę nat po kolei i znajdź punkt, w którym źródło jest nadal osobne dla każdego klienta.

iptables -t nat -S POSTROUTING

Przeczytaj tę listę od góry. Reguła masquerade blisko góry przepisuje źródło dla każdego pasującego przepływu, a wpisy dla poszczególnych klientów umieszczone po niej pasują do adresu, którego już nie ma. Gdy dwa urządzenia LAN dzielą jeden tunel i przychodzą jako jeden adres wewnętrzny, projekt musi się zmienić przed zaporą: utrzymuj ich zakresy źródłowe osobno lub daj każdemu własny adres wewnętrzny.

Powiąż przypisanie adresu wewnętrznego z uwierzytelnionym klientem. Przekazanie tego adresu innemu urządzeniu przekazuje też politykę wyjścia, a tłumaczenie źródła samo w sobie nie jest dowodem tożsamości.

Tłumaczenie nie może wymyślić adresu

Każdy publiczny adres musi być przypisany lub routowany do tego punktu wyjścia, a odpowiedzi muszą znaleźć drogę powrotną. Reguła, która wysyła ruch z adresu, do którego nikt nie routuje z powrotem, jest odrzucana na drugim końcu lub odpowiada hostowi, który o to nie prosił. Instancja u dostawcy chmury zwykle ma publiczny adres przetłumaczony na adres prywatnego interfejsu, zanim pakiet wyjdzie, więc źródłem SNAT musi być adres, który dostawca zaakceptuje, a nie wartość pokazywana przez konsolę. Przeczytaj model adresów dostawcy i podążaj za nim, zamiast kopiować publiczną wartość do każdego pakietu.

W praktyce oznacza to sprawdzenie routowanego prefiksu w konsoli dostawcy przed dotknięciem zapory oraz użycie adresu prywatnego interfejsu jako źródła tłumaczenia, gdy mapowanie jest jeden do jednego. Adresy w poniższych przykładach pochodzą z zakresów dokumentacyjnych, więc pierwszą rzeczą do zastąpienia jest sam tekst adresu.

Wstaw przed ogólnym masquerade

Potwierdź interfejs wyjścia i bieżący łańcuch, zanim cokolwiek dodasz. Pierwszy decyduje, które pakiety reguła może dopasować, a drugi pokazuje, co już przed nią stoi.

ip -4 route show default
iptables -t nat -L POSTROUTING -n -v --line-numbers

Pierwsze polecenie wskazuje interfejs, przez który pakiet do internetu faktycznie wychodzi. Drugie wypisuje łańcuch z numerami linii. Ogólny wpis masquerade to linia, nad którą trzeba pozostać.

iptables -t nat -I POSTROUTING 1 -s 10.88.4.20/32 -o ens3 -j SNAT --to-source 198.51.100.77
iptables -t nat -I POSTROUTING 1 -s 10.88.4.21/32 -o ens3 -j SNAT --to-source 198.51.100.78

Obie powyższe reguły dopasowują po jednym adresie wewnętrznym, ograniczają dopasowanie do interfejsu wyjścia i jawnie ustawiają źródło. Wstawiaj, a nie dodawaj: na pozycji 1 są oceniane przed linią masquerade. Kolejność między nimi nie ma znaczenia, bo ich źródła się różnią. Zastąp ens3 tym, co zgłosiło polecenie trasy, i trzymaj innych menedżerów zapory z dala od tych samych hooków, bo dwa narzędzia piszące jedną tabelę to zwykły powód, dla którego poprawna reguła nie działa.

Udowodnij źródło nowym przepływem

Stateful NAT wiąże tłumaczenie, gdy przepływ się zaczyna, i używa go ponownie dla późniejszych pakietów, więc sesja otwarta przed zmianą zachowuje stare źródło po zmianie. Tylko nowo nawiązane połączenie dowodzi reguły.

conntrack -L -s 10.88.4.20 -p tcp --dport 443

Odczytaj kierunek odpowiedzi tego wpisu: jego celem jest adres, który zdalny punkt widzi jako źródło. Porównaj go z zamierzonym publicznym adresem i potraktuj wpis ze starym adresem jako dowód przepływu rozpoczętego zbyt wcześnie, a nie zepsutej reguły. Poproś klienta o otwarcie nowego połączenia, a następnie powtórz zapytanie. Wyczyszczenie całej tabeli śledzenia, aby wymusić test, przerywa każdą inną sesję na bramie.

Tłumaczenie nadal nie wybiera trasy, nie przepuszcza przepływu przez filtr i nie publikuje usługi przychodzącej. Błędna trasa i brakująca reguła zezwolenia nadal zawodzą po idealnej regule SNAT. Sprawdź także IPv6 i każdą drugorzędną ścieżkę wyjścia, a potem zapisz pary wewnętrzny-do-publicznego w dokumentacji zapory, aby następna zmiana zaczynała się od mapowania, a nie od tekstu reguły.