VPN yhdisti uudelleen, mutta sovelluksen istunto epäonnistuu silti

Tunneli palaa, asiakas sanoo olevansa yhteydessä ja selain pyörii yhä sivulla, jota se oli lataamassa ennen katkoa. VPN:n uudelleenyhdistäminen palauttaa polun eikä palauta sitä yhteyden tilaa, jonka sovellukset ja vastapuoli keräsivät vanhalle. Ne ovat kaksi eri asiaa korjata, ja niiden sekoittaminen vie sinut takaisin VPN-asetuksiin ilman syytä.

Yksi testi erottaa ne puhtaasti, ja se kestää kymmenen sekuntia. Lähetä uusi pyyntö samaan kohteeseen, kun vanha roikkuu.

Mikä selviää uudelleenyhdistämisestä ja mikä ei

Tunneli on joukko reittejä, avaimia ja osoitteita, ja uudelleenyhdistäminen voi palauttaa kaikki kolme, kun taas jokainen muodostettu virtaus jää kuolleeksi. Käyttöjärjestelmä pitää socketin auki, koska sovellus pyysi sitä, ja socketin aikakatkaisu voi olla minuuttien tai tuntien päässä. Sen alla vastapuoli on unohtanut virtauksen, käännömerkintä on vanhentunut, tai polku kulkee nyt päätepisteen kautta, joka ei koskaan nähnyt kättelyä. Mikään uudelleenyhdistämisen sarjassa ei käy sovelluksen socketteja läpi ja korjaa niitä.

Jotkut asiakkaat lisäävät koukun, joka pudottaa vanhentuneet yhteydet uudelleenyhdistettäessä, ja useimmat eivät. Käyttäytyminen vaihtelee täällä asiakkaan, alustan ja version mukaan.

Vastapuoli unohti sinutkin

Kaukopää pitää omaa tilaansa: TLS-istunto, TCP-ohjauslohko ja kenties kartoitusmerkintä, joka sitoo osoitteesi ja porttisi virtaukseen. Polulla oleva käännölaite voi antaa kartoituksen vanhentua katkon aikana, vaikka tunneli palautuisi nopeasti. Kun kartoitus on poissa, paketteja saapuu virtaukselle, jota palvelin ei enää tunne, ja vastaus voi olla reset, jota asiakas ei koskaan näytä. Sovellukset raportoivat tämän jumittumisena eivätkä virheenä, koska ne odottavat yhä socketia, joka ei vastaa koskaan.

Palvelinpuolen joutokäyntiaikakatkaisut tekevät saman omalla aikataulullaan, minkä vuoksi istunto voi kuolla ilman yhtäkään verkkotapahtumaa. Yhteys, joka oli joutilaana kauemmin kuin palvelin odottaa, on jo poissa ennen kuin huomaat tunnelin liikkuneen.

Uusi pyyntö on testi, joka erottaa ne

Lähetä uusi pyyntö samaan isäntään, kun vanha vielä roikkuu, ja seuraa molempia. Jos uusi pyyntö onnistuu, tunneli, reitti ja nimien selvitys toimivat, ja vika rajoittuu vanhentuneeseen virtaukseen. Jos myös uusi pyyntö epäonnistuu, sinulla on polkuongelma ja sovelluksen istuntotila on väärä johtolanka.

Pidä mahdollinen suoran liikenteen esto paikallaan testin ajan. Pyyntö, joka onnistuu vahingossa varareittiä pitkin, ei todista tunnelista mitään.

Vahvista uudella yhteydellä, ei vanhalla

Alla olevat komennot näyttävät yhä avoimet socketit, käynnistävät yhden uuden pyynnön ja tarkistavat, onko istuntotaulussa yhä merkintä virtaukselle. Aja ensimmäinen ennen uudelleenyhdistämistä ja sen jälkeen, jotta ero näkyy. Korvaa isäntä ja portti omalla palvelullasi.

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

Muodostettu socket, jossa ei kulje liikennettä, on etsittävä tunnusmerkki, ja tilakoodin palauttava uusi pyyntö osoittaa, että polku on elossa. Yhteystaulukko vastaa siihen, kartoittaako mikään yhä virtausta, ja se on osa, jota asiakas ei näe. Selvittäjän kysely kattaa sivun latauksen toisen puolen, sillä nimen epäonnistuminen ja jumittunut yhteys näyttävät selaimessa samalta. Yhdessä nuo neljä tulostetta erottavat vanhentuneen istunnon rikkinäisestä tunnelista.

Kirjaa keskeytyksen aika, uudelleenyhdistämisen aika ja ero vanhan ja uuden pyynnön välillä. Se merkintä muuttaa epämääräisen valituksen raportiksi, jolla joku voi toimia.