Jak testować stabilność VPN bez rejestrowania przeglądania

Chcesz wiedzieć, czy tunel przetrwa uśpienie laptopa, przejście między punktami dostępu, albo godzinę rozmów, a przy tym wolisz nie oddawać nikomu dziennika wszystkiego, co czytasz, gdy tego ustalasz. Trzy rzeczy na to odpowiadają: stała sonda, te same cztery fakty próbkowane według harmonogramu i zdarzenie, które je zmieniło, zapisane. Dziesięć minut tego bije popołudnie spędzone na patrzeniu, jak strona się nie ładuje. Dziennik, który zostaje, jest też dość krótki, by dołączyć go do zgłoszenia bez redagowania połowy.

Zdecyduj, co ma znaczyć stabilny

„VPN padł” to cztery różne awarie pod jednym słowem. Peer może stracić uścisk dłoni, trasa może wrócić do lokalnej bramy, rozwiązywanie nazw może trafić do serwera, który nigdy nie odpowiada przez tunel, albo to wszystko może być zdrowe, podczas gdy jedna aplikacja nadal zawodzi. Zdecyduj, która z nich pasuje do twojego objawu, zanim cokolwiek zbierzesz, bo każda wymaga innej sondy. Potem wybierz interwał, który utrzymasz: jedna próbka co trzydzieści sekund przez dziesięć minut łapie roaming bez zamieniania testu w obciążenie pracą.

Jeśli skargą jest rozmowa, która zamarza, gdy idziesz do kuchni, potrzebną właściwością jest to, czy nowe żądanie kończy się po roamingu. To sprawdza się w jednej linii i nie rejestruje żadnego przeglądania.

Ustal jedną nieszkodliwą sondę

Wybierz cel, który wolno ci odpytywać i który nie jest powiązany z twoimi kontami: host dokumentacji, wewnętrzny punkt końcowy stanu albo sama brama tunelu. Uczyń operację powtarzalną, na przykład curl -s -o /dev/null -w "%{http_code} %{time_total}\n" https://example.com/, który wypisuje jedną linię na próbę. Utrzymuj ten format wyjścia przez cały przebieg. Kod stanu i czas trwania zebrane dwa razy w ten sam sposób są tym, co czyni dwa przebiegi porównywalnymi.

Oprzyj się witrynie, na której naprawdę polegasz. Strona banku lub poczty internetowej wciąga do pomiaru trackery, przekierowania i treści osobiste oraz wypisuje identyfikatory sesji we wszystko, co później wkleisz do zgłoszenia. Używaj tego samego celu przez całe dochodzenie i zapisz go obok interwału.

Próbkuj cztery fakty

Stan peera, trasa, resolver i jedno nowe żądanie to cztery obserwacje, a każda ma tanie źródło. W WireGuardzie wg show wg0 latest-handshakes daje znacznik czasu peera, a ip route get 1.1.1.1 pokazuje, którego interfejsu użyłby kernel. W OpenVPN ten sam stan jest w pliku stanu zapisywanym przez --status /run/openvpn/status 10 albo za state na interfejsie zarządzania. Klient Windows zostaje w PowerShellu z Get-NetAdapter i Resolve-DnsName.

Zapętl je w jednym terminalu, aby każda linia miała znacznik czasu: for i in $(seq 1 20); do date -Is; wg show wg0 latest-handshakes; ip route get 1.1.1.1; sleep 30; done. Ta pętla obejmuje trzy z sześciu pól dziennika; wersja klienta trafia raz na górę, a znacznik czasu zdarzenia dodaje się, gdy zdarzenie następuje.

Resolver to fakt, który ludzie pomijają, a dig +short go ukrywa, bo ta forma wypisuje tylko odpowiedź. Zapytaj serwer wprost za pomocą dig example.com | grep SERVER: albo użyj nslookup example.com tam, gdzie dig nie jest zainstalowany, co wypisuje adres serwera, do którego poszło zapytanie. Stary uścisk dłoni na bezczynnym tunelu też nie jest automatycznie awarią, ponieważ WireGuard zmienia klucze tylko wtedy, gdy jest ruch do ochrony.

Wywołaj zdarzenie, nie wyciek

Weź pięć spokojnych minut jako linię bazową przed zdarzeniem, na którym ci zależy, czy to zamknięcie pokrywy, przejście do innego punktu dostępu, czy przełączenie na hotspot telefonu. Zapisz czas, w którym je wywołałeś, aby próbki po obu stronach można było wyrównać.

Bez tego znacznika czasu dziennik pokazuje lukę i nikt nie potrafi powiedzieć, czy zamknął ją klient, czy sieć. Dwa przebiegi ze zdarzeniem w różnych miejscach są warte więcej niż dziesięć bez niego. Użyj własnych kontrolek klienta do rozłączania i ponownego łączenia. Nie wyłączaj kill switcha i nie wypychaj ruchu poza tunel, żeby zobaczyć, co się stanie, bo na zarządzanym laptopie to naruszenie zasad, a na twojej własnej maszynie tworzy dokładnie to ujawnienie, które testowałeś.

Trzymaj dziennik dość mały, by go skończyć

Sześć pól na próbkę: czas, wersja klienta, punkt końcowy, sieć dostępu, zdarzenie, wynik. Pomiń adresy sieciowe, ładunki, tokeny i wszystko, co niesie identyfikator sesji, bo dziennik jest dowodem o tunelu i niczym więcej. Trzymaj go obok pętli, aby następna osoba mogła go uruchomić ponownie bez pytania, co znaczą kolumny.

Po zmianie powtórz test z tą samą sondą i tym samym interwałem; jeśli zmienisz cel i wersję klienta naraz, wynik nie należy do żadnego z nich. Czysty dziesięciominutowy przebieg jest dowodem dla tych warunków i tego celu, nie obietnicą co do sieci hotelowej w przyszłym miesiącu. Trzymaj skrypt i szablon dziennika tam, gdzie je znajdziesz. udokumentowane ograniczenia WireGuarda warto przeczytać, zanim przypiszesz przerwę protokołowi.