VPN-ja e Mac-it lidhet një herë dhe më pas skadon koha: pastroni demonin IKE

Lidhja e parë pas një rinisjeje funksionon. Çdo përpjekje pas saj ngec në fazën e lidhjes dhe përfundimisht skadon koha, dhe ilaçi i vetëm i besueshëm është një rinisje tjetër. Ky model nuk është problem profili dhe nuk është problem kredencialesh. Diçka në sfond ende mban gjendjen nga përpjekja e mëparshme, dhe përpjekja tjetër përplaset me të.

Në macOS, ajo diçka është zakonisht demoni IKE.

Modeli: një lidhje, pastaj skadim kohe

Një lidhje që funksionon saktësisht një herë për nisje tregon një gjendje që i mbijeton një shkëputjeje, por jo një rinisjeje. Profilet i mbijetojnë të dyjave, pra profili nuk është variabli. Kredencialet gjithashtu i mbijetojnë të dyjave, përveç nëse serveri e bllokon llogarinë. Ajo që ndryshon në rinisje është grupi i demonëve që punojnë dhe socket-ët që mbajnë.

Kjo e ngushton hetimin përpara se të hapni edhe një log të vetëm. Pyetja bëhet cili proces zotëron portin IKE dhe çfarë mendon se po bën.

Dy demonë, një port

Sistemi ekzekuton racoon kur një lidhje flet IKE versionin 1. Publikimet aktuale sjellin gjithashtu iked për IKEv2 dhe stivën më të re IPsec. Të dyja mund të zënë UDP 500 dhe UDP 4500, dhe të dyja mund të mbajnë një asociacion sigurie gjysmë të hapur pasi një përpjekje lidhjeje anulohet te kërkesa e fjalëkalimit ose ndërpritet nga një ndryshim rrjeti.

Kur kjo ndodh, përpjekja tjetër nuk fillon pastër. Përpiqet të negociojë ndërsa asociacioni i vjetër ende zë gjendjen e palës, dhe shkëmbimi ngec në vend që të dështojë me një gabim të qartë. Përdoruesi sheh një tregues rrotullues, pastaj skadim kohe.

Gjeni pronarin përpara se të vrisni ndonjë gjë, sepse përgjigjja përcakton cilën shërbim rinisni dhe cilin log lexoni më pas.

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

Lexojeni daljen si dy fakte: cili proces mban portin dhe nëse ka më shumë se një. Dy demonë IKE që konkurrojnë për të njëjtin socket shpjegojnë shumë sjellje të ndërprerë që duket si server i paqëndrueshëm.

Rinisni punën, jo procesin

Në sistemet më të vjetra mjafton të vrisni procesin dhe të lini lidhjen tjetër ta nisë përsëri. Në publikimet aktuale demoni menaxhohet nga launchd, dhe dërgimi i një sinjali vetëm procesit mund ta lërë punën në një gjendje ku as nuk punon as nuk është planifikuar të nisë. Në vend të kësaj ndaloni dhe nisni punën.

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

Nëse launchd nuk ka regjistrim të punës, vrasja e procesit me emër përsëri imponon një negociatë të re në përpjekjen tjetër. Testi është i njëjtë në të dyja rastet: asnjë proces nuk duhet të mbajë portin kur përpiqeni të lidheni përsëri. Konfirmojeni atë me të njëjtin komandë lsof në vend që të supozoni se rinisja funksionoi.

Pastaj lidhuni një herë dhe lexoni log-un e klientit nga fillimi. Një negociatë që kalon fazën 1 dhe më pas raporton një dështim transmetimi po përsërit problemin lokal të socket-it; një negociatë e refuzuar nga pala është një biletë krejt tjetër.

Kur serveri është ai që refuzon

Nuk dështon çdo lidhje e dytë lokalisht. Serveri mund të refuzojë një hyrje të re për një dritare fikse pas një shkëputjeje, dhe skadimi i kohës te klienti duket identik me një demon të bllokuar. Dalluesi është i lirë: nëse rinisja e demonit nuk ndihmon por një llogari tjetër lidhet menjëherë, dritarja është në anën e serverit dhe Mac-i nuk ishte kurrë problemi.

Politika e tunelit të ndarë prodhon të njëjtën formë nga drejtimi tjetër. Një server që kërkon të gjithë trafikun në tunel do të hedhë poshtë një klient të konfiguruar për tunel të ndarë gjatë negociatës, dhe klienti raporton skadim kohe në vend të një refuzimi politike. Ndryshimi i profilit për të dërguar gjithçka përmes tunelit mund ta bëjë atë të lidhet, por ky është një vendim politike që merret me pronarin e rrjetit, jo një riparim që aplikohet në heshtje.

Lexoni log-un e palës përpara se të ndryshoni përsëri klientin. Një refuzim, një mospërputhje politike dhe një hedhje e heshtur janë tre shkaqe të ndryshme që në ekranin e Mac-it duken të gjitha si “po lidhet”.

Klientë më të vjetër dhe kerneli 64-bit

Klienti i vjetër Cisco IPSec ngarkon një zgjerim kerneli të ndërtuar për sisteme 32-bit dhe PowerPC. Në një Mac të nisur në kernelin 64-bit, ai zgjerim nuk mund të ngarkohet, dhe klienti dështon herët me gabimin 51 sepse nuk arrin fare në nënsistemin e VPN-së. Asnjë sasi rinisjesh të demonit nuk riparon një zgjerim kerneli me arkitekturë të gabuar.

Ringarkimi i zgjerimit mund të punojë për një kohë dhe më pas të dështojë përsëri në nisjen tjetër. Përgjigjet e qëndrueshme janë të ekzekutoni kernelin më të vjetër aty ku ende mbështetet, ose të kaloni te klienti i integruar që vjen me sistemin. Kontrolloni arkitekturën përpara se të kaloni një mbrëmje me një klient të palës së tretë që nuk mund të ngarkohet.

• Riprodhoni një herë, pastaj kontrolloni cili demon zotëron UDP 500 përpara se të prekni profilin.
• Lexoni dështimin e parë pas fazës 1: një gabim transmetimi tregon socket-in lokal.
• Rinisni punën e launchd, jo vetëm procesin, dhe konfirmoni se porti është i lirë.
• Provoni një llogari të dytë për të ndarë një dritare riautentikimi në anën e serverit nga një defekt i klientit.
• Shënoni arkitekturën e kernelit përpara se të fajësoni klientin.

Një VPN që funksionon saktësisht një herë është problem gjendjeje derisa të provohet e kundërta. Pastrimi i demonit është më i shpejtë se një rinisje, dhe ruan provat e log-ut që një rinisje do t'i hidhte.