WireGuard działa na danych komórkowych, ale nie w tej samej sieci wifi

Tunel wstaje na danych komórkowych, a potem zatrzymuje się na łączeniu w domu, z tym samym profilem, tym samym kluczem peer i bez zmiany konfiguracji pomiędzy. Różnica tkwi w drodze: żądanie z wnętrza LAN do publicznego adresu routera to nie ta sama podróż co żądanie przychodzące z internetu. Większość bram domowych albo w ogóle nie implementuje ścieżki powrotnej, albo robi to tylko dla niektórych protokołów. Przez to objaw wygląda jak zepsuty klucz, choć w kluczu nic się nie zmieniło. Ustal, która ścieżka zawiodła, zanim dotkniesz klucza, przekierowania portu lub profilu klienta.

Jeden adres, dwie różne ścieżki

Z zewnątrz pakiet dociera do publicznego adresu routera, a reguła przekierowania portu przekazuje go nasłuchowi WireGuard na hoście wewnętrznym. Od wewnątrz klient wybiera ten sam publiczny adres, więc pakiet opuszcza klienta, dociera do routera i musi zostać zawrócony w stronę LAN. Właśnie na tym zawróceniu dwie ścieżki się rozchodzą, bo router musi przetłumaczyć przepływ, który jednocześnie wychodzi i ponownie wchodzi przez ten sam interfejs. Wiele implementacji go odrzuca zamiast tłumaczyć, a klient czeka wtedy na uścisk dłoni, który nigdy nie został wysłany.

Takie zachowanie nazywa się zwykle NAT loopback lub hairpinning i należy do routera, a nie do WireGuard; RFC 4787 opisuje przypadki tłumaczenia, w których brama może je obsługiwać albo nie. Sam WireGuard nie ma zdania o ścieżce, bo widzi tylko pakiety docierające do jego interfejsu. Gdy router odrzuci przepływ, demon nigdy niczego nie otrzymuje, klient zgłasza przekroczenie czasu uścisku dłoni, a dziennik serwera pozostaje pusty. Pusty dziennik jest więc wskazówką, gdzie zatrzymał się pakiet, a nie dowodem, że serwer padł. To także powód, dla którego ponowna instalacja niczego nie zmienia.

Odwrotność też się liczy: dziennik serwera pokazujący próbę uścisku dłoni z adresu LAN dowodzi, że pakiet dotarł i ścieżka jest w porządku, co przenosi śledztwo na klucze i dozwolone adresy. Czytaj dziennik po to, co dowodzi, a nie po to, co miałeś nadzieję zobaczyć.

Najpierw odtwórz, potem zmieniaj

Przetestuj z autoryzowanej sieci zewnętrznej z tym samym urządzeniem i tym samym profilem, a następnie powtórz test wewnątrz LAN, niczego nie edytując. Ukończony uścisk dłoni na zewnątrz i klient, który wewnątrz nigdy nie opuszcza urządzenia, odtwarzają warunek zamiast go zgadywać. Obie próby muszą używać tego samego profilu, inaczej porównanie niczego nie dowodzi.

Następnie sprawdź, na co rozwiązuje się nazwa punktu końcowego dla tego urządzenia. Trzy poniższe polecenia pokazują też, jaki adres klient faktycznie wybrał:

wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net

Pierwsze polecenie podaje punkt końcowy, którego interfejs używa teraz, a pozostałe dwa pokazują, na co nazwa rozwiązuje się na tej maszynie. Klient wybierający publiczny adres, gdy siedzi w tej samej sieci co serwer, korzysta ze ścieżki hairpin. Klient wybierający adres LAN tego nie robi, a awaria tam należy do innego śledztwa. Ta różnica decyduje, czy następna sekcja w ogóle obowiązuje.

Obsługiwane sposoby dotarcia do bliskiego serwera

Najczystszym rozwiązaniem jest odpowiedź z rozdzielonym horyzontem: publiczna nazwa rozwiązuje się na publiczny adres dla internetu i na adres LAN serwera dla klientów wewnątrz. Profil trzyma jedną nazwę punktu końcowego, a resolver wybiera ścieżkę. To wymaga kontroli nad wewnętrzną odpowiedzią DNS, którą router domowy zwykle oferuje, a organizacja może urządzić celowo. Bez tej kontroli zostają funkcja routera albo drugi profil.

Funkcją routera jest odbicie: brama tłumaczy przepływ z wnętrza na zewnątrz i odsyła go do środka. Tam, gdzie działa, nie wymaga zmiany klienta, a tam, gdzie nie działa, żadne ustawienie klienta jej nie uratuje. Przetestuj ją, obserwując dziennik serwera podczas wewnętrznej próby, zamiast czytać listę funkcji routera.

Edycja profilu na adres prywatny to diagnostyka, nie projekt. Dowodzi, że serwer odpowiada w LAN, i psuje ten sam profil w chwili, gdy laptop wyjeżdża z domu.

Utrzymaj profil użyteczny poza domem

Niezależnie od wybranej ścieżki nie ruszaj weryfikacji tożsamości. Adres punktu końcowego to nie tożsamość peer, a zmiana adresu nigdy nie uzasadnia przyjęcia obcego klucza publicznego, który przypadkiem odpowiada. WireGuard uwierzytelnia kluczem, więc błędny host zawodzi na uścisku dłoni, zamiast dawać dostęp do czegoś nieoczekiwanego.

Jeśli publiczny adres się przesuwa, to dynamiczny DNS utrzymuje nazwę użyteczną, a zachowanie odświeżania klienta decyduje, jak szybko zmiana dotrze. Przetestuj to z zewnątrz po zmianie adresu, bo przypadek LAN tego nie potwierdzi. Uważaj na resolver, który buforuje starą odpowiedź dłużej niż czas życia rekordu. Nazwa wciąż wskazująca poprzedni adres wygląda dokładnie jak serwer, który padł.

Zapisz, jakiej nazwy używa profil i na co rozwiązuje się ona po każdej stronie granicy. Profil zależny od funkcji routera, której nikt nie zapisał, to zgłoszenie do wsparcia czekające na następną aktualizację firmware. Notatka mówi też następnej osobie, czy wewnętrzna awaria to znany przypadek hairpin, czy coś nowego.