VPN po UDP zastyga w bezczynności: firewall zapomniał twojego przepływu

VPN łączy się, działa przez chwilę, a potem przestaje przepuszczać ruch, podczas gdy klient wciąż pokazuje sesję. Ponowne połączenie to naprawia, dlatego wygląda to na błąd klienta. Zwykle to firewall albo urządzenie NAT, które odrzuciło nieaktywne mapowanie UDP i nie ma pojęcia, że tunel nadal istnieje.

Objaw jest dość spójny, by go zdiagnozować: pojawia się po bezczynności, a nie pod obciążeniem.

Jak wygląda zastój z powodu bezczynności

Zmierz go, zamiast go opisywać. Zapisz, jak długo tunel stoi bezczynnie, zanim ruch się zatrzyma, czy nowy pakiet wychodzący go ożywia i czy interfejs klienta nadal trzyma swój adres. Jeśli nowe żądanie od klienta działa, ale odpowiedź do istniejącego przepływu nie, podejrzanym jest mapowanie. Jeśli nic nie działa, dopóki nie połączysz się ponownie, stan sesji klienta też przepadł.

Oba są związane z bezczynnością i wymagają różnych poprawek.

Zapisz czasy, zanim cokolwiek zmienisz. Zgłoszenie, że zatrzymuje się po około dziesięciu minutach bezczynności, jest sprawdzalne, a zgłoszenie, że pada losowo, nie jest. Ta różnica decyduje, czy gonisz licznik czasu, czy zmianę trasowania.

Znajdź urządzenie, które zapomniało

Kilka urządzeń może trzymać stan dla tego samego przepływu: lokalny router, translator wyżej w drodze, granica chmury i firewall hosta. Każde ma własny licznik czasu, a wygrywa najkrótszy. Pięciominutowa przerwa zwykle oznacza, że jedno urządzenie jest skonfigurowane znacznie niżej niż pozostałe.

Nie zakładaj, że udokumentowana wartość domyślna to limit czasu na twojej drodze. To wartość domyślna jednego urządzenia.

• Router domowy: często minuty, czasem znacznie mniej.
• Chmurowy NAT lub równoważnik obciążenia: sprawdź udokumentowany limit bezczynności specjalnie dla UDP.
• Firewall hosta: liczniki śledzenia netfilter działają dla każdego przepływu.

Sprawdź liczniki na rzeczywistej drodze

W Linuksie liczniki śledzenia netfilter są widoczne i regulowane: sysctl net.netfilter.nf_conntrack_udp_timeout i net.netfilter.nf_conntrack_udp_timeout_stream. Drugi działa, gdy ruch został już zaobserwowany w obu kierunkach, dlatego ustanowiony tunel może przetrwać zwykłą sondę.

RFC 4787 opisuje zachowanie UDP NAT i zalecane minima. To odniesienie, które warto cytować, gdy domyślna wartość dostawcy wygląda nietypowo krótko.

Keepalive i ponowne połączenie to różne narzędzia

Keepalive utrzymuje mapowanie przy życiu; ponowne połączenie odbudowuje martwą sesję. Rozwiązują różne awarie i nie są wymiennymi ustawieniami szybkości. Ustawienie PersistentKeepalive WireGuarda wysyła pakiet w stałym odstępie, by utrzymać wiązanie NAT otwarte. Opcja keepalive OpenVPN robi to samo na swój sposób. Żadne nie pomoże, jeśli urządzenie w środku już zapomniało przepływu i odrzuca oba kierunki.

Bardzo częste sondy dodają pracy, nie naprawiając niewłaściwej granicy.

Weryfikuj nowym żądaniem, nie odświeżeniem strony

Po zmianie licznika czasu lub dodaniu keepalive powtórz scenariusz bezczynności dokładnie jak wcześniej. Potem wyślij naprawdę nowe żądanie z objętej aplikacji. Karta przeglądarki, która była już wczytana, może wyrenderować się z pamięci podręcznej i nic ci nie powie.

Jeśli zastój się utrzymuje, przesuń się o jeden skok na zewnątrz i sprawdź tablicę stanów tego urządzenia.