VPN na Macu se poveže enkrat, nato poteče čas: počistite demona IKE

Prva povezava po ponovnem zagonu deluje. Vsak naslednji poskus obvisi v fazi povezovanja in na koncu poteče čas, edino zanesljivo zdravilo pa je še en ponovni zagon. Ta vzorec ni težava profila in ni težava poverilnic. Nekaj v ozadju še vedno drži stanje iz prejšnjega poskusa in naslednji poskus trči ob to.

V macOS je to nekaj običajno demon IKE.

Vzorec: ena povezava, nato potek časa

Povezava, ki deluje natanko enkrat na zagon, kaže na stanje, ki preživi prekinitev, ne pa ponovnega zagona. Profili preživijo oboje, zato profil ni spremenljivka. Poverilnice preživijo oboje, razen če strežnik zaklene račun. Kar se spremeni pri zagonu, je nabor delujočih demonov in vtičnice, ki jih držijo.

To zoži preiskavo, preden odprete en sam dnevnik. Vprašanje postane, kateri proces ima vrata IKE in kaj misli, da dela.

Dva demona, ena vrata

Sistem zažene racoon ko povezava govori IKE različico 1. Trenutne izdaje prinesejo tudi iked za IKEv2 in novejši sklad IPsec. Oba lahko zasedeta UDP 500 in UDP 4500 in oba lahko obdržita napol odprto varnostno asociacijo potem, ko je poskus povezave preklican ob pozivu za geslo ali prekinjen zaradi spremembe omrežja.

Ko se to zgodi, se naslednji poskus ne začne čisto. Poskuša se pogajati, medtem ko stara asociacija še vedno zaseda stanje partnerja, in izmenjava se ustavi, namesto da bi spodletela z jasno napako. Uporabnik vidi vrteči se indikator, nato potek časa.

Poiščite lastnika, preden karkoli ubijete, ker odgovor določa, katero storitev znova zaženete in kateri dnevnik boste brali naslednji.

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

Izhod berite kot dve dejstvi: kateri proces drži vrata in ali je prisotnih več kot eden. Dva demona IKE, ki tekmujeta za isto vtičnico, pojasnita veliko občasnega vedenja, ki izgleda kot nestabilen strežnik.

Znova zaženite opravilo, ne procesa

Na starejših sistemih je dovolj, da ubijete proces in pustite naslednji povezavi, da ga znova zažene. V trenutnih izdajah demona upravlja launchd, in samo pošiljanje signala procesu lahko pusti opravilo v stanju, ko niti ne teče niti ni načrtovano za zagon. Namesto tega ustavite in zaženite opravilo.

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

Če launchd nima zapisa o opravilu, ubijanje procesa po imenu še vedno vsili novo pogajanje pri naslednjem poskusu. Preizkus je v obeh primerih enak: noben proces ne bi smel držati vrat, ko se poskusite znova povezati. Potrdite to z istim ukazom lsof namesto da bi domnevali, da je ponovni zagon uspel.

Nato se enkrat povežite in preberite dnevnik odjemalca od začetka. Pogajanje, ki pride prek faze 1 in nato poroča o napaki prenosa, ponavlja lokalno težavo z vtičnico; pogajanje, ki ga partner zavrne je povsem druga vozovnica.

Ko zavrača strežnik

Vsaka druga povezava ne spodleti lokalno. Strežnik lahko po prekinitvi zavrne novo prijavo za določeno okno in odjemalčev potek časa je videti enako kot obtičali demon. Razlikovanje je poceni: če ponovni zagon demona ne pomaga, drug račun pa se poveže takoj, je okno na strani strežnika in Mac nikoli ni bil težava.

Politika razdeljenega tunela ustvari enako obliko z druge strani. Strežnik, ki zahteva ves promet v tunelu, bo med pogajanjem zavrgel odjemalca, nastavljenega za razdeljeni tunel, in odjemalec bo poročal o poteku časa namesto o zavrnitvi politike. Spreminjanje profila, da gre vse skozi tunel, mu lahko omogoči povezavo, vendar je to odločitev o politiki, ki jo je treba sprejeti z lastnikom omrežja, ne popravilo, ki bi ga tiho uporabili.

Preberite dnevnik partnerja, preden znova spremenite odjemalca. Zavrnitev, neskladje politike in tiho odvrženje so trije različni vzroki, ki so na zaslonu Maca videti vsi kot „povezovanje“.

Starejši odjemalci in 64-bitno jedro

Stari odjemalec Cisco IPSec naloži razširitev jedra, zgrajeno za 32-bitne sisteme in PowerPC. Na Macu, zagnanem v 64-bitno jedro, se ta razširitev ne more naložiti, in odjemalec zgodaj spodleti z napako 51, ker sploh ne doseže podsistema VPN. Nobeno ponovno zaganjanje demona ne popravi razširitve jedra z napačno arhitekturo.

Ponovno nalaganje razširitve lahko deluje nekaj časa in nato ob naslednjem zagonu znova spodleti. Trajna odgovora sta zagnati starejše jedro tam, kjer je še podprto, ali preiti na vgrajenega odjemalca, ki pride s sistemom. Preverite arhitekturo, preden preživite večer z odjemalcem tretje strani, ki se ne more naložiti.

• Reproducirajte enkrat, nato preverite, kateri demon ima UDP 500, preden se dotaknete profila.
• Preberite prvo spodletelost po fazi 1: napaka prenosa kaže na lokalno vtičnico.
• Znova zaženite opravilo launchd, ne le procesa, in potrdite, da so vrata prosta.
• Poskusite drug račun, da ločite okno ponovnega preverjanja na strani strežnika od okvare odjemalca.
• Zapišite arhitekturo jedra, preden obtožite odjemalca.

VPN, ki deluje natanko enkrat, je težava stanja, dokler ni dokazano nasprotno. Čiščenje demona je hitrejše od ponovnega zagona in ohrani dokaze iz dnevnika, ki bi jih ponovni zagon zavrgel.