VPN za NAT, którego nie możesz skonfigurować: co nadal działa

Każdy punkt końcowy tunelu potrzebuje adresu i portu, do których druga strona może dotrzeć, a router, którym nie administrujesz, jest zwykłym powodem, dla którego ten wymóg zawodzi. Ciekawe nie jest to, że istnieją sztuczki, ale to, że każda zależy od właściwości tablicy mapowania, której nie widzisz z klienta. Dwie z tych właściwości decydują o prawie wszystkim: jak powstaje mapowanie i czy przyjmuje pakiety z adresu, z którym wnętrze nigdy się nie kontaktowało. Posortuj środowisko według tych właściwości, a obejścia przestaną być folklorem.

Tablica mapowania decyduje o wszystkim

Tłumaczenie adresów sieciowych prowadzi tablicę, w której wewnętrzny adres i port są zapisane naprzeciw publicznego adresu i portu. Odpowiedzi pasujące do wpisu są tłumaczone z powrotem, a pakiet przychodzący z zewnątrz bez pasującego wpisu nie ma żadnego celu. To jedno zachowanie wyjaśnia, dlaczego nasłuchujący za routerem jest nieosiągalny z internetu. Wyjaśnia też, dlaczego pierwszy pakiet w każdym kierunku musi pochodzić z wnętrza.

Spójrz na tablicę od strony routera, a obejścia stają się oczywiste: albo coś tworzy trwały wpis, albo tworzy tymczasowy i utrzymuje go świeżym, albo ruch nigdy nie idzie tą drogą. Reszta artykułu to te trzy przypadki po kolei. Nic tutaj nie zależy od funkcji producenta poza tym, co zapisuje tablica.

Co może, a czego nie może usługa rendezvous

Hole punching UDP wykorzystuje wpis wychodzący jako tymczasowe otwarcie, zamiast pokonywać filtr. Obaj partnerzy kontaktują się z usługą rendezvous, która poznaje każdy publiczny punkt końcowy i zwraca drugiej stronie jej punkt. Potem obaj wysyłają ku sobie, a każdy pakiet wychodzący tworzy lub odświeża wpis, który wpuszcza odpowiedź. Kolejność jest tym, co sprawia, że to działa, i kolejność jest też tym, co czyni to kruchym: partner, który wyśle, zanim druga strona utworzy swój wpis, jest po prostu odrzucany, podczas gdy ponowna próba chwilę później się udaje. Usługa sama nie przenosi ruchu VPN, więc jej jedyną dźwignią jest koordynowany czas.

Zachowanie mapowania decyduje o reszcie, a RFC 4787 wymienia trzy formy: niezależną od punktu końcowego, zależną od adresu oraz zależną od adresu i portu. W ostatniej port, na który partner musi celować, zmienia się z każdym celem, więc przewidywanie przestaje być wiarygodne. Tu technika trafia w ślepy zaułek, ponieważ NAT klasy operatorskiej i ścisła zapora korporacyjna obie usuwają przewidywalność, której schemat potrzebuje, i żadna liczba ponownych prób jej nie przywraca.

Keepalive, restarty i punkt końcowy, który się przesuwa

Przebita ścieżka to przepływ, a nie nasłuch, więc wszystko, co po niej działa, musi przetrwać zmianę. Musi utrzymywać mapowanie przy życiu okresowym ruchem, zauważać, kiedy publiczny punkt końcowy się przesuwa, i odbudowywać się po restarcie routera lub ponownym przydzieleniu adresu. Produkty mesh VPN umieszczają tę logikę we własnej płaszczyźnie sterowania, a zwykły serwer zostawia ją tobie. Keepalive pomagają tylko dopóki przetrwa to samo mapowanie, i zużywają baterię na kliencie mobilnym, dlatego agresywny interwał nie jest darmowy.

Laptop, który śpi godzinę, zwykle wraca na innym publicznym punkcie końcowym. Wszystko, co odbudowuje ścieżkę, musi znów działać od wewnątrz, co przywraca ten sam wymóg po stronie klienta.

Trzy sposoby obejścia brakującego przekierowania

Pierwszy sposób prosi router, aby sam utworzył wpis, przez UPnP IGD, NAT-PMP lub PCP, gdy funkcja istnieje i jest włączona. Drugi oddaje ruch przekaźnikowi z publicznym adresem, co zawsze działa i zawsze kosztuje pasmo plus inną granicę zaufania. Trzeci odwraca kierunek: wewnętrzny host otwiera tunel wychodzący do publicznego serwera, a wszystko inne jedzie w jego wnętrzu.

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

Punkt końcowy przekaźnika czyni tę wymianę widoczną w konfiguracji klienta, gdzie punktem końcowym jest przekaźnik, a nie własny adres partnera. Trwały keepalive utrzymuje mapowanie ciepłe, a dozwolone prefiksy decydują, co klient może przez nie wysłać. Tunel odwrotny z wewnętrznego hosta to ten sam pomysł z innym właścicielem i nie wymaga żadnej zmiany NAT. Każdy z trzech usuwa wymóg ruchu przychodzącego bez pokonywania zapory, która z założenia blokuje nieproszony ruch, bo ruch nadal zaczyna się wewnątrz.

Dopasuj obejście do właściciela routera

Jeśli administrujesz routerem, statyczne przekierowanie UDP jest łatwiejsze do audytu niż jakikolwiek schemat przebijania i zawodzi w sposób, który widzisz. Jeśli nie, sprawdź, czy producent oferuje przekaźnik lub hostowaną płaszczyznę sterowania i czy polityka pozwoliłaby z tego korzystać. Jeśli nic nie jest dostępne, pozostają tunel odwrotny albo akceptacja, że punkt końcowy jest nieosiągalny z zewnątrz. Zapisanie, którego użyto, ma większe znaczenie, niż się wydaje, bo opcje różnią się tym, kto może obserwować ruch i co się dzieje, gdy osoba trzecia coś zmieni.

Zauważ, czy ścieżka, na której skończyłeś, była bezpośrednia, czy przez przekaźnik, bo ten jeden fakt przewiduje zarówno opóźnienie, jak i zachowanie przy awarii. RFC 4787 pozostaje punktem odniesienia dla zachowania mapowania pod tym wszystkim, a czytanie jego sekcji o mapowaniu jest szybsze niż testowanie trzech obejść po kolei. Tablicy nie obchodzi, którą opcję wybrałeś; zapisuje tylko, co wolno zrobić następnemu pakietowi.