WireGuard PersistentKeepalive: utrzymaj mapowanie NAT przy życiu

Domowe pudełko otwiera tunel i bez problemu dociera do serwera w chmurze. Serwer w chmurze może dotrzeć do aplikacji domowej przez minutę lub dwie po tym, jak domowe pudełko ostatnio coś wysłało, a potem przestaje. W logu WireGuard nie pojawia się nic, nie jest zgłaszany żaden błąd uścisku dłoni, a restart tunelu naprawia to na krótko. Ten wzorzec to wygasające mapowanie, a nie zepsuty tunel, i poniższy przewodnik potwierdza to przed zmianą czegokolwiek.

Potwierdź, że wzorzec to wygaśnięcie przy bezczynności

Wyróżniającym szczegółem jest czas. Jeśli połączenie zwrotne działa zaraz po tym, jak domowy peer wyśle ruch, i zawodzi po cichym okresie, ścieżka jest w porządku, a stan pośrodku nie. Jeśli nigdy nie działało, nawet zaraz po ruchu, to błędna diagnoza.

sudo wg show wg0 latest-handshakes
sudo wg show wg0 endpoints
sudo wg show wg0 transfer

Uruchom pierwsze dwa zaraz po tym, jak domowy peer coś wyśle, odczekaj pięć minut i uruchom je ponownie. Znacznik czasu uścisku dłoni, który odświeża się zgodnie z harmonogramem bez nowego punktu końcowego, mówi ci, że tunel żyje. Zmieniła się zdolność nieproszonych pakietów do przychodzenia z zewnątrz, co jest cechą ścieżki, a nie tunelu.

Następnie wykonaj próbę zwrotną i obserwuj liczniki transferu. Jeśli strona chmurowa wysyła bajty, a strona domowa nie odbiera żadnego, pakiet opuścił chmurę i zginął po drodze w urządzeniu utrzymującym stan. To jest sygnatura, której szukasz. Jeśli oba liczniki się poruszają, tunel dostarczył pakiet, a podejrzanym jest aplikacja.

Umieść keepalive na peerze za routerem

Trwałe keepalive utrzymują mapowanie NAT i dowolny stan zapory ogniowej przy życiu, wysyłając zgodnie z harmonogramem mały uwierzytelniony pakiet. Ustawienie należy do maszyny za routerem, do jej wpisu dla zdalnego peera, bo to ta strona swoim pakietem wychodzącym tworzy stan.

[Peer]
PublicKey = <cloud peer public key>
AllowedIPs = 10.71.0.1/32
PersistentKeepalive = 25

Scal je z istniejącą sekcją peera. Dodanie drugiego bloku z tym samym kluczem publicznym nie jest prawidłowym sposobem dodawania opcji, a wg-quick nie scali ich za Ciebie. Udokumentowane 25 sekund to przykład wybrany tak, by mieścić się poniżej typowych limitów UDP, a nie wartość o szczególnym znaczeniu.

Umieszczenie tej samej dyrektywy po stronie chmurowej nie pomaga w tym problemie. Pakiety tego peera i tak przychodzą z publicznego adresu, więc w istotnym kierunku nie ma czego zachowywać. To dodaje ruch i niczego nie zmienia.

Czytaj liczniki czasu zamiast zgadywać interwał

Keepalive działają, bo przychodzą częściej, niż wygasa stan. To czyni limit czasu liczbą, której naprawdę potrzebujesz, a w Linuksie można go odczytać na urządzeniu wykonującym tłumaczenie:

sysctl net.netfilter.nf_conntrack_udp_timeout
sysctl net.netfilter.nf_conntrack_udp_timeout_stream
sudo conntrack -L -p udp --dport 51820

Pierwsza wartość to limit czasu dla przepływu UDP widzianego tylko w jednym kierunku, a druga obowiązuje po zaobserwowaniu odpowiedzi. Oba są zwykle krótkie, a milknące mapowanie pójdzie za tym, co dotyczy twojego przepływu.

Porównaj tę liczbę ze swoim interwałem. Keepalive 25 sekund przy limicie 30 sekund działa; ten sam keepalive przy limicie 15 sekund nie działa. Żadna liczba ponowień nie zmienia tej arytmetyki. Niektóre routery domowe i operatorzy komórkowi używają znacznie krótszych wartości niż domyślna w Linuksie, dlatego konfiguracja działająca w jednej sieci zawodzi w innej.

Sprawdź nasłuchujący i zaporę osobno

Żywe mapowanie jest konieczne i niewystarczające. Aplikacja na domowym pudełku musi nasłuchiwać na właściwym adresie, a zapora hosta musi przepuścić pakiet po odszyfrowaniu.

sudo ss -lntup | grep 8080
sudo wg show wg0 allowed-ips
curl -sS -m 5 http://10.71.0.2:8080/health

Jeśli gniazdo jest powiązane tylko z adresem interfejsu fizycznego, a nie z adresem tunelu, pakiety przychodzące przez tunel są odrzucane, zanim zapora w ogóle zostanie zapytana. Ta usterka ze strony chmury wygląda identycznie jak problem z mapowaniem i przeżywa każdą regulację keepalive.

Sprawdzenie listy dozwolonych jest równie ważne w drugą stronę. Peer w chmurze musi zezwolić na adres tunelu domowego jako źródło, jeśli ma odpowiadać, a peer domowy musi zezwolić na adres chmury jako cel. Pakiety keepalive to uwierzytelniony ruch i stosują te same reguły, dlatego keepalive, który wydaje się działać, może współistnieć z aplikacją, która nie działa.

Wdróż zmianę i poznaj jej granice

Zastosuj ustawienie, zrestartuj interfejs, jeśli to twoja metoda aktualizacji, a następnie powtórz test bezczynności, a nie test natychmiastowy. Odczekaj dłużej niż odczytany wcześniej limit czasu, wykonaj żądanie zwrotne i potwierdź, że liczniki ruszyły na obu końcach.

Zapisz interwał i zmierzony limit czasu obok. Przyszła zmiana firmware’u routera lub przejście na połączenie mobilne może zmienić limit czasu. Notatka jest tym, co pozwala komuś ponownie wyprowadzić wartość zamiast ją kopiować. Dwie liczby w jednej linii oszczędzają później całe śledztwo.

Trwałe keepalive chronią stan. Nie otwierają portu, nie dodają wpisu do listy dozwolonych i nie sprawiają, że pojawia się nasłuchujący. Gdy połączenie zwrotne w ogóle nie działa, wina leży w jednej z tych trzech rzeczy, a szybki start WireGuard opisuje ustawienie keepalive w tych samych wąskich terminach.