VPN-ul s-a reconectat, dar sesiunea aplicației încă eșuează

Tunelul revine, clientul spune că e conectat, iar browserul se învârte încă pe o pagină pe care o încărca înainte de întrerupere. O reconectare VPN reface o cale și nu reface starea conexiunii pe care aplicațiile și partea îndepărtată au acumulat-o pe cea veche. Sunt două lucruri diferite de reparat, iar confundarea lor vă trimite înapoi în setările VPN fără motiv.

Un singur test le separă curat, și durează zece secunde. Trimiteți o cerere nouă către aceeași destinație cât timp cea veche atârnă.

Ce supraviețuiește unei reconectări și ce nu

Un tunel este un set de rute, chei și adrese, iar o reconectare poate reface toate trei în timp ce fiecare flux stabilit rămâne mort. Sistemul de operare ține un socket deschis pentru că aplicația a cerut-o, iar timeoutul acelui socket poate fi la minute sau ore distanță. Dedesubt, partenerul a uitat fluxul, o intrare de traducere a expirat, sau calea trece acum printr-un punct final care nu a văzut niciodată strângerea de mână. Nimic din secvența de reconectare nu parcurge socketurile aplicației și nu le repară.

Unii clienți adaugă un cârlig care aruncă conexiunile vechi la reconectare, iar majoritatea nu. Comportamentul aici variază în funcție de client, platformă și versiune.

Și partea îndepărtată v-a uitat

Capătul îndepărtat păstrează stare proprie: o sesiune TLS, un bloc de control TCP și poate o intrare de mapare care leagă adresa și portul dumneavoastră de flux. Un dispozitiv de traducere de pe cale poate lăsa acea mapare să expire în timpul golului chiar și când tunelul se restabilește repede. Odată ce maparea dispare, sosesc pachete pentru un flux pe care serverul nu îl mai recunoaște, iar răspunsul poate fi un reset pe care clientul nu îl arată niciodată. Aplicațiile raportează asta ca o blocare și nu ca o eroare, pentru că încă așteaptă un socket care nu va răspunde niciodată.

Timeouturile de inactivitate de pe partea serverului fac același lucru după propriul program, motiv pentru care o sesiune poate muri fără niciun eveniment de rețea. O conexiune care a fost inactivă mai mult decât se așteaptă serverul a dispărut deja înainte să observați că tunelul s-a mutat.

O cerere nouă este testul care le separă

Trimiteți o cerere nouă către același host cât timp cea veche încă atârnă, și urmăriți ambele. Dacă cererea nouă reușește, atunci tunelul, ruta și rezolvarea numelor funcționează, iar defectul se limitează la fluxul vechi. Dacă și cererea nouă eșuează, aveți o problemă de cale și starea de sesiune a aplicației este o pistă falsă.

Lăsați pe loc orice blocare a traficului direct în timpul testului. O cerere care reușește printr-o cale de rezervă accidentală nu dovedește nimic despre tunel.

Confirmați cu o conexiune nouă, nu cu cea veche

Comenzile de mai jos arată socketurile încă deschise, pornesc o cerere nouă și verifică dacă tabela de sesiuni mai ține o intrare pentru flux. Rulați-o pe prima înainte și după reconectare, ca diferența să fie vizibilă. Înlocuiți hostul și portul cu serviciul dvs.

ss -tanp | grep -E ':(443|8443)'
curl -sS -o /dev/null -w '%{http_code} %{time_connect}\n' --max-time 8 https://intranet.example.com/
conntrack -L 2>/dev/null | grep 8443
dig +short intranet.example.com

Un socket stabilit fără trafic care se mișcă este semnătura de căutat, iar o cerere nouă care returnează un cod de stare arată că calea e vie. Tabela de conexiuni răspunde dacă ceva mai mapează fluxul, iar aceea este partea pe care clientul nu o poate vedea. Interogarea resolverului acoperă cealaltă jumătate a încărcării unei pagini, fiindcă o eroare de nume și o conexiune blocată arată la fel într-un browser. Împreună, cele patru ieșiri separă o sesiune veche de un tunel stricat.

Notați momentul întreruperii, momentul reconectării și diferența dintre cererea veche și cea nouă. Acea notă transformă o plângere vagă într-un raport pe care cineva poate acționa.