Na co naprawdę czeka gateway-ping-timeout w NetworkManagerze

Znajdujesz connection.gateway-ping-timeout w wątku o laptopie, który wstaje, zanim sieć jest użyteczna, podnosisz go i coś się zmienia. Czy zmiana pomogła z powodu, który masz na myśli, to osobne pytanie. Odpowiedź zaczyna się od tego, co aktywacja faktycznie robi, gdy działa ten licznik, oraz od faktu, że oczekiwanie ma dwa możliwe zakończenia.

Śledź jedno połączenie z wiersza poleceń, a semantyka staje się konkretna.

Śledzenie jednej aktywacji

Zacznij od zapisanego połączenia, a nie od globalnej wartości domyślnej, bo to właściwość każdego połączenia. Dodaj --show-secrets tylko wtedy, gdy naprawdę go potrzebujesz; samo ustawienie nie jest tajemnicą.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Gdy właściwość wynosi zero, co jest udokumentowaną wartością domyślną, aktywacja rusza dalej, gdy tylko adresowanie się zakończy. Ustaw wartość dodatnią, a aktywacja konfiguracji IP czeka, aż przyjdzie odpowiedź z bramy albo upłynie limit czasu.

Potem wyłącz i włącz połączenie, obserwując strumień zdarzeń. Widoczna kolejność to praca tego ustawienia: stan urządzenia, adresowanie, oczekiwanie i wreszcie stan aktywacji, według którego zwykle porządkuje się usługi zależne.

Oczekiwanie ma dwa zakończenia

Oba zakończenia się liczą, a większość ludzi pamięta tylko jedno. Odpowiedź z bramy kończy oczekiwanie wcześniej, a limit czasu kończy je także wtedy, niezależnie od tego, czy coś odpowiedziało. Właściwość nie wymaga udanego ping przed zakończeniem aktywacji.

To jedno zdanie wyjaśnia wiele zamieszania wokół laptopów w hotelach i na konferencjach, gdzie portal przechwytujący często odrzuca ICMP, dopóki się nie zalogujesz. Połączenie i tak aktywuje się po upływie limitu czasu; robi to tylko później, niż trzeba, a każda usługa uporządkowana po połączeniu czeka razem z nim.

To także nie jest kontrola żywotności. Nic w opisie nie zaczyna pingować bramy po podniesieniu połączenia i nic nie rozłącza aktywnego profilu, bo późniejszy ping się nie udał. Jeśli potrzebujesz wykrywania utraty, należy to do protokołu lub właściciela tunelu, a nie do właściwości, która zadziałała raz podczas aktywacji.

Dwa obiekty, jedno ustawienie

Przewodowy profil bazowy i profil VPN to osobne obiekty konfiguracji, a ustawienie właściwości na jednym nie wpływa na drugi. Profil VPN, który wskazuje połączenie bazowe, nie dziedziczy żadnych jego ustawień aktywacji, dlatego zmieniona wartość może wyglądać na bez wpływu na to, co obserwowałeś.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Czytaj UUID, a nie nazwy. Nazwy dublują się po reinstalacji lub przywróconym profilu, a dwa połączenia o tej samej widocznej nazwie sprawią, że będziesz edytować niewłaściwy plik, podczas gdy prawdziwy pozostanie niezmieniony.

Zainstalowane wydanie NetworkManagera też ma znaczenie. Zachowanie wtyczki i sposób, w jaki typ połączenia mapuje tę właściwość na własne kroki aktywacji, się różnią, więc testuj na wersji, którą wdrażasz, zamiast zakładać, że znaleziony wpis obowiązuje bez zmian.

Czego oczekiwanie nie może poświadczyć

Oto część, która kosztuje najwięcej czasu. Odpowiedź lokalnego routera dowodzi, że jeden host odpowiedział na jedno echo ICMP podczas aktywacji. Nie dowodzi, że punkt końcowy VPN się rozwiązuje, że tożsamość klienta jest akceptowana, że zainstalowano trasy prywatne, że resolver biurowy odpowiada, ani że aplikacja, na której ci zależy, będzie działać.

To osobne zależności z osobnymi dowodami. Brama może odpowiadać, gdy DNS zawodzi, a brama może po cichu odrzucać ICMP zgodnie z polityką, gdy wszystkie ścieżki aplikacji działają. Warunkowanie na tej właściwości jest więc zgadywaniem, która warstwa się spóźnia, a nie jej pomiarem.

Jeśli czekasz na usługę zależną, nazwij, czego potrzebuje. Przydzielony adres jest odpowiadany przez adresowanie. Tunel jest odpowiadany przez własny stan tunelu. Prywatna nazwa jest odpowiadana przez zapytanie. Aplikacja jest odpowiadana przez aplikację, i żadna z tych odpowiedzi nie pochodzi z licznika nazwanego po bramie.

Jeśli to zmieniasz, zapisz dlaczego

Zapisz poprzednią wartość i powód przed zatwierdzoną zmianą, a potem ustaw ją na konkretnym połączeniu, a nie wszędzie. Dłuższe oczekiwanie przesuwa czas aktywacji wszystkiego, co jest uporządkowane po tym połączeniu, co może sprawić, że wolny system wygląda dobrze, a szybki wygląda na zepsuty.

Warto wymienić jedną historyczną pułapkę: taka wartość bywa zmieniana, aby starszy edytor zaakceptował profil. Jeśli to jest prawdziwa historia, masz dwa zdarzenia, a nie jedno. Edytor zapisał, a polityka sieciowa na żywo się zmieniła. Napraw edytor lub wtyczkę i przywróć licznik.

Źródła NetworkManagera definiują tę właściwość jako opóźnienie powodzenia adresowania IP do odpowiedzi bramy albo limitu czasu, z domyślną wartością zero, a definicja ustawienia połączenia jest referencją, którą trzeba przeczytać, zanim zaufa się zachowaniu opisanemu z drugiej ręki.