Tunneli on alhaalla, mutta kone käyttäytyy yhä kuin se olisi ylhäällä: kysely roikkuu, kunnes se aikakatkaistaan, ja reitti osoittaa rajapintaan, jota ei enää ole. Se on sellaisen openconnect-prosessin allekirjoitus, joka kuoli suorittamatta irrotusapuriaan. Sen luoma verkkotila on yhä asennettu, eikä mikään muu järjestelmässä tiedä, miten se poistetaan.

Käy kone läpi siinä järjestyksessä, jossa tila luotiin: prosessi, linkki, reitti, resolver. Jokainen vaihe kertoo, onko asiakas todella poistunut vai vain irronnut päätteestäsi, ja tämä ero ratkaisee, korjaatko ylipäätään mitään.

Aloita prosessista, älä kokoonpanosta

Avaa pääte ja kysy, mitä vielä on käynnissä, ennen kuin kosket reittiin. pgrep -a openconnect luettelee jokaisen instanssin argumentteineen, mikä näyttää pid-tiedoston ja sille annetun skriptin. Prosessi, jota et odottanut, selittää aavesolmun nopeammin kuin mikään loki.

Jos mitään ei ole käynnissä, katso linkkiä. ip link show tun0 kertoo, selvisikö rajapinta hengissä, ja ip route show dev tun0 luettelee reitit, jotka ovat yhä sidottuja siihen. Tarkista sitten resolver komennolla resolvectl status. Kirjaa kaikki kolme tulostetta ennen niiden muuttamista, sillä juuri se kirjaus on tapa erottaa myöhemmin vanhentunut merkintä uudesta.

Rajapinta, joka on poissa, vie yleensä reittinsä mukanaan. Linkin yli säilyvät reitit tarkoittavat yleensä, että prosessi on yhä elossa tai että toinen asiakas omistaa laitteen.

Apuskripti on se, joka peruu muutokset

openconnect ei itse poista rajapintaa, reittejä tai resolver-merkintöjä. Se kutsuu ulkoista apuria, /etc/vpnc/vpnc-script upstream-koonnissa ja /usr/share/vpnc-scripts/vpnc-script Debian- ja Ubuntu-paketeissa, valittuna komennolla -s. Sama skripti, joka pystyttää tunnelin, purkaa sen.

Jos prosessi poistuu kutsumatta tätä apuria, tila jää. OpenConnect-käsikirja on yksiselitteinen siitä, että reititys ja nimipalvelu eivät toimi oikein ilman skriptiä, ja se kuvaa apurin komponenttina, joka purkaa rajapinnan tilan poistuessa. Siksi polulla on väliä, kun käynnistät asiakkaan komennolla -s.

Mikä signaali tuolle polulle päätyy, muuttui versioiden välillä. Version 7.06 käsikirja pitää SIGTERM:iä välittömänä poistumisena, joka ohittaa skriptin. Nykyiset koontiversiot dokumentoivat INT:n ja TERM:n puhtaana pysäytyksenä, jossa istunto kirjataan ulos ja apuri ajetaan. Lue sen binäärin SIGNALS-osio, joka sinulla todella on, sen sijaan että olettaisit jomman kumman käytöksen.

man openconnect | sed -n '/^SIGNALS/,/^LIMITATIONS/p'

Lähetä signaali, jonka koontiversiosi dokumentoi

Kun tiedät signaalin, pysäytä prosessi pidin perusteella, älä kuvion.

pgrep -a openconnect
sudo kill -INT "$(cat /var/run/openconnect.pid)"

Toista sitten ensimmäisen osion kolme tarkistusta sen sijaan että luottaisit poistumistilaan. ip link show tun0 pitäisi epäonnistua, ip route show dev tun0 ei pitäisi tulostaa mitään, ja resolvectl status ei pitäisi enää luetella VPN-linkkiä.

SIGHUP ei ole pysäytysnappi: se katkaisee yhteyden, ajaa skriptin ja jättää istunnon jatkettavaksi komennolla --cookie. SIGUSR2 pakottaa välittömän uudelleenyhdistämisen. SIGKILL ohittaa siivouksen kokonaan, ja juuri siitä tilasta tämä artikkeli kertoo.

Korjaa resolver korvaamatta resolv.conf-tiedostoa

Useimmissa Ubuntu-järjestelmissä /etc/resolv.conf on symbolinen linkki systemd-resolvediin, ei tiedosto, jota sinun pitäisi muokata. Sen korvaaminen rikkoo nimien selvityksen kaikissa verkoissa, ei vain VPN:ssä. Poista sen sijaan tunnelin rekisteröinti:

resolvectl revert tun0
resolvectl query example.com

Jos järjestelmä käyttää systemd-resolvedin sijaan resolvconffia, rajapintakohtainen tietue säilyy, kunnes sitä käsketään pudottamaan linkki, ja resolvconf -d tun0 on vastaava toimenpide. Tarkista, mitä resolveria käytetään, ennen kuin valitset komennon.

Kysely, joka kohdistuu yhä kuolleen linkin takana olevaan palvelimeen, roikkuu, kunnes se aikakatkaistaan, ja se viive näyttää rikkinäiseltä DNS-palvelimelta eikä jäljelle jääneeltä reitiltä.

Tee seuraavasta irrotuksesta tylsä

Pidä pid-tiedoston polku samana käynnistyksessä ja sammutuksessa antamalla --pid-file joka kerta, tai aja openconnect unitin alla jonka KillSignal vastaa signaalia, jonka versiosi dokumentoi. Testaaminen ensin etualalla näyttää sammutusviestit, jotka apuri tulostaa.

Yhdistä, irrota ja aja kolme tarkistusta kerran. Puhdas poistuminen ei jätä VPN-linkkiä, VPN-reittiä eikä VPN-resolver-merkintää. Jos yksi kolmesta selviää, tiedät nyt, mikä komponentti ei siivonnut. Seuraava tutkinta alkaa silloin siitä vastauksesta eikä roikkuvasta kyselystä.

Aiheeseen liittyvät artikkelit