Który skok NAT gubi nieaktywne mapowanie VPN i jak to rozpoznać
Nieaktywny przepływ VPN może umrzeć na każdym skoku utrzymującym stan. Powtórz jeden test, porównaj, co widziała każda granica, i zgłoś ograniczony wynik zamiast zgadywanego winnego.
Po cichym okresie tunel łączy się ponownie, żaden dziennik nie wskazuje winnego, a oczywistym ruchem jest wybrać urządzenie z najbardziej imponującą dokumentacją limitu czasu. To domysł przebrany za diagnozę. Stan może przetrwać jakiś czas w domowym routerze, w translatorze operatora i na krawędzi chmury, a każde z nich może zgubić przepływ, który cichnie. Zamiast tego możesz zmapować ścieżkę, zaznaczyć, które urządzenia naprawdę możesz obserwować, i wykonać jeden test bezczynności, który da się powtórzyć.
Powtarzalny test zamienia anegdotę w pomiar. Wszystko poniżej zakłada jednego klienta, jeden serwer i jeden protokół oraz to, że powstrzymujesz się od zmiany dwóch zmiennych naraz. Chodzi o to, by następne zdarzenie było tańsze niż to.
Za każdym razem wykonuj ten sam test bezczynności
Zapisz, kiedy przepływ ostatnio był w porządku, jak długo potem był bezczynny i czy jedna świeża paczka go przywróciła. Te trzy fakty to pomiar; bez nich masz historię o upadłym laptopie. Przy każdym powtórzeniu używaj tego samego klienta, tego samego serwera i tego samego protokołu, i zanotuj moment wysłania pierwszej paczki po ciszy.
Następnie porównaj, co naprawdę widziała każda granica, którą posiadasz. Rozstrzyga to, czy serwer nie zobaczył po pauzie niczego, czy zobaczył żądanie i odpowiedział w ścieżkę, która nie niosła już odpowiedzi.
| What you observe | What it suggests | What it does not prove |
|---|---|---|
| server records no packet after the pause | state was lost upstream of the server | which hop dropped it |
| server answers, client never receives | return-path state or filtering | that the timer belongs to the client |
| client sends nothing at all | client-side timer or application behaviour | that the network path is healthy |
Porównywanie ścieżek bez zmieniania pięciu rzeczy
Druga zatwierdzona sieć dostępu to uprawnione porównanie, bo łańcuch NAT jest inny. Różni się też dostawcą, warunkami radiowymi i być może rodziną adresów, więc wynik jest granicą, a nie przypisaniem. Zapisuj ograniczenia razem z wynikiem, zamiast po cichu je pomijać w raporcie. Zapisz też ścieżkę: urządzenie, rola i czy da się w ogóle odczytać jego stan.
Porównanie ścieżek daje ograniczone pytanie: przepływ przeżywa na jednej i ginie na drugiej po podobnej ciszy, więc zmienna jest gdzieś w częściach, które się różnią. To realny wynik nawet wtedy, gdy żadne urządzenie nie zostaje nazwane, i mówi następnemu inżynierowi, gdzie spędzić popołudnie, a gdzie nie.
Warto odczytać stan lokalny, zanim zacznie się spekulować o operatorach. Na bramie Linux conntrack -L wylicza śledzone przepływy wraz z pozostałym czasem życia, co zamienia domysł o timerze w liczbę, której wygaśnięcie można zobaczyć. Odczytaj go przed okresem bezczynności i po nim, nie tylko po.
Co utrzyma sygnał podtrzymania, a czego nie
Wspierany sygnał podtrzymania utrzymuje mapowanie otwarte, a otwarte mapowanie niczego nie dowodzi o usłudze za nim. Tunel może pozostać zmapowany, gdy aplikacja, którą niesie, przestała odpowiadać, a z punktu widzenia lampki statusu te dwie sytuacje wyglądają tak samo. Traktuj sygnał podtrzymania jako ubezpieczenie od wygaśnięcia bezczynności, a nie jako kontrolę stanu.
Ustaw interwał na najkrótszy faktycznie zmierzony limit czasu, a nie na liczbę skopiowaną z forum. Sygnał podtrzymania dostrojony poniżej każdego możliwego timera to ruch, którego nikt nie potrzebował, a także usuwa objaw, który powiedziałby ci, która granica wygasa pierwsza. Wybierz interwał na podstawie zmierzonej liczby i zostaw wszystko inne w spokoju.
Jedna zmiana, potem zmierz ponownie
Oprzyj się pokusie podniesienia każdego limitu i wyczyszczenia każdej bramy podczas testu na żywo. To wymazuje dowody, po które przyszedłeś, i przerywa przepływy innych osób, co jest złą wymianą za niesprawdzoną hipotezę. Zmień jedno wspierane ustawienie na jednym urządzeniu, a potem powtórz okres bezczynności i odzyskanie aplikacji.
Zapisz, które obserwacje granicy się przesunęły, i zapisz to nawet wtedy, gdy nic się nie poprawiło. Ustawienie, które niczego nie naprawiło, jest informacją, i taniej jest zauważyć to raz, niż przetaczać przez cały majątek.
Pisanie ustalenia, którego można bronić
Gdy nie da się sprawdzić translatora wyżej, powiedz tylko to, co potwierdzają dowody: wymiana ginie gdzieś na tym odcinku ścieżki po tylu ciszy, a odpowiedzialny skok pozostaje nieprzypisany. Ograniczone stwierdzenie przechodzi przegląd i wskazuje następnej osobie właściwy segment. Wskazanie ukrytego routera jako przyczyny nie robi ani jednego, ani drugiego. Przekaż ograniczone ustalenie temu, kto posiada nieobserwowalny segment, wraz z interwałem.
RFC 4787 opisuje, dlaczego timery mapowania UDP są trudne do wywnioskowania z jednego końca, i właśnie ta trudność czyni ograniczone ustalenie uczciwym. Timery są realne, podobnie jak niepewność wokół nich.