VPN na Macu se připojí jednou a pak vyprší: vyčistěte démona IKE

První připojení po restartu funguje. Každý další pokus visí ve fázi připojování a nakonec vyprší a jediným spolehlivým lékem je další restart. Tento vzorec není problém profilu a není to problém přihlašovacích údajů. Něco na pozadí stále drží stav z předchozího pokusu a další pokus se s tím střetne.

Na macOS je tou věcí obvykle démon IKE.

Vzorec: jedno připojení, pak vypršení

Připojení, které funguje přesně jednou za boot, ukazuje na stav, který přežije odpojení, ale ne restart. Profily přežijí obojí, takže profil není proměnná. Přihlašovací údaje přežijí také obojí, pokud server účet neuzamkne. Co se při restartu změní, je sada běžících démonů a soketů, které drží.

To zužuje vyšetřování, než otevřete jediný log. Otázka se stává, který proces vlastní port IKE a co si myslí, že dělá.

Dva démoni, jeden port

Systém spouští racoon když připojení mluví IKE verze 1. Současná vydání přinášejí také iked pro IKEv2 a novější zásobník IPsec. Oba mohou obsadit UDP 500 a UDP 4500 a oba mohou držet polootevřenou bezpečnostní asociaci poté, co je pokus o připojení zrušen u výzvy k zadání hesla nebo přerušen změnou sítě.

Když se to stane, další pokus nezačíná čistě. Snaží se vyjednávat, zatímco stará asociace stále zabírá stav protějšku, a výměna se zasekne, místo aby selhala s jasnou chybou. Uživatel vidí otáčející se indikátor a pak vypršení.

Najděte vlastníka, než cokoli zabijete, protože odpověď určuje, kterou službu restartujete a který log budete číst dál.

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

Čtěte výstup jako dvě skutečnosti: který proces drží port a zda je jich přítomno víc než jeden. Dva démoni IKE soutěžící o stejný soket vysvětlují hodně občasného chování, které vypadá jako nestabilní server.

Restartujte úlohu, ne proces

Na starších systémech stačí proces zabít a nechat další připojení, ať ho znovu spustí. V současných vydáních démona spravuje launchd a pouhý signál procesu může úlohu nechat ve stavu, kdy ani neběží, ani není naplánována ke spuštění. Místo toho úlohu zastavte a spusťte.

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

Pokud launchd o úloze nemá záznam, zabití procesu podle jména stejně vynutí nové vyjednávání při dalším pokusu. Test je v obou případech stejný: žádný proces by neměl držet port, když se znovu pokusíte připojit. Potvrďte to stejným příkazem lsof místo předpokladu, že restart zabral.

Potom se jednou připojte a přečtěte klientský log od začátku. Vyjednávání, které postoupí za fázi 1 a poté hlásí chybu přenosu, opakuje místní problém se soketem; vyjednávání odmítnuté protějškem je úplně jiná vstupenka.

Když odmítá server

Ne každé druhé připojení selže lokálně. Server může po odpojení odmítnout nové přihlášení po pevně dané okno a časový limit klienta vypadá stejně jako zaseknutý démon. Rozlišovač je levný: pokud restart démona nepomůže, ale jiný účet se připojí okamžitě, okno je na straně serveru a Mac nikdy nebyl problém.

Politika rozděleného tunelu vytváří stejný tvar z opačné strany. Server, který vyžaduje veškerý provoz v tunelu, zahodí klienta nakonfigurovaného pro rozdělený tunel během vyjednávání a klient hlásí vypršení místo odmítnutí politiky. Změna profilu, aby vše šlo tunelem, ho může připojit, ale to je rozhodnutí o politice, které se dělá s vlastníkem sítě, ne oprava, kterou lze tiše nasadit.

Přečtěte log protějšku, než klienta znovu změníte. Odmítnutí, nesoulad politiky a tiché zahození jsou tři různé příčiny, které na obrazovce Macu vypadají všechny jako „připojování“.

Starší klienti a 64bitové jádro

Starý klient Cisco IPSec načítá rozšíření jádra postavené pro 32bitové systémy a PowerPC. Na Macu zavedeném do 64bitového jádra se toto rozšíření nemůže načíst a klient brzy selže s chybou 51, protože se vůbec nedostane k podsystému VPN. Žádné restartování démona neopraví rozšíření jádra se špatnou architekturou.

Opětovné načtení rozšíření může chvíli fungovat a pak při dalším bootu znovu selhat. Trvalá řešení jsou spustit starší jádro tam, kde je ještě podporováno, nebo přejít na vestavěného klienta, který je součástí systému. Zkontrolujte architekturu, než strávíte večer u klienta třetí strany, který se nedá načíst.

• Reprodukujte jednou, pak zkontrolujte, který démon vlastní UDP 500, než se dotknete profilu.
• Přečtěte první selhání po fázi 1: chyba přenosu ukazuje na místní soket.
• Restartujte úlohu launchd, ne jen proces, a potvrďte, že port je volný.
• Zkuste druhý účet, abyste oddělili okno opakovaného ověření na straně serveru od závady klienta.
• Zaznamenejte architekturu jádra, než obviníte klienta.

VPN, které funguje přesně jednou, je problém stavu, dokud se neprokáže opak. Vyčištění démona je rychlejší než restart a zachová důkazy z logu, které by restart zahodil.