VPN ühendus taastus, aga rakenduse sessioon ikka ebaõnnestub

Tunnel tuleb tagasi, klient teatab ühendusest ja brauser keerleb endiselt lehel, mida see enne katkestust laadis. VPN-i taasühendus taastab tee ega taasta ühenduse olekut, mille rakendused ja kaugpool vanal teel kogusid. Need on kaks erinevat asja, mida parandada, ja nende segamine saadab teid ilma põhjuseta VPN-i seadetesse tagasi.

Üks test eristab neid puhtalt ja võtab kümme sekundit. Saatke uus päring samasse sihtkohta, kuni vana ripub.

Mis taasühenduse üle elab ja mis mitte

Tunnel on marsruutide, võtmete ja aadresside kogum, ja taasühendus võib kõik kolm taastada, samal ajal kui iga loodud voog jääb surnuks. Operatsioonisüsteem hoiab soketit avatud, sest rakendus palus seda, ja selle soketi aegumine võib olla minutite või tundide kaugusel. Selle all on partner voo unustanud, tõlke kirje on aegunud või kulgeb tee nüüd lõpp-punkti kaudu, mis käsitsi kokkulepet kunagi ei näinud. Midagi taasühenduse järjestuses ei käi rakenduse soketid läbi ega paranda neid.

Mõned kliendid lisavad konksu, mis viskab taasühendamisel aegunud ühendused välja, ja enamik mitte. Käitumine erineb siin kliendi, platvormi ja versiooni järgi.

Kaugpool on ka teid unustanud

Kauge ots hoiab oma olekut: TLS-i sessioon, TCP juhtplokk ja võib-olla vastenduskirje, mis seob teie aadressi ja pordi vooga. Teel olev tõlkeseade võib selle vastenduse vaheaja jooksul aeguda lasta isegi siis, kui tunnel taastub kiiresti. Kui vastendus on kadunud, saabuvad paketid voo jaoks, mida server enam ei tunne, ja vastuseks võib olla reset, mida klient kunagi ei näita. Rakendused teatavad sellest kui tõrkest, mitte veast, sest nad ootavad endiselt soketit, mis ei vasta kunagi.

Serveripoolsed jõudeaja aegumised teevad sama oma ajakava järgi, mistõttu võib sessioon surra ilma ühegi võrgusündmuseta. Ühendus, mis oli jõude kauem, kui server ootab, on juba kadunud, enne kui märkate, et tunnel on liikunud.

Uus päring on test, mis need eristab

Saatke uus päring samasse hosti, kuni vana veel ripub, ja jälgige mõlemat. Kui uus päring õnnestub, töötavad tunnel, marsruut ja nimelahendus ning viga piirdub aegunud vooga. Kui ka uus päring ebaõnnestub, on teil tee probleem ja rakenduse sessiooni olek on eksitav.

Jätke testimise ajaks igasugune otsese liikluse blokeering paigale. Päring, mis õnnestub juhusliku varutee kaudu, ei tõesta tunnelist midagi.

Kinnitage uue ühendusega, mitte vanaga

Allolevad käsud näitavad endiselt avatud soketeid, käivitavad ühe uue päringu ja kontrollivad, kas sessioonitabel hoiab endiselt voo jaoks kirjet. Käivitage esimene enne ja pärast taasühendust, et erinevus oleks nähtav. Asendage host ja port oma teenusega.

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

Loodud sokett, milles liiklus ei liigu, on tunnus, mida otsida, ja uus päring, mis tagastab olekukoodi, näitab, et tee on elus. Ühenduste tabel vastab, kas miski veel voogu vastendab, ja see on osa, mida klient ei näe. Resolveri päring katab lehe laadimise teise poole, sest nime tõrge ja takerdunud ühendus näevad brauseris ühesugused välja. Kokku eristavad need neli väljundit aegunud sessiooni katkisest tunnelist.

Kirjutage üles katkestuse aeg, taasühenduse aeg ja vahe vana ning uue päringu vahel. See kirje muudab ebamäärase kaebuse aruandeks, millega keegi saab tegutseda.