Domowy serwer VPN nieosiągalny: przejdź łańcuch NAT

Serwer odpowiada w sieci LAN, reguła przekierowania portu wygląda poprawnie, a zewnętrzny klient nadal nie może się połączyć. Przechodzenie jednej granicy naraz na zewnątrz jest szybsze niż czwarta edycja reguły, ponieważ każda granica zostawia własny dowód: strona WAN routera, tłumaczenie u dostawcy i nasłuch na hoście. Zacznij od strony administracyjnej, którą już masz otwartą, a skończ na teście z sieci, której nie kontrolujesz. Zapisuj każdy wynik na bieżąco, bo kolejność jest diagnozą, a zapamiętana liczba nie jest dowodem. Jeśli potrzebujesz tylko tunelu wychodzącego, tłumaczenie nie jest twoim problemem: blokowany jest wyłącznie niechciany ruch przychodzący.

Zacznij od strony WAN routera

Zaloguj się do routera i czytaj stronę stanu, a nie listę przekierowań portów. Zapisz adres WAN, interfejs, do którego należy, i czy typ połączenia to DHCP, PPPoE czy coś zapewnianego przez dostawcę. Następnie porównaj ten adres z tym, co zgłasza zewnętrzna usługa, używając telefonu na danych mobilnych, aby obserwacja nie wracała przez ten sam router. Obie liczby odpowiadają na różne pytania, a ich porównanie jest całym sensem tego kroku.

Adres WAN różny od zaobserwowanego adresu publicznego oznacza, że nad routerem stoi co najmniej jeden tłumacz. To jeszcze nie usterka, bo wielu dostawców tłumaczy z założenia, a usługa nadal działa. Jeśli oba się zgadzają, adres prawdopodobnie należy do routera, a problem przeniósł się do wnętrza twojej sieci. W każdym razie zapisz parę z datą, bo dostawcy przydzielają adresy ponownie, a porównanie z notatkami z zeszłego miesiąca jest bezwartościowe.

Przejdź jeden skok wyżej

Uruchom traceroute z samego routera i przeczytaj pierwsze skoki. Powtarzające się adresy publiczne, pierwszy skok odpowiadający adresem prywatnym lub adres we współdzielonym zakresie 100.64.0.0/10 wskazują na tłumacza wyżej. RFC 6598 definiuje ten zakres właśnie dla takiego wdrożenia, dlatego zobaczenie go w polu WAN jest silnym sygnałem, a nie ciekawostką. Dwa tłumacze na ścieżce czynią ślad mniej oczywistym, więc czytaj wzorzec, a nie pojedynczą linię.

Niektórzy dostawcy pokazują przydzielony adres tylko w portalu klienta, więc zajrzyj tam, zanim stwierdzisz, że router kłamie. Adres w portalu zgodny z twoją obserwacją zewnętrzną, podczas gdy router zgłasza coś innego, jest najjaśniejszym dowodem tłumacza wyżej. Zachowaj obie strony w dzienniku zmian, bo spór o to, kto posiada którą granicę, idzie znacznie szybciej z dwoma datowanymi obrazami.

Potwierdź nasłuch i przekierowanie

Test w sieci LAN dowodzi, że usługa działa lokalnie, i nie dowodzi niczego o dostępności z zewnątrz. Wiele routerów odpowiada na własną regułę przekierowania od wewnątrz, więc test pętli udaje się, mimo że ścieżka zewnętrzna jest wciąż zamknięta. Potwierdź, że demon jest przypisany do adresu i portu, których się spodziewasz, a potem testuj z zewnątrz. Wszystko poniżej służy tylko do czytania.

ss -lunp | grep -E '1194|51820'
ip -4 addr show | grep -E 'inet '
curl -s --max-time 5 ifconfig.me
traceroute -n -m 5 1.1.1.1

Jeśli test zewnętrzny pokazuje, że żaden pakiet nie dociera do routera, strata nastąpiła wyżej i żadna lokalna reguła tego nie naprawi. Jeśli pakiety docierają, a nic nie odpowiada, następną granicą jest nasłuch lub zapora hosta. Przechwycenie pakietów na hoście rozstrzyga, który z tych dwóch widzisz, i zajmuje mniej czasu niż kolejna runda zgadywania reguł. Podczas porównywania zostaw nasłuch i jego transport bez zmian, inaczej następny test odpowie na inne pytanie.

Zmień topologię, a nie tę samą regułę

Gdy tłumacz należy do dostawcy, rozwiązaniem jest inna ścieżka, a nie kolejne przekierowanie. Mały VPS z publicznym adresem, połączony tunelem wychodzącym od strony domu, stawia przed usługą osiągalny punkt końcowy. Publiczny adres od dostawcy jest prostszy tam, gdzie istnieje, i zwykle tańszy niż utrzymywanie maszyny. IPv6 usuwa tłumaczenie całkowicie, pod warunkiem że sieć klienta, rekordy DNS i polityka zapory wszystkie to obsługują.

Dynamiczny DNS aktualizuje tylko nazwę; nie tworzy osiągalności, a wskazanie na współdzielony adres wysyła klientów do bramy dostawcy, z której korzystają też inni abonenci. Ta awaria wygląda dokładnie jak martwy serwer, dlatego zapis z wcześniejszych kroków ma znaczenie. Zanotuj, na jaki adres nazwa się rozwiązała, gdy test zawiódł, i trzymaj odpowiedź razem z wynikiem testu.

Przepisz plan wokół granicy, którą kontrolujesz: nasłuchu, tunelu i tras. Stare przekierowanie zostaw tylko dopóki opisuje coś prawdziwego, bo reguła, która nie pasuje już do topologii, jest gorsza niż brak reguły. Zapisz, która warstwa faktycznie blokowała i jaki dowód to pokazał. Inaczej następna osoba, która otworzy stronę administracyjną, powtórzy każdy krok tego przejścia od początku.