VPN na routerze czy przekierowanie portu: co wygrywa?

Router sam kończy VPN, a stara reguła przekierowania nadal wysyła ten sam port UDP do maszyny w sieci LAN. Tylko jedno z nich może być prawdziwym punktem końcowym, a jądro nie rozstrzyga między nimi. Tłumaczenie celu przepisuje pakiet, zanim zapytana zostanie usługa lokalna, więc proces VPN czeka na ruch, który już wysłano gdzie indziej. Zadanie polega na ustaleniu, kto jest właścicielem portu, a następnie uzgodnieniu reguł.

Jeden port, dwóch zgłaszających roszczenia właścicieli

Serwer VPN działający wewnątrz routera potrzebuje zezwolenia przychodzącego, które prowadzi do jego własnego gniazda. Wpis NAT celu dla tego samego portu prowadzi zupełnie gdzie indziej: do adresu LAN i decyzji o przekierowaniu. To różne punkty końcowe z różnymi logami i różnymi trybami awarii. Zwykłą wskazówką jest to, że jedna rodzina adresów działa, a druga nie, ponieważ pozostały wpis napisano dla jednej rodziny i nigdy go nie przejrzano.

Zapisz roszczenie przed edycją: rodzina, adres zewnętrzny, transport, port i przetłumaczony cel.

Tłumaczenie działa przed lokalną kontrolą

NAT celu zmienia cel pakietu na etapie przed trasowaniem, zanim jądro wybierze między dostawą lokalną a przekierowaniem. Gdy cel jest hostem LAN, pakiet idzie ścieżką przekierowania. Reguły wejściowe dla własnego gniazda routera nigdy nie są sprawdzane, dlatego log VPN pozostaje pusty, gdy klient czeka.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Ta kolejność to cały mechanizm, a interfejsy urządzeń ukrywają ją za polami wyboru, nie zmieniając jej. O ścieżce pakietu nadal decyduje właściciel celu.

Jeśli host LAN jest zamierzonym punktem końcowym, przekierowanie jest poprawne i router nie powinien także nasłuchiwać na tym porcie.

Zachowaj jedno mapowanie i usuń drugie

Wypisz wpisy NAT dla tego portu i rodziny i wybierz ocalałego:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Wpis TCP o tym samym numerze jest nieistotny dla awarii UDP, a traktowanie ich jako jednego obiektu prowadzi do usunięcia niewłaściwej reguły. Gdy lokalne gniazdo powinno wygrać, właściciel kolidującego mapowania usuwa lub przepisuje właśnie ten wpis, a zezwolenie przychodzące dla własnego portu routera zostaje na miejscu. Niepowiązane przekierowania, ścieżka zarządzania i kopia zestawu reguł powinny przetrwać zmianę.

Jeśli VPN mieszka na osobnym hoście, przekierowanie jest właściwym obiektem. Usługa w kontenerze lub maszynie wirtualnej może potrzebować opublikowanego portu, nawet gdy pudełko nazywa się routerem, więc śledź gniazdo i jego przestrzeń nazw, a nie etykietę na obudowie.

Potwierdź właściciela z zewnątrz

Testuj każdą rodzinę osobno, ponieważ połączenie IPv6 kończące się na routerze nic nie mówi o połączeniu IPv4, które przekierowuje stara reguła. Przeczytaj log usługi odbierającej, aby zobaczyć, który punkt końcowy odpowiedział, a komunikat o sukcesie klienta traktuj jako słaby dowód. Do sensownego testu potrzebny jest nowy przepływ. Wyślij sondę z zewnętrznego hosta za pomocą nc -zvu 203.0.113.7 1194 i przeczytaj log zwycięzcy za pomocą journalctl -u openvpn@server -n 20. Słuchacz routera sam rejestruje połączenie, a host LAN rejestruje je we własnej usłudze.

Śledzenie połączeń utrzymuje istniejące przepływy na ich pierwotnym mapowaniu, więc ustanowiona sesja może przeżyć regułę, którą właśnie naprawiłeś.

Gdy zamierzony punkt końcowy odpowie swoimi zwykłymi kontrolami tożsamości, przetestuj prywatny zasób za tunelem. Dotarcie do zewnętrznego słuchacza to dopiero pierwszy krok; trasowanie wewnętrzne i autoryzacja aplikacji to osobne wyniki.