Mac-VPN verbind een keer, dan time-out: ruim die IKE-daemon op

Die eerste verbinding ná 'n herstarting werk. Elke poging daarna hang by die verbindingstadium en eindig uiteindelik in 'n time-out, en die enigste betroubare oplossing is nog 'n herstarting. Daardie patroon is nie 'n profielprobleem nie en dit is nie 'n geloofsbriewe-probleem nie. Iets in die agtergrond hou steeds die toestand van die vorige poging vas, en die volgende poging bots daarmee.

Op macOS is daardie iets gewoonlik die IKE-daemon.

Die patroon: verbind een keer, dan time-out

'n Verbinding wat presies een keer per herstarting werk, dui op toestand wat 'n ontkoppeling oorleef maar nie 'n herstarting nie. Profiele oorleef albei, dus is die profiel nie die veranderlike nie. Geloofsbriewe oorleef ook albei, tensy die bediener die rekening sluit. Wat by 'n herstarting verander, is die stel lopende daemons en die sokkels wat hulle hou.

Dit vernou die ondersoek voordat jy 'n enkele log oopmaak. Die vraag word watter proses die IKE-poort besit en wat dit dink dit doen.

Twee daemons, een poort

Die stelsel gebruik racoon wanneer 'n verbinding IKE-weergawe 1 praat. Huidige uitgawes bring ook iked vir IKEv2 en die nuwer IPsec-stapel. Albei kan UDP 500 en UDP 4500 bind, en albei kan 'n halfoop sekuriteitsassosiasie hou nadat 'n verbindingspoging by die wagwoordprompt gekanselleer of deur 'n netwerkverandering onderbreek is.

Wanneer dit gebeur, begin die volgende poging nie skoon nie. Dit probeer onderhandel terwyl die ou assosiasie steeds die eweknie se toestand beset, en die uitruiling staak in plaas daarvan om met 'n duidelike fout te misluk. Die gebruiker sien 'n draaier, dan 'n time-out.

Vind die eienaar voordat jy enigiets doodmaak, want die antwoord bepaal watter diens jy herbegin en watter log jy volgende lees.

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

Lees die uitset as twee feite: watter proses die poort hou, en of meer as een daarvan teenwoordig is. Twee IKE-daemons wat om dieselfde sokkel meeding, verduidelik baie wisselvallige gedrag wat soos 'n onbetroubare bediener lyk.

Herbegin die taak eerder as die proses

Op ouer stelsels is dit genoeg om die proses dood te maak en die volgende verbinding dit weer te laat begin. Op huidige uitgawes word die daemon deur launchd bestuur, en om net die proses 'n sein te stuur kan die taak in 'n toestand laat waar dit nóg loop nóg geskeduleer is om te begin. Stop en begin eerder die taak.

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

As launchd geen rekord van die taak het nie, dwing om die proses by naam dood te maak steeds 'n nuwe onderhandeling by die volgende poging af. Die toets is in elk geval dieselfde: geen proses behoort die poort te hou wanneer jy weer probeer verbind nie. Bevestig dit met dieselfde lsof opdrag eerder as om aan te neem die herstarting het gewerk.

Verbind dan een keer en lees die kliëntlog van die begin af. 'n Onderhandeling wat verby fase 1 vorder en dan 'n oordragfout rapporteer, herhaal die plaaslike sokkelprobleem; 'n onderhandeling wat die eweknie verwerp is heeltemal 'n ander kaartjie.

Wanneer dit die bediener is wat weier

Nie elke tweede verbinding misluk plaaslik nie. 'n Bediener kan 'n nuwe aanmelding vir 'n vaste venster ná 'n ontkoppeling weier, en die kliënt se time-out lyk identies aan 'n vasgehaakte daemon. Die onderskeider is goedkoop: as die herbegin van die daemon nie help nie, maar 'n ander rekening dadelik verbind, is die venster aan die bedienerkant en was die Mac nooit die probleem nie.

Beleid vir 'n gesplete tonnel lewer dieselfde vorm uit die ander rigting. 'n Bediener wat alle verkeer in die tonnel vereis, sal 'n kliënt wat vir 'n gesplete tonnel ingestel is tydens die onderhandeling laat val, en die kliënt rapporteer 'n time-out eerder as 'n beleidsverwerping. Om die profiel te verander om alles deur die tonnel te stuur, kan dit laat verbind, maar dit is 'n beleidsbesluit om met die netwerkeienaar te neem, nie 'n herstelling om stilweg toe te pas nie.

Lees die eweknie se log voordat jy die kliënt weer verander. 'n Verwerping, 'n beleidswanpassing en 'n stille val is drie verskillende oorsake wat almal soos “verbind” op die Mac se skerm lyk.

Ouer kliënte en die 64-bis kern

Die ou Cisco IPSec-kliënt laai 'n kernuitbreiding wat vir 32-bis- en PowerPC-stelsels gebou is. Op 'n Mac wat in die 64-bis kern begin het, kan daardie uitbreiding nie laai nie, en die kliënt misluk vroeg met fout 51 omdat dit glad nie die VPN-subsisteem kan bereik nie. Geen hoeveelheid herbegin van die daemon maak 'n kernuitbreiding reg wat die verkeerde argitektuur het nie.

Om die uitbreiding te herlaai kan 'n ruk werk en dan weer by die volgende herstarting misluk. Die duursame antwoorde is om die ouer kern te gebruik waar dit nog ondersteun word, of om oor te skakel na die ingeboude kliënt wat by die stelsel gelewer word. Kontroleer die argitektuur voordat jy 'n aand aan 'n derdeparty-kliënt bestee wat nie kan laai nie.

• Reproduseer een keer en kyk dan watter daemon UDP 500 besit voordat jy aan die profiel raak.
• Lees die eerste mislukking ná fase 1: 'n oordragfout dui op die plaaslike sokkel.
• Herbegin die launchd-taak, nie net die proses nie, en bevestig dat die poort vry is.
• Probeer 'n tweede rekening om 'n bedienerkant-herverifikasievenster van 'n kliëntfout te skei.
• Teken die kernargitektuur aan voordat jy die kliënt die skuld gee.

'n VPN wat presies een keer werk, is 'n toestandprobleem tot die teendeel bewys word. Om die daemon skoon te maak is vinniger as om te herbegin, en dit bewaar die logbewyse wat 'n herstarting sou weggooi.