Czy VPN pada po odnowieniu DHCP? Porównaj adresy

Odnowienie dzierżawy i awaria VPN pojawiają się razem w logach dość często, by ludzie wnioskowali, że jedno powoduje drugie. Zbieżność czasowa jest realna; przyczynowość zwykle nie. Odnowienie to zapytanie unicast do serwera, który wydał dzierżawę, o dalsze używanie tego samego powiązania, a serwer może je przedłużyć bez zmiany choćby jednego adresu przez klienta. Przejrzenie własnych wartości klienta wokół zdarzenia oddziela cicho odnowioną dzierżawę od sieci, która naprawdę zmieniła się pod działającym tunelem.

Zacznij od klienta, który się zerwał

Najpierw otwórz log połączeń klienta i zapisz czas zerwania co do sekundy. Potem otwórz log sieciowy systemu operacyjnego dla tej samej minuty i przeczytaj po kolei, co zrobił interfejs. Ta kolejność to całe śledztwo: zdarzenie DHCP przed rozłączeniem, rozłączenie przed zdarzeniem DHCP i dwa zdarzenia bez niczego między nimi to trzy różne ustalenia. Wiersz logu, który tylko wspomina dzierżawę, gdy tunel już się ponownie łączył, jest ozdobą, nie dowodem.

Zapisuj oś czasu na bieżąco, zamiast trzymać ją w pamięci. Znaczniki czasu z różnych narzędzi rzadko zgadzają się idealnie, a sama różnica bywa wyjaśnieniem.

Porównaj cztery wartości wokół zdarzenia

Cztery wartości opisują lokalną stronę połączenia wystarczająco dobrze, by wychwycić rzeczywistą zmianę: adres interfejsu, brama domyślna, lista resolverów i stan operacyjny interfejsu. Zarejestruj je w ciągu minuty po zerwaniu i porównaj z zapisem wykonanym, gdy tunel był zdrowy.

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

Niezmieniony adres z niezmienioną bramą i zmienioną listą resolverów wskazuje na rozwiązywanie nazw, a nie routing, i tunel mógł przetrwać, gdy aplikacje przestały znajdować hosty. Zmieniona brama oznacza, że droga z sieci lokalnej się przesunęła, co wystarcza, by unieważnić trasę wskazującą na poprzednią. Jeśli wszystkie cztery wartości zgadzają się ze zdrowym zapisem, dzierżawa nie jest twoją przyczyną i tematem staje się własna logika ponownego łączenia klienta. Wykonaj porównanie, póki usterka jest widoczna, bo zdrowy zapis po restarcie ma inną historię adresów i nie będzie pasował.

Co odnowienie może, a czego nie może zmienić

RFC 2131 opisuje odnowienie jako zapytanie do pierwotnego serwera w połowie czasu dzierżawy, z ponownym powiązaniem z dowolnym serwerem w siedmiu ósmych, jeśli pierwsza próba pozostanie bez odpowiedzi. Żaden z kroków nie wymaga, by klient uzyskał inny adres, a współpracujący serwer zwykle przedłuża istniejące powiązanie. Rzeczywista zmiana adresu zwykle przychodzi inną drogą: serwer odmawia odnowienia, klient utracił swój stan i zaczął od nowa, albo sieć przeniosła urządzenie do innego segmentu.

Publiczna strona połączenia może się zmienić bez żadnej lokalnej zmiany. Za tłumaczeniem klasy operatorskiej adres, który widzi partner VPN, może zostać przydzielony ponownie niezależnie od tego, co zrobiła lokalna dzierżawa, a to przydzielenie wygląda od wewnątrz klienta identycznie jak lokalna awaria sieci. Porównanie adresu zgłaszanego lokalnie z obserwacją po stronie partnera to jedyny sposób, by je rozdzielić.

Gdy klient nie potrafi się przystosować

Klient, który związał swój transport ze starym adresem, zapisał w pamięci podręcznej nieaktualną trasę do partnera lub zachował tożsamość interfejsu, może dalej próbować drogi, której już nie ma. To defekt przystosowania, widoczny jako powtarzane retransmisje do adresu, którego host nie może już osiągnąć. Niektórzy klienci radzą sobie z tym z założenia: WireGuard na przykład aktualizuje punkt końcowy partnera, gdy z nowego źródła przychodzi poprawnie uwierzytelniony pakiet.

Ręczny restart przywracający usługę jest wskazówką, gdzie przystosowanie zawiodło, a nie dowodem, że dzierżawy i tunele są niezgodne. Podczas testów utrzymuj politykę blokowania, inaczej sam test staje się awarią z innej przyczyny. Zanotuj, czy klient odzyskał sprawność sam, ile to trwało i który adres próbował ponownie; ta sekwencja mówi więcej niż powód rozłączenia pokazany w interfejsie.

Powtórz zdarzenie, zanim je obwinisz

Odtwórz warunek zamiast czekać na harmonogram: zwolnij i odnowij dzierżawę albo wymuś równoważne kontrolowane zdarzenie i obserwuj, czy tunel przetrwa. W sieci zarządzanej skoordynuj każdą zmianę adresu z właścicielem sieci, bo dowolne przypisanie statyczne może kolidować z urządzeniem, które już ma ten adres.

Po wspieranej poprawce powtórz to samo zdarzenie, a potem przetestuj aplikację i zapytanie o nazwę, bo tunel, który łączy się ponownie, ale psuje DNS, przechodzi słabszy test niż ten, który się liczy. Zgłoś konkretną zaobserwowaną zmianę wraz z jej znacznikiem czasu, zamiast wskazywać zaplanowaną dzierżawę jako przyczynę. Różnica między tymi dwoma raportami to, czy następna osoba potrafi odtworzyć usterkę, czy tylko plotkę.