Wyzwalanie portów a przekierowanie portów dla domowego serwera VPN

Przekierowanie portów i wyzwalanie portów znajdują się w tym samym menu na większości domowych routerów, dlatego traktuje się je jako dwa sposoby na zrobienie jednej rzeczy. Przekierowanie to reguła statyczna: połączenie przychodzące na port WAN jest tłumaczone na stały adres i port wewnętrzny, niezależnie od tego, czy dzieje się coś jeszcze. Wyzwalanie jest warunkowe: router obserwuje ruch wychodzący i otwiera mapowanie przychodzące dopiero po wyjściu pasującego połączenia. Serwer VPN czeka, aż ktoś inny połączy się pierwszy, więc właśnie ten warunek jest jedyną rzeczą, której nigdy nie może spełnić.

Dwie reguły o różnych cyklach życia

NAT w IPv4 jest stanowy. Gdy host wewnętrzny wysyła pakiet na zewnątrz, router tworzy mapowanie, aby odpowiedzi znalazły drogę powrotną; pakiet przychodzący, który nie pasuje do żadnego mapowania, jest odrzucany, i to właśnie to zachowanie trzyma niezałatany komputer z dala od internetu. Przekierowanie to trwały wpis tłumaczenia dodawany ręcznie. Wyzwalanie to tymczasowa dziura strzeżona przez wzorzec ruchu.

Praktyczna różnica to czas. Przekierowanie istnieje od chwili zapisania, dopóki ktoś go nie usunie. Wyzwolone mapowanie istnieje po zadziałaniu wyzwalacza i zamyka się po upływie licznika bezczynności, mierzonego w minutach na sprzęcie konsumenckim, albo natychmiast przy ponownym uruchomieniu.

Żadne z nich nie jest bezpieczniejsze w ujęciu abstrakcyjnym. Przekierowanie wystawia jeden port bez przerwy; wyzwalacz wystawia go dopiero po określonym ruchu wychodzącym. Dla usługi, która musi przyjąć pierwszy pakiet od obcego, pasuje tylko jedno z tych dwóch.

Dlaczego wyzwalanie nie opublikuje serwera

Serwer VPN jest z założenia pasywny. Druga strona, czy to laptop w kawiarni, czy telefon na danych komórkowych, wysyła pierwszy pakiet, a router nie ma dla niego mapowania. Nic w środku nie rozpoczęło ruchu do portu wyzwalacza, więc reguła nigdy nie zadziała, a połączenie ginie, zanim zacznie się uzgadnianie.

Tam, gdzie wyzwalanie wygląda na działające, ruch na porcie wyzwalacza generuje coś innego: klient w sieci LAN, sonda monitorująca albo własne kontrole wychodzące serwera. Wtedy mapowanie otwiera się dla tego jednego hosta i zamyka, gdy ruch ustanie, więc kolejna zewnętrzna strona znów zawodzi, a pierwszy sukces leży w logu i wygląda jak dowód.

Wyzwalanie zwykle dotyczy też jednego hosta. Wiele implementacji pozwala trzymać mapowanie tylko jednemu urządzeniu wewnętrznemu naraz, co jest dokładnie niewłaściwe dla serwera, który ma odpowiadać kilku stronom. Funkcja powstała dla aplikacji, które otwierają połączenie sterujące na zewnątrz i oczekują danych przychodzących na drugim porcie, i nadal pasuje do tego kształtu.

Co przekierowanie naprawdę mapuje

Przekierowanie to jeden wpis tłumaczenia: port i protokół WAN na adres i port wewnętrzny. Potrzebuje nasłuchu, który już działa po drugiej stronie, i potrzebuje, aby adres wewnętrzny został na miejscu. Dzierżawa DHCP, która przeniesie się na inną maszynę, po cichu wysyła każdy tunel do niewłaściwego hosta, więc utwórz rezerwację przed regułą.

Protokół jest ważniejszy, niż sugeruje formularz. OpenVPN po UDP wymaga przekierowania UDP, WireGuard wymaga UDP, a dane IPsec przychodzą jako ESP, protokół IP 50, który w ogóle nie ma portów. Formularz przekierowania, który przyjmuje tylko TCP albo UDP, nie potrafi tego wyrazić, więc IPsec wymaga passthrough lub statycznego mapowania jeden do jednego zamiast reguły portu.

Warstwa nad twoim routerem

Przekierowanie steruje wyłącznie tłumaczeniem, które należy do ciebie. Jeśli adres WAN nie jest twój, co ma miejsce za NAT operatora, gdzie abonenci dzielą 100.64.0.0/10, jak opisano w RFC 6598, połączenie przychodzące nigdy nie dotrze do twojego routera, bo dostawca przetłumaczył pierwszy. Żadna reguła na twoim urządzeniu nie naprawi tej kolejności.

Podwójny NAT to ten sam problem w miniaturze. Twój router przekierowuje do routera dostawcy internetu, który nie ma pasującej reguły i odrzuca pakiet. Albo dodaj regułę na zewnętrznym urządzeniu, albo ustaw je w trybie mostu i pozwól swojemu trzymać publiczny adres.

Dlatego test musi przyjść z zewnątrz. Test z tej samej sieci LAN przez publiczny adres zależy od obsługi hairpin NAT i może się udać lub nie z powodów niezwiązanych z regułą; telefon na danych komórkowych albo znajomy w innej sieci to czystsza kontrola.

Ogranicz regułę, a potem zweryfikuj obie połowy

Przekieruj jeden port na jeden adres. Zakres dodany dlatego, że pierwsze próby zawiodły, to droga, którą interfejsy zarządzania trafiają do internetu, a nasłuch VPN nie potrzebuje obok siebie opublikowanej strony administracyjnej routera.

Zachowaj wszystko, co już chroniło ten nasłuch: tożsamość opartą na certyfikacie lub kluczu, firewall hosta, aktualne wersje pakietów. Przekierowanie wpuszcza pakiet; uwierzytelnianie decyduje, czy pakiet stanie się tunelem, i to są dwa odrębne błędy, gdy coś pójdzie nie tak.

Weryfikacja ma dwie połowy. Uzgadnianie musi się zakończyć z zewnętrznej sieci, a potem prywatny zasób za serwerem musi odpowiedzieć przez tunel. Przekierowanie wpuszcza połączenie tunelu i nic więcej; routing i autoryzacja dla 10.8.0.0/24 to inne ustawienie na innym ekranie.

Zdecyduj trzema pytaniami

Trzy pytania rozstrzygają wybór szybciej niż jakakolwiek tabela porównawcza:

• Czy coś łączy się z zewnątrz jako pierwszy pakiet? Wtedy użyj przekierowania albo przekaźnika. Wyzwalanie nie otworzy się bez ruchu wychodzącego, którego nigdy nie będzie.
• Czy dziura musi przetrwać czas bezczynności? Wtedy użyj przekierowania, bo wyzwolone mapowanie zamyka się według własnego harmonogramu.
• Czy adres WAN jest twój, żeby go publikować? Jeśli nie, napraw warstwę wyżej, zanim edytujesz jakąkolwiek regułę.

Jeśli odpowiedź na wszystkie trzy brzmi nie, co jest przypadkiem laptopa samodzielnie łączącego się z komercyjnym dostawcą, żadna z reguł nie jest potrzebna. Klient za NAT działa, bo sam tworzy mapowanie stanowe, i to obejmuje większość osób czytających stronę o przekierowaniu portów o północy.