VPN kuollut unen jälkeen: kadonnut tunneli vai vanhentunut sovellus?

Kansi aukeaa, langattoman verkon kuvake palaa ja VPN näkyy edelleen yhdistettynä. Ensimmäinen sisäinen sivu jää sitten roikkumaan, kunnes aikakatkaisu iskee, ja uusi välilehti tekee saman. Kolme eri asiaa voi tuottaa tuon kuvan, ja ne tarvitsevat kolme eri korjausta: tunneli, joka ei selvinnyt unesta, profiili, jota kukaan ei pyytänyt aktivoimaan uudelleen, tai sovellus, joka pitää yhä istuntoa, joka kuoli tunteja sitten. Niiden vertaaminen on nopeampaa kuin minkään uudelleenasentaminen.

Kolme asiaa voi mennä rikki heräämisen jälkeen

Ensimmäinen ehdokas on itse tunneli. Rajapinta voi olla yhä olemassa osoitteen kanssa, vaikka vertaisyhteys on kadonnut, siksi merkkivalo ei ole todiste toimivasta reitistä. Uneasi vanhempi kättely on merkki, ja sen näkemiseen riittää yksi komento.

Toinen on aktivointi. Monet asiakkaat yhdistävät itse uudelleen; jotkut eivät, ja profiili, jota kukaan ei pyydä palaamaan, jää siihen ja näyttää määritellyltä. Tuo epäonnistuminen on suunnitellusti hiljaista, koska mikään ei antanut virhettä.

Kolmas on sovellus. Selaimen välilehti, SSH-istunto tai tietokantayhteys voi selvitä verkon vaihdoksesta tiedostokahvana, vaikka alla oleva siirto on kuollut. Silloin uusi istunto toimii moitteettomasti, mikä kertoo, että tunneli oli kunnossa koko ajan.

Vertaa kolmea ennen kuin muutat mitään, koska korjaukset eivät mene päällekkäin. Sellaisen asiakkaan uudelleenkäynnistys, jota ei koskaan pyydetty käynnistymään uudelleen, tuhlaa tarvitsemasi todisteen. Kirjoita ylös, mihin ehdokkaaseen oire sopii, ennen kuin kosket asetukseen. Se yksi lause ratkaisee yleensä tutkinnan loppuosan.

Ensimmäinen: tuliko tunneli takaisin?

Katso rajapintaa ja vertaisen tilaa, älä asiakkaan omaa tilatekstiä. Rajapinta, jolla on osoite mutta ei tuoretta kättelyä, on tunneli, joka on pystyssä vain nimellisesti.

ip -brief addr show
wg show
ip route show table all | head -20

Jos rajapinta puuttuu kokonaan, tunneli ei selvinnyt ja kysymykseksi tulee, kenen oli tuotava se takaisin. Jos se on olemassa mutta kättely on vanha, vertaussuhde on palautettava, ja asiakas voi odottaa liikennettä, joka käynnistää sen.

Tarkista myös reitit ja DNS-asetukset. Tunneli voi palata ilman reittejään, mikä synnyttää hämmentävän tilan, jossa rajapinta on pystyssä ja sisäiset nimet ratkeavat yhä väärän palvelimen kautta.

Toinen: pyysikö jokin sitä palaamaan?

Tässä vertailu ansaitsee paikkansa. OpenVPN-liitännäisprofiili ja natiivi WireGuard-yhteys käsitellään NetworkManagerissa eri tavalla, ja yhteysasetusten viite sanoo selvästi, että connection.autoconnect ei aktivoi VPN-profiileja; mekanismi VPN:n nostamiseksi yhteyden mukana on connection.secondaries.

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

Jos manuaalinen uudelleenyhdistäminen korjaa ongelman joka kerta, se on puuttuvan aktivoinnin eikä rikkinäisen tunnelin allekirjoitus. Loki näyttää yleensä, kuinka rajapinta putoaa eikä mikään tuo sitä takaisin.

Vastusta houkutusta lisätä unikoukku heti. Koukku, joka laukeaa ennen kuin verkko on toipunut, kilpailee sen saman prosessin kanssa, jota yrittää auttaa, ja muuttaa toistettavan ongelman ajoittaiseksi.

Kolmas: pitääkö sovellus vanhaa tilaa?

Avaa täysin uusi istunto samaan kohteeseen ennen kuin kosket VPN:ään. Jos uusi istunto toimii ja vanha ei, tunneli on kunnossa ja sovellus pitää kuollutta yhteyttä.

Tämä on kolmesta tarkistuksesta halvin ja useimmin ohitettu, koska epäonnistuva ikkuna on suoraan ruudulla. Sulje se, avaa uudelleen ja huomaa, jääkö ongelma. Jos uusi istunto toimii, lopeta tunnelin tutkiminen kokonaan. Jos sekin epäonnistuu, sovellus on oire eikä syy.

Jotkin sovellukset toipuvat itsestään aikakatkaisun jälkeen, siksi oire voi näyttää korjaavan itsensä muutaman minuutin kuluttua. Tällainen käytös osoittaa sovellukseen eikä tunneliin, ja se kannattaa kirjata erikseen. Kollega, joka kertoo, että se vain korjautui itsestään, kuvaa tätä kaavaa, ei onnenkantamoista.

Tee vertailusta toistettava

Pidä muuttujat pieninä: yksi käyttöverkkoyhteys, yksi unen kesto ja sama ensimmäinen pyyntö joka kerta. Kirjaa sitten kaksi tulosta: korjaako manuaalinen uudelleenyhdistäminen sen ja tuoko toinen uni vian takaisin.

Juuri viimeinen havainto erottaa kolme ehdokasta luotettavimmin. Toimiva uusi istunto epäonnistuneen vanhan jälkeen ei ole tunnelin ongelma, eikä mikään asiakkaan uudelleenasennus muuta sitä.

WireGuardin pysyvä keepalive kuuluu tähän kuvaan vain NAT-mappauksen keepalivena. Se lähettää paketteja pitääkseen mappauksen auki; se ei estä konetta nukahtamasta eikä voi jatkaa lähettämistä, kun prosessi on keskeytetty.

Kirjaa tikettiin, mitä löysit: mikä kolmesta oli rikki, mikä sen korjasi ja miten toistit sen. Seuraava henkilö, joka avaa kannen maanantaina, kiittää sinua, eikä vastausta tarvitse löytää uudelleen alusta.