Maci VPN ühendub korra ja siis aegub: puhastage IKE-deemon

Esimene ühendus pärast taaskäivitust töötab. Iga järgnev katse jääb ühendumise faasis rippuma ja lõpuks aegub ning ainus usaldusväärne ravim on veel üks taaskäivitus. See muster ei ole profiili probleem ja see ei ole õigustunnuste probleem. Midagi taustal hoiab endiselt eelmise katse olekut ja järgmine katse põrkub sellega kokku.

MacOS-is on see midagi tavaliselt IKE-deemon.

Muster: üks ühendus, siis aegumine

Ühendus, mis töötab täpselt korra käivituse kohta, viitab olekule, mis elab üle katkestuse, aga mitte taaskäivitust. Profiilid elavad üle mõlemad, seega profiil ei ole muutuja. Õigustunnused elavad samuti üle mõlemad, kui server kontot ei lukusta. Mis taaskäivitusel muutub, on jooksvate deemonite hulk ja nende hoitavad soketid.

See kitsendab uurimist enne, kui avate ühegi logi. Küsimuseks saab, milline protsess omab IKE-porti ja mida see arvab end tegevat.

Kaks deemonit, üks port

Süsteem käivitab racoon kui ühendus räägib IKE versiooni 1. Praegused väljaanded toovad kaasa ka iked IKEv2 ja uuema IPsec-virna jaoks. Mõlemad võivad hõivata UDP 500 ja UDP 4500 ning mõlemad võivad hoida poolavatud turvaassotsiatsiooni pärast seda, kui ühenduskatse tühistatakse parooli küsimuses või katkestatakse võrgu muutumise tõttu.

Kui see juhtub, ei alga järgmine katse puhtalt. See üritab läbirääkimisi pidada, samal ajal kui vana assotsiatsioon hõivab endiselt partneri olekut, ja vahetus takerdub, selle asemel et selge veaga läbi kukkuda. Kasutaja näeb pöörlevat indikaatorit, seejärel aegumist.

Leidke omanik enne, kui midagi tapate, sest vastus määrab, millist teenust te taaskäivitate ja millist logi järgmisena loete.

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

Lugege väljundit kahe faktina: milline protsess hoiab porti ja kas neid on rohkem kui üks. Kaks IKE-deemonit, mis võistlevad sama soketi pärast, selgitavad palju katkendlikku käitumist, mis näeb välja nagu ebausaldusväärne server.

Taaskäivitage töö, mitte protsess

Vanemates süsteemides piisab protsessi tapmisest ja järgmise ühenduse laskmisest see uuesti käivitada. Praegustes väljaannetes haldab deemonit launchd ja ainult protsessile signaali saatmine võib jätta töö olekusse, kus see ei tööta ega ole ka käivitamiseks planeeritud. Peatage ja käivitage hoopis töö.

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

Kui launchd-il pole tööst kirjet, sunnib protsessi nime järgi tapmine järgmisel katsel ikkagi värske läbirääkimise. Test on mõlemal juhul sama: ükski protsess ei tohiks porti hoida, kui proovite uuesti ühenduda. Kinnitage seda sama käsuga lsof selle asemel, et eeldada, et taaskäivitus toimis.

Seejärel ühenduge korra ja lugege kliendi logi algusest. Läbirääkimine, mis liigub faasist 1 edasi ja teatab seejärel ülekandevigast, kordab kohalikku soketi probleemi; partneri poolt tagasi lükatud läbirääkimine on täiesti erinev pilet.

Kui keelduja on server

Mitte iga teine ühendus ei ebaõnnestu kohapeal. Server võib pärast katkestust keelduda uuest sisselogimisest kindla akna jooksul ja kliendi aegumine näeb identne välja nagu kinnijäänud deemon. Eristaja on odav: kui deemoni taaskäivitamine ei aita, aga teine konto ühendub kohe, on aken serveripoolne ja Mac ei olnud kunagi probleem.

Jagatud tunneli poliitika tekitab sama kuju teisest suunast. Server, mis nõuab kogu liiklust tunnelis, viskab läbirääkimise ajal välja jagatud tunnelile konfigureeritud kliendi ja klient teatab aegumisest, mitte poliitika tagasilükkamisest. Profiili muutmine, et saata kõik läbi tunneli, võib selle ühendada, kuid see on poliitika otsus, mis tuleb teha võrgu omanikuga, mitte parandus, mida vaikselt rakendada.

Lugege partneri logi enne, kui klienti uuesti muudate. Tagasilükkamine, poliitika mittevastavus ja vaikne mahaviskamine on kolm erinevat põhjust, mis kõik näevad Maci ekraanil välja nagu “ühendub”.

Vanemad kliendid ja 64-bitine tuum

Vana Cisco IPSec klient laadib tuumalaienduse, mis on ehitatud 32-bitistele ja PowerPC süsteemidele. Macis, mis on käivitatud 64-bitises tuumas, ei saa see laiendus laadida ja klient ebaõnnestub varakult veaga 51, sest see ei jõua VPN alamsüsteemini üldse. Ükski kogus deemoni taaskäivitamist ei paranda vale arhitektuuriga tuumalaiendust.

Laienduse uuesti laadimine võib mõnda aega töötada ja siis järgmisel käivitusel uuesti ebaõnnestuda. Püsivad vastused on kasutada vanemat tuuma seal, kus see on veel toetatud, või liikuda süsteemiga kaasas oleva sisseehitatud kliendi juurde. Kontrollige arhitektuuri enne, kui kulutate õhtu kolmanda osapoole kliendile, mida ei saa laadida.

• Taastage kord ja seejärel kontrollige, milline deemon omab UDP 500, enne kui profiili puudutate.
• Lugege esimest ebaõnnestumist pärast faasi 1: ülekandeviga viitab kohalikule soketile.
• Taaskäivitage launchd töö, mitte ainult protsess, ja kinnitage, et port on vaba.
• Proovige teist kontot, et eraldada serveripoolne uuesti autentimise aken kliendi rikkest.
• Kirjutage üles tuuma arhitektuur enne, kui klienti süüdistate.

VPN, mis töötab täpselt korra, on olekuprobleem, kuni pole tõestatud vastupidist. Deemoni puhastamine on kiirem kui taaskäivitamine ja see säilitab logitõendid, mille taaskäivitus oleks ära visanud.