VPN katkeaa, kun näyttö pimenee: lukitus, tyhjeneminen vai lepotila?
Lukittu istunto, pimentynyt näyttö ja lepotilaan mennyt kone ovat kolme eri tapahtumaa. Yhdistä ne journalctliin ennen kuin syytät VPN:n yhteydenpitomekanismia.
Kun joku sanoo VPN:n kuolleen, kun näyttö pimeni, ensimmäinen hyödyllinen kysymys on, mikä kolmesta tapahtumasta todella tapahtui: istunto lukittiin, paneeli sammutettiin vai koko kone meni uneen. Ne ovat erillisiä mekanismeja erillisillä ajastimilla, ja vain yksi niistä voi estää prosessin aikatauluttamisen kokonaan. Käy alla olevat tarkistukset järjestyksessä läpi. Pysähdy ensimmäiseen, joka vastaa kysymykseen, sillä jokainen sen jälkeinen tarkistus vastaa johonkin muuhun.
Tarkistus yksi: erota lukitus pimenemisestä ja unesta
Lukitus muuttaa sitä, kuka saa käyttää istuntoa; komposiitti jatkaa piirtämistä, verkkopino jatkaa toimintaa eikä VPN-asiakas huomaa mitään. Näytön pimeneminen sammuttaa paneelin toimettomuusjakson jälkeen ja jättää koneen täysin hereille. Uni pysäyttää suorittimet, eli yhtään käyttäjäavaruuden prosessia ei aikatauluteta, joten mikään yhteydenpito ei voi laueta, olipa väli kuinka lyhyt tahansa.
| Event | What it stops | Can it kill the tunnel? |
|---|---|---|
| Session lock | Input to your session | No |
| Display blank | The panel | No |
| Suspend to RAM | CPU scheduling, hence every process | Yes, and silently |
| Hibernate | Everything, with state written to disk | Yes |
Juuri tuon taulukon vuoksi «näyttö pimeni» ei ole diagnoosi. Viiden minuutin pimenemiseen ja kolmenkymmenen minuutin uneen asetettu työpöytäkone näyttää pimeän näytön kuudennella minuutilla täysin terveen tunnelin kanssa. Kolmannenkymmenennen minuutin vika on toinen tapahtuma toisella korjauksella, ja molemmat näyttävät samalta huoneen toiselta puolelta.
Tarkistus kaksi: laita virta- ja verkkotapahtumat yhdelle aikajanalle
Lue lokia rajatulta ajanjaksolta koko käynnistyksen sijaan ja sisällytä sekä kirjautumishallinta että yhteyden omistaja:
journalctl -b -u systemd-logind -u NetworkManager --since "45 minutes ago"
systemd-inhibit --list
Ensimmäinen komento näyttää unipyynnöt, heräämisen ja niitä seuranneet verkkosiirtymät. Toinen näyttää, mikä pitää tällä hetkellä estolukkoa, mikä kertoo, estääkö jokin unen tarkoituksella ja mikä ohjelma se on. Mukauta yksikköjen nimiä, jos yhteytesi omistaja ei ole NetworkManager, ja muista, että toisen käyttäjän yksikön tai järjestelmälokin lukeminen riippuu paikallisesta käytännöstä.
Puuttuva rivi ei ole kielteinen tulos. Jos valitun yksikön loki ei näy tilillesi, unimerkinnän puuttuminen ei todista mitään, ja päätelmä «se ei koskaan nukkunut» tyhjästä suodattimesta on tapa, jolla ihmiset viettävät viikon yhteydenpitoa säätäen.
Tarkistus kolme: jos se meni uneen, päätä oliko se tarkoituksellista
Kun unisiirtymä on aikajanalla, kysymys muuttuu siitä, miksi VPN meni rikki, siihen, olisiko koneen ylipäätään pitänyt nukkua. Kannettavassa vastaus on usein kyllä, ja tunnelin katkeaminen on odotettua käytöstä, josta asiakkaan pitäisi toipua herätessään. Työasemassa, jonka pitäisi pysyä tavoitettavissa, unikäytäntö on se, mitä pitää muuttaa. Sen päättäminen, kumpaa näistä kahdesta koneesta katsot, vaatii yhden kysymyksen, eikä se ole kysymys, johon loki voi vastata puolestasi.
Muuta sitä kirjautuneeseen istuntoon kuuluvilla säätimillä tai järjestelmänvalvojan tukemalla mekanismilla, jos vaatimus koskee koko konetta. Näyttöhallinnan asetuksen muokkaaminen toisella tilillä kirjautuneena ei ole sama toimenpide ja näyttää toimineen seuraavan istunnon alkuun asti. Virranhallinnan täydellinen poistaminen käytöstä on laaja ensireaktio, joka maksaa akunkestoa ja kätkee varsinaisen käytäntökysymyksen.
Tarkistus neljä: jos se pysyi hereillä, katso verkkoa ja asiakasta
Hereillä olevalla koneella, joka menetti tunnelinsa, on yksi kolmesta tarinasta: liityntäverkko putosi, VPN-asiakas pysähtyi tai käynnistyi uudelleen, tai palvelinpuoli päästi liitoksen vanhenemaan, kun asiakas uskoi edelleen olevansa yhteydessä. Vertaa taustalla olevan linkkitapahtuman aikaleimoja tunnelitapahtumaan ja ole täsmällinen siitä, kumpi tuli ensin.
Testaa sitten palautumispolku erikseen alkuperäisestä istunnosta. Uusi pyyntö palautetun tunnelin kautta voi onnistua, vaikka ennen katkoa avattu pitkäikäinen sovellusistunto pysyy rikki, koska sovellus pitää vanhentunutta pistoketta tai välimuistiin tallennettua osoitetta. Se on sovellusongelma, ei todiste siitä, että tunneli ei palannut.
Mitä hyödyllinen raportti sisältää
Kirjoita järjestys aikaleimoineen ja omistajineen: milloin istunto lukittiin, milloin näyttö pimeni, kirjattiinko unipyyntö, milloin linkki putosi ja palasi, milloin tunneli vaihtoi tilaa ja mitä sovellus todella teki. Jokaisella rivillä on omistaja, joten jokainen rivi voidaan antaa oikealle henkilölle sen sijaan, että siitä tulisi yleinen valitus Linuxista.
Jos jokin noista riveistä puuttuu, se on seuraava mitattava asia eikä seuraava muutettava asia. Aukon sisältävä aikajana on informatiivisempi kuin aavistuksen perusteella tehty asetusmuutos.