Mac VPN prisijungia vieną kartą, tada baigiasi laikas: išvalykite IKE tarnybą

Pirmas prisijungimas po perkrovimo veikia. Kiekvienas vėlesnis bandymas pakimba prisijungimo etape ir galiausiai baigiasi laiko pasibaigimu, o vienintelis patikimas būdas – dar vienas perkrovimas. Šis modelis nėra profilio problema ir tai nėra prisijungimo duomenų problema. Kažkas fone vis dar laiko ankstesnio bandymo būseną, ir kitas bandymas su ja susiduria.

macOS sistemoje tas kažkas paprastai yra IKE tarnyba.

Modelis: vienas prisijungimas, tada laiko pabaiga

Ryšys, veikiantis tiksliai vieną kartą per įkrovimą, rodo būseną, kuri išlieka atsijungus, bet neišlieka perkrovus. Profiliai išlieka abiem atvejais, tad profilis nėra kintamasis. Prisijungimo duomenys taip pat išlieka abiem atvejais, nebent serveris užrakina paskyrą. Perkraunant keičiasi veikiančių tarnybų rinkinys ir jų laikomi lizdai.

Tai susiaurina tyrimą dar neatsidarius nė vieno žurnalo. Klausimas tampa, kuris procesas valdo IKE prievadą ir ką jis mano darąs.

Dvi tarnybos, vienas prievadas

Sistema paleidžia racoon kai ryšys kalba IKE 1 versija. Dabartiniai leidimai taip pat atneša iked IKEv2 ir naujesniam IPsec rinkiniui. Abu gali užimti UDP 500 ir UDP 4500, ir abu gali išlaikyti pusiau atvirą saugos asociaciją po to, kai prisijungimo bandymas atšaukiamas slaptažodžio raginime arba nutraukiamas dėl tinklo pasikeitimo.

Kai taip nutinka, kitas bandymas neprasideda švariai. Jis bando derėtis, kol sena asociacija vis dar užima partnerio būseną, ir mainai sustoja, o ne nepavyksta su aiškia klaida. Vartotojas mato sukantį indikatorių, tada laiko pabaigą.

Raskite savininką prieš ką nors žudydami, nes atsakymas nulemia, kurią paslaugą paleisite iš naujo ir kurį žurnalą skaitysite toliau.

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

Skaitykite išvestį kaip du faktus: kuris procesas laiko prievadą ir ar jų yra daugiau nei vienas. Dvi IKE tarnybos, konkuruojančios dėl to paties lizdo, paaiškina daug protarpinio elgesio, kuris atrodo kaip nestabilus serveris.

Paleiskite iš naujo užduotį, o ne procesą

Senesnėse sistemose pakanka nužudyti procesą ir leisti kitam prisijungimui jį paleisti. Dabartiniuose leidimuose tarnybą valdo launchd, o signalas vien procesui gali palikti užduotį tokioje būsenoje, kai ji nei veikia, nei suplanuota paleisti. Vietoj to sustabdykite ir paleiskite užduotį.

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

Jei launchd neturi užduoties įrašo, proceso nužudymas pagal pavadinimą vis tiek priverčia naujas derybas kitame bandyme. Testas abiem atvejais tas pats: joks procesas neturėtų laikyti prievado, kai bandote prisijungti iš naujo. Patvirtinkite tai ta pačia komanda lsof užuot manius, kad perkrovimas suveikė.

Tada prisijunkite vieną kartą ir skaitykite kliento žurnalą nuo pradžių. Derybos, kurios pereina 1 fazę ir tada praneša apie perdavimo klaidą, kartoja vietinę lizdo problemą; partnerio atmestos derybos yra visiškai kitas bilietas.

Kai atsisako pats serveris

Ne kiekvienas antras prisijungimas nepavyksta lokaliai. Serveris gali atsisakyti naujo prisijungimo fiksuotam langui po atsijungimo, o kliento laiko pabaiga atrodo identiškai kaip įstrigusi tarnyba. Skirtukas pigus: jei tarnybos paleidimas iš naujo nepadeda, bet kita paskyra prisijungia iš karto, langas yra serverio pusėje ir Mac niekada nebuvo problema.

Padalinto tunelio politika sukuria tą pačią formą iš kitos pusės. Serveris, reikalaujantis viso srauto tunelyje, derybų metu atmes klientą, sukonfigūruotą padalintam tuneliui, ir klientas praneš apie laiko pabaigą, o ne apie politikos atmetimą. Profilio pakeitimas siųsti viską per tunelį gali leisti prisijungti, bet tai politikos sprendimas, kurį reikia priimti su tinklo savininku, o ne tyliai taikomas remontas.

Skaitykite partnerio žurnalą prieš vėl keisdami klientą. Atmetimas, politikos neatitikimas ir tylus numetimas yra trys skirtingos priežastys, kurios Mac ekrane visos atrodo kaip „jungiamasi“.

Senesni klientai ir 64 bitų branduolys

Senas Cisco IPSec klientas įkelia branduolio plėtinį, sukurtą 32 bitų ir PowerPC sistemoms. Mac, įkrautame su 64 bitų branduoliu, tas plėtinys negali įsikelti, ir klientas anksti nepavyksta su 51 klaida, nes visiškai nepasiekia VPN posistemės. Joks tarnybos perkrovimų kiekis nepataiso neteisingos architektūros branduolio plėtinio.

Plėtinio perkrovimas gali veikti kurį laiką ir tada vėl nepavykti kitame įkrovime. Ilgalaikiai atsakymai – paleisti senesnį branduolį ten, kur jis dar palaikomas, arba pereiti prie įtaisyto kliento, kuris ateina su sistema. Patikrinkite architektūrą prieš praleisdami vakarą su trečiosios šalies klientu, kuris nesikrauna.

• Atkurkite vieną kartą, tada patikrinkite, kuri tarnyba valdo UDP 500, prieš liesdami profilį.
• Skaitykite pirmą nepavykimą po 1 fazės: perdavimo klaida rodo į vietinį lizdą.
• Paleiskite iš naujo launchd užduotį, ne tik procesą, ir patvirtinkite, kad prievadas laisvas.
• Išbandykite antrą paskyrą, kad atskirtumėte serverio pusės pakartotinės autentifikacijos langą nuo kliento gedimo.
• Užsirašykite branduolio architektūrą prieš kaltindami klientą.

VPN, veikiantis tiksliai vieną kartą, yra būsenos problema, kol neįrodyta priešingai. Tarnybos išvalymas greitesnis už perkrovimą, ir jis išsaugo žurnalo įrodymus, kuriuos perkrovimas būtų išmetęs.