Dlaczego tunel Azure OpenVPN pada mniej więcej co sześćdziesiąt sekund

Tunel kończy uzgadnianie, przenosi ruch przez około minutę, a następnie łączy się ponownie. Ta sekwencja wyklucza zwykłego podejrzanego, ponieważ zapora blokująca port zatrzymałaby uzgadnianie, a nie sesję. To, co masz, to spór o żywotność: jedna strona uznała, że druga zamilkła, i zerwała działający tunel. Wiersz dziennika mówi która strona, i on wybiera poprawkę.

Przeczytaj ten wiersz, zanim dotkniesz jakiegokolwiek licznika.

Mit: coś na ścieżce blokuje tunel

Gdyby port był zablokowany, połączenie nie powiodłoby się na początku i pozostałoby nieudane. Powtarzający się cykl oznacza, że komunikaty sterujące płyną, sesje się nawiązują, a coś później w rozmowie ciągle wygasa. Blokowanie tworzy ciszę, a to tworzy rytm.

Rytm jest użyteczną wskazówką. Tworzą go liczniki; utrata pakietów rzadko.

Przeczytaj powód rozłączenia przed licznikiem

OpenVPN nazywa swój powód, a każda nazwa wskazuje inny podsystem. Session invalidated: KEEPALIVE_TIMEOUT to wygasający licznik, więc porównaj wartości ping i ping-restart na obu końcach. AUTH_FAILED to dane logowania lub stan certyfikatu, i żadna zmiana licznika nie pomoże. Błąd TLS oznacza, że strony w ogóle nie dotarły do etapu keepalive.

Zapisz czas połączenia, czas rozłączenia i to, czy interwał jest stabilny co do sekundy. Ten jeden pomiar oddziela skonfigurowany harmonogram od przypadku.

Stabilny interwał to licznik. Dryfujący to raczej problem ścieżki albo przesunięta sesja.

Dwa liczniki keepalive, które nigdy się nie zgodziły

Profile wyeksportowane z portalu czasami nadal zawierają wiersze takie jak keepalive lub ping-restart skopiowane z szablonu serwera społecznościowego. Brama prowadzi własne wykrywanie martwego partnera i narzuca własne oczekiwania, a oba harmonogramy nie muszą się zgadzać. Gdy się różnią, klient restartuje się według harmonogramu, na który brama nigdy się nie zgodziła.

Te dwie wartości to nie ta sama kontrola. ping to, jak często klient wysyła echo, a ping-restart to, jak długo czeka, nie słysząc niczego, zanim zerwie tunel. Profil z krótkim ping-restart i brama odpowiadająca wolno będą restartować się w każdym cichym okresie, co jest dokładnie kształtem cyklu jednominutowego.

Najmniejsza zmiana po stronie klienta to zneutralizowanie liczników na najwyższym poziomie profilu, poza każdym blokiem wbudowanym:

keepalive 0 0

Zapisz, wczytaj profil ponownie, połącz się ponownie. Sesja znajdująca się już w pamięci zachowuje stare wartości, dlatego edycja czasami wygląda, jakby nic nie zrobiła.

Nazwa certyfikatu może się przesunąć pod twoimi stopami

Uwierzytelnianie certyfikatem Azure zależy od tego, czy klient ufa nazwie, którą brama przedstawia dzisiaj. Wiersz verify-x509-name w starszym pobraniu może przypiąć nazwę, którą przebudowa bramy lub odnowienie certyfikatu zmieniły od tego czasu, a niezgodność objawia się jako pętla ponownego łączenia, a nie jako jasny błąd. Usunięcie wiersza przywraca łączność, co czyni go dobrą diagnostyką i złą stałą poprawką, ponieważ usuwa też weryfikację. Gdy tunel się utrzyma, przywróć wiersz z nazwą, którą brama rzeczywiście przedstawia.

Przetestuj drugą generację klienta na tej samej maszynie, zanim zmodyfikujesz bramę. Jeśli jeden klient zapętla się, a drugi trzyma, problemem nie jest profil.

Co zmienić i w jakiej kolejności

Następnie sprawdź przesuniętą sesję. Dwa urządzenia współdzielące jeden certyfikat mogą się wzajemnie wypychać, a wynik wygląda okresowo, ponieważ obie strony ciągle łączą się ponownie. Porównaj rejestr sesji typu punkt-lokacja dla tej samej tożsamości, która pojawia się raz za razem.

Następnie przetestuj ścieżkę bezczynną, uruchamiając ciągły ruch na kilka minut. Jeśli przerwy ustają, gdy ruch płynie, ważny licznik należy do urządzenia NAT lub balansera obciążenia na ścieżce, a nie do OpenVPN.

Ustawienia bramy powinny się zmienić dopiero po tych czterech testach.