VPN yhdistää, toimii hetken ja lakkaa sitten välittämästä liikennettä, vaikka asiakas näyttää yhä istuntoa. Uudelleenyhdistäminen korjaa sen, mikä saa sen näyttämään asiakasohjelman bugilta. Yleensä kyse on palomuurista tai NAT-laitteesta, joka pudotti joutokäyvän UDP-mappauksen eikä tiedä tunnelin olevan yhä olemassa.

Oire on riittävän johdonmukainen diagnosoitavaksi: se ilmenee käyttämättömyyden jälkeen, ei kuormituksessa.

Miltä joutokäynnin pysähdys näyttää

Mittaa sitä sen sijaan, että kuvailisit. Kirjaa, kuinka kauan tunneli on joutokäynnillä ennen kuin liikenne pysähtyy, herättääkö uusi lähtevä paketti sen ja pitääkö asiakkaan rajapinta yhä osoitteensa. Jos asiakkaan tuore pyyntö toimii mutta vastaus olemassa olevaan virtaukseen ei, mappaus on epäilty. Jos mikään ei toimi ennen uudelleenyhdistämistä, myös asiakkaan istuntotila on mennyt.

Molemmat liittyvät joutokäyntiin, ja ne vaativat erilaiset korjaukset.

Kirjoita ajat muistiin ennen kuin muutat mitään. Raportti, että se pysähtyy noin kymmenen joutokäyntiminuutin jälkeen, on testattavissa, kun taas raportti, että se putoaa satunnaisesti, ei ole. Tämä ero ratkaisee, jahtaatko ajastinta vai reititysmuutosta.

Etsi laite, joka unohti

Useat laitteet voivat pitää tilaa samalle virtaukselle: paikallinen reititin, ylempänä oleva kääntäjä, pilven raja ja isäntäkoneen palomuuri. Jokaisella on oma ajastimensa, ja lyhin voittaa. Viiden minuutin katkos tarkoittaa yleensä, että yksi laite on asetettu selvästi muita alemmas.

Älä oleta, että dokumentoitu oletusarvo on polkusi aikakatkaisu. Se on yhden laitteen oletusarvo.

  • Kotireititin: usein minuutteja, joskus paljon vähemmän.
  • Pilvi-NAT tai kuormantasaaja: etsi dokumentoitu joutokäynnin aikakatkaisu nimenomaan UDP:lle.
  • Isäntäkoneen palomuuri: netfilterin seuranta-ajastimet koskevat jokaista virtausta.

Tarkista ajastimet todellisella polulla

Linuxissa netfilterin seuranta-ajastimet ovat näkyvissä ja säädettävissä: sysctl net.netfilter.nf_conntrack_udp_timeout ja net.netfilter.nf_conntrack_udp_timeout_stream. Jälkimmäinen koskee, kun liikennettä on nähty molempiin suuntiin, minkä vuoksi vakiintunut tunneli voi elää pelkkää koetta pidempään.

RFC 4787 määrittää UDP NAT -käyttäytymisen ja suositellut minimit. Se on viite, johon viitata, kun toimittajan oletusarvo näyttää poikkeuksellisen lyhyeltä.

Keepalive ja uudelleenyhdistäminen ovat eri työkaluja

Keepalive pitää mappauksen elossa; uudelleenyhdistäminen rakentaa kuolleen istunnon uudelleen. Ne ratkaisevat eri vikoja eivätkä ole vaihdettavia nopeusasetuksia. WireGuardin PersistentKeepalive lähettää paketin kiinteällä välillä pitääkseen NAT-sidoksen auki. OpenVPN:n keepalive vaihtoehto tekee saman työn omalla tavallaan. Kumpikaan ei auta, jos välissä oleva laite on jo unohtanut virtauksen ja pudottaa molemmat suunnat.

Erittäin tiheät kokeet lisäävät työtä korjaamatta väärää rajaa.

Varmista uudella pyynnöllä, älä sivun uudelleenlatauksella

Kun olet muuttanut ajastinta tai lisännyt keepaliven, toista joutokäyntiskenaario täsmälleen kuten ennen. Tee sitten todella uusi pyyntö katetusta sovelluksesta. Jo ladattu selaimen välilehti voi piirtyä välimuistista eikä kerro sinulle mitään.

Jos pysähdys jatkuu, siirry yksi hyppy ulospäin ja tarkista kyseisen laitteen tilataulu.

Aiheeseen liittyvät artikkelit