Mac-eko VPNa behin konektatu eta gero iraungitzen da: garbitu IKE deabrua

Berrabiarazi ondorengo lehen konexioa funtzionatzen du. Hurrengo saiakera bakoitza konektatzeko fasean zintzilik geratzen da eta azkenean iraungi egiten da, eta sendabide fidagarri bakarra beste berrabiarazte bat da. Eredu hori ez da profilaren arazoa eta ez da kredentzialen arazoa. Atzeko planoan zerbait oraindik aurreko saikeraren egoera mantentzen ari da, eta hurrengo saiakera harekin talka egiten du.

macOS-en, zerbait hori IKE deabrua izan ohi da.

Eredua: behin konektatu, gero iraungi

Abio bakoitzeko behin zehazki funtzionatzen duen konexio batek deskonexioa gainditzen duen baina berrabiaraztea gainditzen ez duen egoerari seinalatzen dio. Profilak biak gainditzen ditu, beraz profila ez da aldagaia. Kredentzialek ere biak gainditzen dituzte, zerbitzariak kontua blokeatzen ez badu. Berrabiaraztean aldatzen dena martxan dagoen deabruen multzoa eta haiek mantentzen dituzten socketak dira.

Horrek ikerketa estutzen du log bat ere ireki aurretik. Galdera IKE ataka nor duen eta zer uste duen egiten ari dela bihurtzen da.

Bi deabru, ataka bat

Sistemak exekutatzen du racoon konexio batek IKE 1 bertsioan hitz egiten duenean. Bertsio berriek ere ekartzen dute iked IKEv2 eta IPsec pila berriagoarentzat. Biek UDP 500 eta UDP 4500 lotu ditzakete, eta biek segurtasun elkarte erdi-irekia mantendu dezakete konexio saiakera bat pasahitzaren galdetegian bertan behera utzi edo sare aldaketak eten ondoren.

Hori gertatzen denean, hurrengo saiakera ez da garbi hasten. Elkarte zaharra oraindik parearen egoera hartzen ari den bitartean negoziatzen saiatzen da, eta trukea gelditu egiten da, errore argi batekin huts egin beharrean. Erabiltzaileak biraketa-adierazle bat ikusten du, gero iraungitzea.

Aurkitu jabea ezer hil aurretik, erantzunak zehazten baitu zein zerbitzu berrabiarazten duzun eta zein log irakurtzen duzun hurrena.

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

Irakurri irteera bi egoera gisa: zein prozesuk mantentzen duen ataka eta bat baino gehiago dagoen. Socket beraren alde lehiatzen diren bi IKE deabruk denbora irregularreko jokabide asko azaltzen dute, zerbitzari ezegonkor baten itxura duena.

Berrabiarazi lana, ez prozesua

Sistema zaharretan nahikoa da prozesua hiltzea eta hurrengo konexioari berriro abiarazten uztea. Egungo bertsioetan deabrua launchd-ek kudeatzen du, eta prozesuari soilik seinalea bidaltzeak lana ez martxan eta ez abiatzeko programatuta ez dagoen egoeran utz dezake. Gelditu eta abiarazi lana, horren ordez.

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

Launchd-ek lanaren erregistrorik ez badu, prozesua izenez hiltzeak hurrengo saiakeran negoziazio berria behartzen du oraindik. Testa bera da bi kasuetan: inongo prozesuk ez luke ataka mantendu behar berriro konektatzen saiatzen zarenean. Berretsi ezazu komando berarekin lsof berrabiarazteak funtzionatu zuela suposatu beharrean.

Ondoren konektatu behin eta irakurri bezeroaren loga hasieratik. 1go fasettik aurrera egiten duen eta gero transmisio-errore baten berri ematen duen negoziazioak tokiko socketaren arazoa errepikatzen du; pareak baztertutako negoziazioa erabat bestelako txartela da.

Zerbitzaria da ukatzen duena

Ez da bigarren konexio guztiak bertan huts egiten. Zerbitzari batek deskonexio baten ondoren saio-hasiera berria uka dezake leiho finko batean, eta bezeroaren iraungitzeak deabru blokeatu baten berdin-berdin ikusten du. Bereizlea merkea da: deabrua berrabiarazteak laguntzen ez badu baina beste kontu bat berehala konektatzen bada, leihoa zerbitzariaren aldean dago eta Mac ez zen inoiz arazoa.

Tunel zatituaren politikak forma bera sortzen du beste norabidetik. Tunel guztiko trafiko guztia eskatzen duen zerbitzari batek tunel zatirako konfiguratuta dagoen bezero bat baztertuko du negoziazioan, eta bezeroak iraungitzea jakinarazten du politika-bazterketa bat eman beharrean. Profila guztia tunelen bidez bidaltzeko aldatzeak konekta dezake, baina sarearen jabearekin hartu beharreko politika-erabakia da, ez isilpean aplikatu beharreko konponketa.

Irakurri parearen loga bezeroa berriro aldatu aurretik. Bazterketa bat, politika-desadostasun bat eta isiluneko baztertze bat hiru kausa desberdin dira, Mac-en pantailan denek “konektatzen” diruditenak.

Bezero zaharragoak eta 64 biteko nukleoa

Cisco IPSec bezero zaharrak 32 biteko eta PowerPC sistementzako eraikitako nukleo-luzapen bat kargatzen du. 64 biteko nukleoan abiatutako Mac batean, luzapen hori ezin da kargatu, eta bezeroak goiz huts egiten du 51 errorearekin, VPN azpisistema ere ez baitu lortzen. Deabrua berrabiarazteak ez du arkitektura okerreko nukleo-luzapenik konpontzen.

Luzapena berriro kargatzeak denbora batez funtziona dezake eta gero berriro huts egin hurrengo abioan. Erantzun iraunkorrak nukleo zaharragoa oraindik onartzen den lekuan exekutatzea edo sistemarekin datorren barneko bezeroa erabiltzea dira. Egiaztatu arkitektura gau oso bat kargatu ezin den hirugarrenen bezero batekin eman aurretik.

• Erreproduzitu behin eta gero egiaztatu zein deabruk duen UDP 500 profila ukitu aurretik.
• Irakurri 1go fasettik ondorengo lehen hutsegitea: transmisio-errore batek tokiko socketari seinalatzen dio.
• Berrabiarazi launchd lana, ez bakarrik prozesua, eta berretsi ataka librea dela.
• Probatu bigarren kontu bat zerbitzariaren aldeko berrautaketa-leihoa bezeroaren hutsegite batetik bereizteko.
• Idatzi nukleoaren arkitektura bezeroari errua eman aurretik.

Behin zehazki funtzionatzen duen VPN bat egoera-arazoa da kontrakoa frogatu arte. Deabrua garbitzea berrabiaraztea baino azkarragoa da, eta berrabiarazteak botako lituzkeen log frogak gordetzen ditu.