Czy należy stosować SNAT przy przekierowaniu portu do podsieci VPN?

Przekierowanie portu do hosta, który stoi za własnym klientem VPN routera, kończy się niepowodzeniem w sposób wyglądający jak problem z zaporą sieciową, ponieważ żądanie wyraźnie dociera. Usługa zapisuje połączenie, klient czeka, a nic nie wraca. Tłumaczenie miejsca docelowego zrobiło swoje; pakiet powrotny to ta część, która zniknęła. Jedna selektywna reguła źródłowego NAT na routerze to naprawia, a ciekawą częścią jest decyzja, jak wąska może być ta reguła.

Dlaczego odpowiedź idzie inną drogą

Przekierowanie portu przepisuje, dokąd idzie pakiet, nigdy skąd przyszedł. Adres klienta internetowego pozostaje w polu źródłowym przez całą drogę przez tunel, więc zdalna usługa widzi obcego i odpowiada w jedyny znany sobie sposób: przez własną bramę domyślną. Ta brama to koncentrator VPN po drugiej stronie, który nie ma trasy powrotnej do dowolnego publicznego adresu.

Obejrzyj przechwycenie na interfejsie tunelu, a asymetria jest oczywista: pakiety żądania na zewnątrz, nic do środka. Łańcuch przekierowania pozwolił na przepływ, a tunel go przeniósł, więc odrzucenie następuje po tym, jak zdalny host już wybrał drogę powrotną.

Reguła źródłowa wystarczająco wąska, by jej zaufać

Uczyń router źródłem, na które odpowiada zdalny host. W tym układzie adres WAN to 203.0.113.24, LAN to 192.168.88.0/24, adres tunelu routera to 172.20.5.1, a usługa odpowiada na 172.20.5.40:8443. Poniższa reguła dopasowuje pakiet po tłumaczeniu miejsca docelowego, dlatego wymienia adres przetłumaczony, a nie publiczny. Nic w niej nie zależy od adresu klienta i dokładnie o to chodzi.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Każde dopasowanie w tej linii istnieje po to, by przepisywanie pozostało lokalne dla jednej usługi na jednym tunelu. Usuń interfejs lub port, a przepiszesz więcej ruchu, niż wymaga problem, i tak ukierunkowana poprawka staje się zagadką dla następnej osoby.

Kiedy zbiorcza maskarada jest uczciwym wyborem

Jeśli router przekierowuje wiele usług do tej samej podsieci VPN, reguła na usługę staje się listą, której nikt nie utrzymuje. Maskowanie wszystkiego, co opuszcza interfejs tunelu, jest prostsze i przewidywalne, za cenę ukrycia oryginalnego klienta przed każdym hostem po drugiej stronie. Wybierz to, gdy tamtejsze logi nie służą do przypisywania; zachowaj wąską regułę, gdy służą.

Obie opcje zawodzą też inaczej. Brak wąskiej reguły psuje jedną usługę; szeroka maskarada, która dopasowuje zbyt wiele, może po cichu przepisać ruch, który już działał, w tym własne połączenia wychodzące routera.

Sprawdź liczniki przed publikacją

Reguły, które nigdy nie pasują, wyglądają identycznie jak reguły działające, dopóki nie policzysz pakietów. Odczytaj tabelę ponownie z licznikami bajtów, zanim podłączy się jakikolwiek klient, następnie połącz się z sieci, która nie jest LAN, i odczytaj ją jeszcze raz. Dwa odczyty to właśnie to, co zamienia przypuszczenie w fakt. Opublikuj przekierowanie dopiero po tym, jak drugi się zmieni.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Zerowy licznik na regule źródłowej po rzeczywistym połączeniu oznacza, że dopasowanie jest błędne, zwykle dlatego, że miejsce docelowe lub port nie pasują do pakietu po tłumaczeniu. Jeśli licznik rośnie, ale klient wciąż kończy się przekroczeniem czasu, droga powrotna jest naprawiona i coś innego odrzuca odpowiedź, więc sprawdź następnie politykę przekierowania po drugiej stronie. Dostęp przez zawiniętą pętlę z wnętrza LAN to osobny problem i wymaga własnej reguły, a nie szerszej wersji tej.