Pingowy stróż nie odróżni zepsutego tunelu od sprawnego

Ping do internetu dowodzi mniej, niż się wydaje. Sonduj tunel od środka, licz niepowodzenia przed działaniem i traktuj zmianę serwera jako osobną decyzję.

Trzy warunki decydują, czy stróż pomaga, czy szkodzi: co potrafi rozróżnić sonda, ile kolejnych niepowodzeń uzasadnia działanie i czy działaniem jest ponowne połączenie, czy przełączenie. Linia cron, która pinguje publiczny adres, nie odpowiada dobrze na żadne z nich. Ponownie łączy tunele, które są sprawne, i zostawia tunele zepsute, a robi jedno i drugie bez żadnego zapisu. Projekt, który warto zachować, czyni te trzy wybory jawnymi.

Sonda to ta część, która decyduje o wszystkim innym.

Co ping do internetu naprawdę dowodzi

Ping do publicznego resolvera pokazuje, że lokalna droga do internetu żyje. Nie dowodzi, że tunel przenosi ruch, a w profilu pełnego tunelu sam ping podróżuje przez tunel, więc zdrowa odpowiedź i zepsuty tunel mogą istnieć jednocześnie, gdy klient wciąż przekazuje pakiety. Jeśli profil wysyła zapytania o nazwy przez tunel, błąd DNS jest czytany jako martwe połączenie i uruchamia ponowne połączenie, które niczego nie naprawi.

Żaden z dwóch kierunków błędu nie pojawia się w kodzie wyjścia. Stróż zbudowany na tym sygnale to rzut monetą z harmonogramem cron.

Sonduj coś, co żyje za tunelem

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

Sonduj od środka, najtańsza kontrola najpierw. Istnienie interfejsu mówi, że tunel jest podniesiony; wyszukanie trasy do znanego adresu wewnętrznego mówi, że ruch by do niego wszedł; sonda TCP do hosta po drugiej stronie mówi, że coś naprawdę odpowiada. Same żądania echo mylą: wiele hostów wewnętrznych chętnie odpowiada na TCP, ale odrzuca ICMP, więc stróż oparty na pingu bez przerwy ponownie łączy tunel, który nigdy nie przestał działać.

Trzymaj sondę ograniczoną w czasie i daj jej odrębny kod wyjścia. Sonda, która wisi trzydzieści sekund, zamienia stróża w detektor awarii z wbudowanym opóźnieniem.

Wybierz między jedną linią a pętlą

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

Wpis cron to jedna linia bez pamięci, co pasuje do laptopa, na którym dodatkowe połączenie nic nie kosztuje. Nadzorowana pętla trzyma licznik i działa dopiero po kilku niepowodzeniach, co nie pozwala niestabilnemu łączu wywołać burzy ponownych połączeń. W obu przypadkach uruchamiaj ją pod nadzorcą, żeby przetrwała awarię i pisała do dziennika. Wybieraj według tego, czy zbędne połączenie ma znaczenie, a nie według tego, która wersja jest krótsza.

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

Ta pętla liczy kolejne niepowodzenia, a nie ułamek w oknie. Okno wymaga zegara i pamięci próbek, a większość błędów w stróżach pisanych ręcznie mieszka właśnie w tej arytmetyce.

Przełączenie to inna decyzja

Zmiana serwera różni się od ponownego połączenia. Najpierw zerwij stare połączenie, bo drugi klient uruchomiony, gdy pierwszy wciąż trzyma adres, zderzy się. Licz kolejne niepowodzenia przed zmianą, ogranicz liczbę prób i sprawdź ponownie, gdy nowe połączenie będzie podniesione, zamiast ufać kodowi wyjścia polecenia connect. Błędna konfiguracja nie powinna krążyć po wszystkich serwerach w pętli.

Nie sonduj publicznego adresu samego serwera VPN z wnętrza pełnego tunelu. Ta kontrola zależy od rzeczy, którą testuje, i zgłasza sukces, gdy droga, którą miała potwierdzić, już zniknęła.

Zanotuj, która sonda działała, co zwróciła i jaka akcja nastąpiła. Ten zapis zamienia tajemnicze ponowne połączenie w zdarzenie, które można zdiagnozować.

Powiązane artykuły