Macin VPN yhdistää kerran ja aikakatkaisee sitten: tyhjennä IKE-daemon

Ensimmäinen yhteys uudelleenkäynnistyksen jälkeen toimii. Jokainen sitä seuraava yritys jää roikkumaan yhdistämisvaiheeseen ja aikakatkaisee lopulta, ja ainoa luotettava parannuskeino on uusi uudelleenkäynnistys. Tämä kuvio ei ole profiiliongelma eikä tunnistetietojen ongelma. Jokin taustalla pitää yhä edellisen yrityksen tilaa, ja seuraava yritys törmää siihen.

macOS:ssä tuo jokin on yleensä IKE-daemon.

Kuvio: yksi yhteys, sitten aikakatkaisu

Yhteys, joka toimii täsmälleen kerran käynnistystä kohden, viittaa tilaan, joka selviää katkaisusta mutta ei uudelleenkäynnistyksestä. Profiilit selviävät molemmista, joten profiili ei ole muuttuja. Tunnistetiedot selviävät myös molemmista, ellei palvelin lukitse tiliä. Uudelleenkäynnistyksessä muuttuu käynnissä olevien daemonien joukko ja niiden pitämät socketit.

Tämä kaventaa tutkintaa ennen kuin avaat yhtäkään lokia. Kysymykseksi tulee, mikä prosessi omistaa IKE-portin ja mitä se luulee tekevänsä.

Kaksi daemonia, yksi portti

Järjestelmä käynnistää racoon kun yhteys puhuu IKE-versiota 1. Nykyiset versiot tuovat myös iked IKEv2:lle ja uudemmalle IPsec-pinolle. Molemmat voivat varata UDP 500:n ja UDP 4500:n, ja molemmat voivat pitää puoliavoimen suojausliitoksen, kun yhteysyritys peruutetaan salasanakehotteessa tai keskeytetään verkon muutoksen vuoksi.

Kun näin käy, seuraava yritys ei ala puhtaasti. Se yrittää neuvotella, kun vanha liitos yhä varaa vastapuolen tilaa, ja vaihto pysähtyy sen sijaan, että se epäonnistuisi selkeällä virheellä. Käyttäjä näkee latauspyörän ja sitten aikakatkaisun.

Etsi omistaja ennen kuin tapat mitään, koska vastaus määrää, minkä palvelun käynnistät uudelleen ja mitä lokia luet seuraavaksi.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Lue tuloste kahtena tosiasiana: mikä prosessi pitää porttia ja onko niitä enemmän kuin yksi. Kaksi IKE-daemonia, jotka kilpailevat samasta socketista, selittävät paljon ajoittaista käytöstä, joka näyttää epävakaalta palvelimelta.

Käynnistä työ uudelleen, älä prosessia

Vanhemmissa järjestelmissä riittää, että tappaa prosessin ja antaa seuraavan yhteyden käynnistää sen uudelleen. Nykyisissä versioissa daemonia hallitsee launchd, ja pelkkä prosessille signalointi voi jättää työn tilaan, jossa se ei ole käynnissä eikä aikataulutettu käynnistymään. Pysäytä ja käynnistä sen sijaan työ.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Jos launchdilla ei ole merkintää työstä, prosessin tappaminen nimeltä pakottaa silti tuoreen neuvottelun seuraavalla yrityksellä. Testi on sama kummassakin tapauksessa: minkään prosessin ei pitäisi pitää porttia, kun yrität yhdistää uudelleen. Vahvista se samalla komennolla lsof sen sijaan, että olettaisit uudelleenkäynnistyksen onnistuneen.

Yhdistä sitten kerran ja lue asiakasloki alusta alkaen. Neuvottelu, joka etenee vaiheen 1 ohi ja raportoi sitten siirtovirheen, toistaa paikallisen socket-ongelman; vastapuolen hylkäämä neuvottelu on täysin eri lippu.

Kun palvelin on se, joka kieltäytyy

Jokainen toinen yhteys ei epäonnistu paikallisesti. Palvelin voi kieltäytyä uudesta kirjautumisesta kiinteän ikkunan ajan katkaisun jälkeen, ja asiakkaan aikakatkaisu näyttää identtiseltä jumiutuneen daemonin kanssa. Erottelija on halpa: jos daemonin uudelleenkäynnistys ei auta mutta toinen tili yhdistää heti, ikkuna on palvelimen puolella eikä Mac ollut koskaan ongelma.

Jaetun tunnelin käytäntö tuottaa saman muodon toisesta suunnasta. Palvelin, joka vaatii kaiken liikenteen tunneliin, pudottaa jaettuun tunneliin määritetyn asiakkaan neuvottelun aikana, ja asiakas raportoi aikakatkaisun käytännön hylkäämisen sijaan. Profiilin muuttaminen lähettämään kaikki tunnelin läpi voi saada sen yhdistämään, mutta se on käytäntöpäätös, joka tehdään verkon omistajan kanssa, ei hiljainen korjaus.

Lue vastapuolen loki ennen kuin muutat asiakasta uudelleen. Hylkääminen, käytäntöjen ristiriita ja hiljainen pudotus ovat kolme eri syytä, jotka kaikki näyttävät Macin näytöllä “yhdistää”.

Vanhemmat asiakkaat ja 64-bittinen ydin

Vanha Cisco IPSec -asiakas lataa ytimen laajennuksen, joka on rakennettu 32-bittisille ja PowerPC-järjestelmille. Macissa, joka on käynnistetty 64-bittiseen ytimeen, tuo laajennus ei voi latautua, ja asiakas epäonnistuu varhain virheellä 51, koska se ei tavoita VPN-alijärjestelmää lainkaan. Mikään määrä daemonin uudelleenkäynnistystä ei korjaa väärän arkkitehtuurin ydinlaajennusta.

Laajennuksen uudelleenlataus voi toimia hetken ja epäonnistua sitten uudelleen seuraavassa käynnistyksessä. Kestävät vastaukset ovat vanhemman ytimen käyttäminen siellä, missä sitä vielä tuetaan, tai siirtyminen järjestelmän mukana tulevaan sisäänrakennettuun asiakkaaseen. Tarkista arkkitehtuuri ennen kuin vietät illan kolmannen osapuolen asiakkaan parissa, jota ei voi ladata.

• Toista kerran ja tarkista sitten, mikä daemon omistaa UDP 500:n, ennen kuin kosket profiiliin.
• Lue ensimmäinen epäonnistuminen vaiheen 1 jälkeen: siirtovirhe osoittaa paikalliseen sockettiin.
• Käynnistä launchd-työ uudelleen, älä vain prosessia, ja vahvista, että portti on vapaa.
• Kokeile toista tiliä erottaaksesi palvelimen puolen uudelleentodennusikkunan asiakkaan viasta.
• Kirjaa ytimen arkkitehtuuri ennen kuin syytät asiakasta.

VPN, joka toimii täsmälleen kerran, on tilaongelma, kunnes toisin todistetaan. Daemonin tyhjentäminen on nopeampaa kuin uudelleenkäynnistys, ja se säilyttää lokitodisteet, jotka uudelleenkäynnistys olisi heittänyt pois.