VPN ilmoittaa olevansa yhteydessä, mutta oletusreitti on kuollut

Asiakas ilmoittaa olevansa yhteydessä, ilmaisinalueen kuvake näyttää normaalilta, eikä mikään lataudu. Se alkoi heti, kun siirryit Wi-Fistä kaapeliin, tai heti jakelun päivityksen päätyttyä. Rikki ei mennyt profiili vaan tila, joka rakennettiin edellistä perusyhteyttä varten. Ytimellä on yhä oletusreitti, joka osoittaa tunnelilaitteeseen, jota kukaan ei omista, tai resolveri luettelee yhä palvelimia linkillä, joka on kadonnut. Molemmat viat näyttävät kuolleelta verkolta ja molemmat voi korjata paikan päällä.

Vanhentuneet osat olivat väärin jo ennen kuin huomasit ne. Kaapelin irrottaminen teki ne vain näkyviksi.

Kysy ytimeltä, minne paketti menisi

Reittilistauksia on vaikea lukea, koska ne luettelevat kaiken, mitä järjestelmä tietää, mukaan lukien merkinnät, jotka eivät enää päde. Reittihaku vastaa ainoaan kysymiseen arvoiseen kysymykseen: mikä laite kuljettaa juuri tätä pakettia juuri nyt. Jos vastaus nimeää tunnelilaitteen, ydin käyttää sitä, vaikka sen takana ei ole yhtään elävää asiakasprosessia, ja paketti putoaa rajapintaan, jota kukaan ei ylläpidä. Jos vastaus nimeää Ethernet-sovittimen, kun asiakas väittää yhteyden olevan päällä, tunneli on olemassa mutta menetti valinnan, mikä on tavallinen tulos siirryttäessä langattomasta langalliseen.

Suorita haku kahdesti, kerran julkiselle osoitteelle ja kerran sisäiselle, koska jaetun tunnelin käytäntö voi reitittää toisen rehellisesti ja pudottaa toisen.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

Resolveri pitää myös kuolleen linkin

systemd-resolved-isännällä DNS-palvelimet kuuluvat linkeille eivätkä yhdelle globaalille listalle. Kaatuva VPN-linkki voi pysyä rekisteröitynä palvelimineen jonkin aikaa, ja silloin jokainen haku odottaa osoitetta, joka ei koskaan vastaa. Se viive tuntuu kuolleelta verkolta ja saa ihmiset katsomaan reittejä, kun reitti on kunnossa.

resolvectl status
resolvectl query intranet.example.com

Lue lohkot linkeittäin ja selvitä, mikä linkki omistaa kyseisen verkkotunnuksen. Tunneli, joka on päällä mutta ei omista sisäistä verkkotunnusta, välittää sisäiset nimet julkiselle resolverille, ja oire on erottamaton reititysvirheestä.

Korjaa rekisteröinti, älä /etc/resolv.conf. Nykyisissä Ubuntu- ja Fedora-asennuksissa tuo polku on symbolinen linkki resolverin ajonaikaiseen tilaan, joten muokkaus joko jätetään huomiotta tai kirjoitetaan yli seuraavassa verkkotapahtumassa.

VPN ei koskaan käynnisty itsestään

NetworkManager nostaa VPN:n perusyhteyden päälle ja oppii, mitä seurata, connection.secondaries kyseiseltä perustalta. Yhteyden asetusten viite toteaa selvästi, että automaattinen yhdistäminen ei ole toteutettu VPN-profiileille. Se on koko mekanismi tämän vikaluokan takana: vaihda perusta, ja VPN on paritettava uudelleen tai aktivoitava käsin.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

Kun aktiivilista näyttää perustan ilman VPN:ää, tunneli ei ole lainkaan aktiivinen ja reittiä ei koskaan asennettu sen sijaan että se olisi jäänyt vanhentuneeksi. Kun aktivointi valittaa, ettei lähdeyhteyttä ole, perusta, jonka kanssa se oli paritettu, on kadonnut, joten korjaa ensin perusta tai paritus ja lopeta VPN:n uudelleen yrittäminen.

Päivitys voi pudottaa asetuksia ilman ilmoitusta

Jakelun päivittäminen korvaa asiakkaan ja usein sen NetworkManager-liitännäisen, kun taas tallennettu profiili säilyttää ne ominaisuuksien nimet, joilla se kirjoitettiin. Kaikki, mitä uusi liitännäinen ei enää tunnista, ohitetaan hiljaisesti. Profiili aktivoituu yhä ja laite ilmestyy yhä, mutta reitti, joka ennen tuli sen mukana, ei enää tule.

Käsin kirjoitetut koukut liikkuvat myös. Skripti, joka asensi reitin vanhan järjestyksen ennustettavassa kohdassa, voi nyt ajaa ennen kuin rajapinta on olemassa tai sen jälkeen, kun asiakas on jo aikakatkaistu.

Vertaa elävää profiilia liitännäiseen, joka sinulla todella on, älä siihen käytökseen, jonka muistat. Jos avain on kadonnut dokumentaatiosta, siirrä työ lähettäjäskriptiin tai tuettuun korvaavaan ratkaisuun sen sijaan että palauttaisit vanhan ominaisuuden.

Kolme tilaa, kolme eri korjausta

Päätä, missä tilassa olet, ennen kuin kosket mihinkään, koska uudelleenkäynnistys tuhoaa todisteet ja vika palaa seuraavassa verkkomuutoksessa.

Lopeta yhteen hakuun julkiselle osoitteelle, yhteen sisäiselle osoitteelle ja yhteen nimikyselyyn. Jos osoitteet toimivat ja nimi ei, jäljellä oleva vika on verkkotunnuksen laajuus resolverissa, eikä reittitaulu koskaan ollut ongelma.