Mac-VPN ferbynt ien kear en docht dan in time-out: romje de IKE-daemon op

De earste ferbining nei in opnij opstarten wurket. Elk besykjen dêrnei hinget yn ’e ferbiningsfaze en rint úteinlik op in time-out, en it iennige betroubere middel is noch in opstart. Dat patroan is gjin profylprobleem en it is gjin probleem mei oanmeldgegevens. Iets op ’e eftergrûn hâldt noch de tastân fan ’e foarige poging fêst, en de folgjende poging botst dêrmei.

Op macOS is dat iets meastentiids de IKE-daemon.

It patroan: ien kear ferbine, dan in time-out

In ferbining dy’t krekt ien kear per opstart wurket, wiist op in tastân dy’t in ôfbrekking oerlibbet mar gjin opstart. Profilen oerlibje beide, dus it profyl is net de fariabele. Oanmeldgegevens oerlibje ek beide, útsein as de server it akkount ôfslút. Wat by in opstart feroaret, is de set fan draaiende daemons en de sockets dy’t se hâlde.

Dat beheint it ûndersyk foardat jo ien log iepenje. De fraach wurdt hokker proses de IKE-poarte hat en wat it tinkt dat it docht.

Twa daemons, ien poarte

It systeem draait racoon as in ferbining IKE-ferzje 1 praat. Hjoeddeiske ferzjes bringe ek iked foar IKEv2 en de nijere IPsec-stapel. Beide kinne UDP 500 en UDP 4500 besette, en beide kinne in healiepen befeiligingsassosjaasje hâlde nei’t in ferbiningspoging by de wachtwurdprompt annulearre of troch in netwurkferoaring ûnderbrutsen is.

As dat bart, begjint de folgjende poging net skjin. It besiket te ûnderhanneljen wylst de âlde assosjaasje noch de tastân fan ’e partner beset, en de útwikseling stûket yn stee fan te mislearjen mei in dúdlike flater. De brûker sjocht in draaiend symboal, dan in time-out.

Fyn de eigner foardat jo eat deadzje, want it antwurd bepaalt hokker tsjinst jo opnij starte en hokker log jo dêrnei lêze.

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

Lês de útfier as twa feiten: hokker proses de poarte hâldt, en oft der mear as ien oanwêzich is. Twa IKE-daemons dy’t om deselde socket stride ferklearje in protte ûnregelmjittich gedrach dat op in ûnstabile server liket.

Start de taak opnij, net it proses

Op âldere systemen is it genôch om it proses te deadzjen en de folgjende ferbining it wer starte te litten. Op hjoeddeiske ferzjes wurdt de daemon beheard troch launchd, en allinnich it proses in sinjaal jaan kin de taak yn in tastân litte wêryn’t er noch draait noch pland is om te starten. Stop en start de taak ynstee.

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

As launchd gjin registraasje fan ’e taak hat, twingt it deadzjen fan it proses by namme dochs in nije ûnderhanneling by de folgjende poging. De test is itselde yn beide gefallen: gjin proses heart de poarte te hâlden as jo wer ferbine. Befêstigje dat mei deselde opdracht lsof ynstee fan oan te nimmen dat it opnij starten wurke hat.

Ferbyn dan ien kear en lês it kliïntlog fan it begjin ôf. In ûnderhanneling dy’t foarby faze 1 giet en dan in oerdrachtsflater meldt, werhellet it lokale socketprobleem; in ûnderhanneling dy’t de partner wegeret is in hiel oar ticket.

As de server dejinge is dy’t wegeret

Net elke twadde ferbining mislearret lokaal. In server kin in nije oanmelding foar in fêst finster nei in ôfbrekking wegerje, en de time-out fan ’e kliïnt liket identyk op in fêsthingjende daemon. It ûnderskied is goedkeap: as it opnij starten fan ’e daemon net helpt mar in oar akkount ferbynt fuort, sit it finster oan ’e serverkant en wie de Mac nea it probleem.

Belied foar splitstunnel jout deselde foarm fan ’e oare kant. In server dy’t al it ferkear yn ’e tunnel freget, smyt in kliïnt dy’t foar splitstunnel konfigurearre is by de ûnderhanneling fuort, en de kliïnt meldt in time-out yn stee fan in beliedswegering. It profyl feroarje om alles troch de tunnel te stjoeren kin it ferbine litte, mar dat is in beliedsbeslút dat mei de netwurkeigner nommen wurde moat, gjin reparaasje om stil tapast te wurden.

Lês it log fan ’e partner foardat jo de kliïnt wer feroarje. In wegering, in beliedsôfwiking en in stil falle litte binne trije ferskillende oarsaken dy’t op it skerm fan ’e Mac allegear as “ferbynt” lykje.

Aldere kliïnten en de 64-bits kernel

De âlde Cisco IPSec-kliïnt laadt in kernelútwreiding dy’t boud is foar 32-bits en PowerPC-systemen. Op in Mac dy’t yn ’e 64-bits kernel opstart is, kin dy útwreiding net laadzje, en de kliïnt mislearret betiid mei flater 51 om’t er de VPN-subsysteem hielendal net berikke kin. Gjin inkelde hoemannichte daemons opnij starten makket in kernelútwreiding mei de ferkearde arsjitektuer goed.

De útwreiding opnij laadzje kin in skoft wurkje en dan by de folgjende opstart wer mislearje. De duorsume antwurden binne de âldere kernel draaie wêr’t dat noch stipe wurdt, of oerstappe nei de ynboude kliïnt dy’t mei it systeem komt. Kontrolearje de arsjitektuer foardat jo in jûn besteegje oan in tredde-partij kliïnt dy’t net laadzje kin.

• Reprodusearje ien kear, kontrolearje dan hokker daemon UDP 500 hat foardat jo it profyl oanreitsje.
• Lês de earste mislearring nei faze 1: in oerdrachtsflater wiist nei de lokale socket.
• Start de launchd-taak opnij, net allinnich it proses, en befêstigje dat de poarte frij is.
• Probearje in twadde akkount om in serverkant-werôfliedingfinster fan in kliïntflater te skieden.
• Skriuw de kernelarsjitektuer op foardat jo de kliïnt de skuld jouwe.

In VPN dy’t krekt ien kear wurket, is in tastânprobleem oant it tsjinoerstelde bewiisd is. De daemon opromje is flugger as opnij opstarten, en it bewarret it logbewiis dat in opstart fuortgoaid hawwe soe.