VPN na Macu sa pripojí raz a potom vyprší: vyčistite démona IKE

Prvé pripojenie po reštarte funguje. Každý ďalší pokus visí vo fáze pripájania a nakoniec vyprší, a jediným spoľahlivým liekom je ďalší reštart. Tento vzor nie je problém profilu a nie je to problém prihlasovacích údajov. Niečo na pozadí stále drží stav z predchádzajúceho pokusu a ďalší pokus sa s tým zrazí.

Na macOS je tou vecou zvyčajne démon IKE.

Vzor: jedno pripojenie, potom vypršanie

Pripojenie, ktoré funguje presne raz za boot, ukazuje na stav, ktorý prežije odpojenie, ale nie reštart. Profily prežijú oboje, takže profil nie je premenná. Prihlasovacie údaje prežijú tiež oboje, ak server účet neuzamkne. Čo sa pri reštarte zmení, je sada bežiacich démonov a sokety, ktoré držia.

To zužuje vyšetrovanie, skôr než otvoríte jediný log. Otázkou sa stáva, ktorý proces vlastní port IKE a čo si myslí, že robí.

Dvaja démoni, jeden port

Systém spúšťa racoon keď pripojenie hovorí IKE verzia 1. Súčasné vydania prinášajú aj iked pre IKEv2 a novší zásobník IPsec. Oba môžu obsadiť UDP 500 a UDP 4500 a oba môžu držať polootvorenú bezpečnostnú asociáciu po tom, čo je pokus o pripojenie zrušený pri výzve na heslo alebo prerušený zmenou siete.

Keď sa to stane, ďalší pokus nezačína čisto. Snaží sa vyjednávať, kým stará asociácia stále zaberá stav partnera, a výmena sa zasekne namiesto toho, aby zlyhala s jasnou chybou. Používateľ vidí otáčajúci sa indikátor a potom vypršanie.

Nájdite vlastníka, skôr než čokoľvek zabijete, pretože odpoveď určuje, ktorú službu reštartujete a ktorý log budete čítať ďalej.

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

Čítajte výstup ako dve skutočnosti: ktorý proces drží port a či je prítomný viac ako jeden. Dvaja démoni IKE súťažiaci o rovnaký soket vysvetľujú veľa občasného správania, ktoré vyzerá ako nestabilný server.

Reštartujte úlohu, nie proces

Na starších systémoch stačí proces zabiť a nechať ďalšie pripojenie, aby ho znova spustilo. V súčasných vydaniach démona spravuje launchd a samotný signál procesu môže úlohu nechať v stave, keď ani nebeží, ani nie je naplánovaná na spustenie. Namiesto toho úlohu zastavte a spustite.

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

Ak launchd nemá záznam o úlohe, zabitie procesu podľa mena aj tak vynúti nové vyjednávanie pri ďalšom pokuse. Test je v oboch prípadoch rovnaký: žiadny proces by nemal držať port, keď sa znova pokúsite pripojiť. Potvrďte to rovnakým príkazom lsof namiesto predpokladu, že reštart zabral.

Potom sa raz pripojte a prečítajte klientsky log od začiatku. Vyjednávanie, ktoré postúpi za fázu 1 a potom hlási chybu prenosu, opakuje miestny problém so soketom; vyjednávanie odmietnuté partnerom je úplne iný lístok.

Keď odmieta server

Nie každé druhé pripojenie zlyhá lokálne. Server môže po odpojení odmietnuť nové prihlásenie na pevne dané okno a časový limit klienta vyzerá rovnako ako zaseknutý démon. Rozlišovač je lacný: ak reštart démona nepomôže, ale iný účet sa pripojí okamžite, okno je na strane servera a Mac nikdy nebol problém.

Politika rozdeleného tunela vytvára rovnaký tvar z opačnej strany. Server, ktorý vyžaduje všetku premávku v tuneli, zahodí klienta nakonfigurovaného na rozdelený tunel počas vyjednávania a klient hlási vypršanie namiesto odmietnutia politiky. Zmena profilu, aby všetko išlo tunelom, ho môže pripojiť, ale to je rozhodnutie o politike, ktoré sa robí s vlastníkom siete, nie oprava, ktorú treba potichu nasadiť.

Prečítajte log partnera, skôr než klienta znova zmeníte. Odmietnutie, nesúlad politiky a tiché zahodenie sú tri rôzne príčiny, ktoré na obrazovke Macu vyzerajú všetky ako „pripájanie“.

Starší klienti a 64-bitové jadro

Starý klient Cisco IPSec načítava rozšírenie jadra postavené pre 32-bitové systémy a PowerPC. Na Macu zavedenom do 64-bitového jadra sa toto rozšírenie nemôže načítať a klient skoro zlyhá s chybou 51, pretože sa vôbec nedostane k podsystému VPN. Žiadne reštartovanie démona neopraví rozšírenie jadra so zlou architektúrou.

Opätovné načítanie rozšírenia môže chvíľu fungovať a potom pri ďalšom boote znova zlyhať. Trvalé riešenia sú spustiť staršie jadro tam, kde je ešte podporované, alebo prejsť na vstavaného klienta, ktorý je súčasťou systému. Skontrolujte architektúru, skôr než strávite večer pri klientovi tretej strany, ktorý sa nedá načítať.

• Reprodukujte raz, potom skontrolujte, ktorý démon vlastní UDP 500, skôr než sa dotknete profilu.
• Prečítajte prvé zlyhanie po fáze 1: chyba prenosu ukazuje na miestny soket.
• Reštartujte úlohu launchd, nielen proces, a potvrďte, že port je voľný.
• Skúste druhý účet, aby ste oddelili okno opätovného overenia na strane servera od poruchy klienta.
• Zaznamenajte architektúru jadra, skôr než obviníte klienta.

VPN, ktoré funguje presne raz, je problém stavu, kým sa nepreukáže opak. Vyčistenie démona je rýchlejšie ako reštart a zachová dôkazy z logu, ktoré by reštart zahodil.