IKEv2 nuk është një dorështrëngim i vetëm: IKE SA, vërtetim, pastaj CHILD SA

Mund të mendoni se një lidhje IKEv2 është një shkëmbim i vetëm që përfundon me trafikun tuaj të kriptuar. Janë të paktën dy, dhe i pari nuk vërteton askënd. Palët fillojnë me mesazhe kontrolli, bien dakord për parametrat kriptografikë, vërtetojnë identitetin dhe vetëm pastaj negociojnë gjendjen që transporton paketat e aplikacionit. Ky rend shpjegon mospërputhjen për të cilën njerëzit raportojnë vazhdimisht: porta përgjigjet, klienti thotë i lidhur, dhe aplikacioni privat përsëri skadon. Këtu është çfarë bën në të vërtetë çdo fazë dhe çfarë duhet të jetë e vërtetë pas saj.

Miti: nëse porta përgjigjet, ju jeni të lidhur

Një përgjigje ndaj mesazhit të parë provon se pika fundore është e arritshme dhe e gatshme të flasë. Nuk provon se një llogari u pranua, se një zinxhir certifikatash u vërtetua, ose se u instalua ndonjë politikë e dhënave.

Këto dështime ndodhin më vonë dhe japin simptoma të ndryshme. Refuzimi i certifikatës ose një dështim EAP vjen pasi shkëmbimi i parë ka pasur sukses, prandaj një ping drejt UDP 500 dhe një ikonë e gjelbër në klient thonë kaq pak.

IKE_SA_INIT: bini dakord për parametra, jo për identitet

Shkëmbimi i parë transporton propozimet për asociacionin e sigurisë IKE: algoritme kriptimi dhe integriteti, një funksion pseudorandom dhe një grup Diffie-Hellman. Palët shkëmbejnë gjithashtu nonce, dhe secila anë nxjerr materialin e çelësit për IKE SA nga sekreti i përbashkët që krijojnë këto vlera. Asgjë në këtë shkëmbim nuk përcakton kush është pala tjetër. Përcakton vetëm se të dyja anët mund të llogarisin të njëjtët çelësa dhe se bien dakord për një propozim. Një përgjigjës që nuk i pëlqen asnjë propozim e refuzon shkëmbimin këtu, prandaj një mospërputhje versioni ose algoritmi duket si server i rënë.

IKE SA e krijuar në këtë pikë mbron të gjitha shkëmbimet e menaxhimit që vijnë më pas. Ky është puna e saj, dhe është një punë tjetër nga mbrojtja e paketave tuaja.

IKE_AUTH: provoni identitetin, pastaj ndërtoni CHILD SA e parë

Shkëmbimi i dytë transporton identitetin. Me certifikata, secila palë nënshkruan me çelësin e vet privat dhe paraqet një zinxhir që tjetra duhet ta vërtetojë; me EAP, përgjigjësi sfidon iniciuesin përmes metodës së zgjedhur. Këtu më në fund dalin një emër i gabuar serveri, një certifikatë e skaduar ose një fjalëkalim i refuzuar.

Zakonisht IKE_AUTH negocion edhe CHILD SA e parë, kështu që mbrojtja e të dhënave bihet dakord në të njëjtin udhëtim. Iniciuesi propozon përzgjedhës të trafikut, përgjigjësi i ngushton ose i refuzon, dhe çelësat e rrugës së të dhënave nxirren nga IKE SA. Kjo do të thotë se një shkëmbim i vetëm mund të dështojë në dy vende shumë të ndryshme: identiteti ose politika. Lexoni ngarkesën e njoftimit ose gabimin, jo dështimin e përgjithshëm të dorështrëngimit, sepse ilaçi për njërin është një certifikatë dhe për tjetrin një mospërputhje nënrrjeti.

Dy SA, dy punë

Ndarja e tyre shpjegon dy sjellje që duken si gabime. Një tunel mund të duket i vendosur ndërsa rinovimi i çelësave dështon në sfond, dhe një CHILD SA mund të zëvendësohet pa e humbur klienti lidhjen.

Në strongSwan referenca e konfigurimit IKEv2 dhe swanctl --list-sas tregojnë të dy nivelet, dhe ip xfrm state bashkë me ip xfrm policy tregojnë çfarë instaloi në të vërtetë kerneli. Krahasimi i këtyre dy pamjeve është mënyra më e shpejtë për të parë nëse negocimi përfundoi apo vetëm u duk i përfunduar. Nëse daemoni liston një CHILD SA për të cilën kerneli nuk ka gjendje, instalimi dështoi në heshtje. Nëse kerneli mban gjendje që daemoni nuk e njeh, po shikoni mbetje të një përpjekjeje të mëparshme.

Çfarë duhet të mbetet e vërtetë pasi tuneli është lart

Përzgjedhësit e trafikut përcaktojnë cilat adresa mbulohen. Nëse klienti propozon një nënrrjet dhe serveri pret një tjetër, CHILD SA instalohet por nuk transporton asgjë të dobishme, dhe gabimi shfaqet si problem rrugëtimi dhe jo negocimi. Pastaj stivi lokal duhet të bashkëpunojë: përcjellja e aktivizuar aty ku hosti rrugëton, rrugët drejt tunelit, rregullat e firewall-it që lejojnë paketat e dekapsuluara dhe një zgjidhës i brendshëm nëse përfshihen emra privatë. Secili prej tyre dështon veçmas dhe asnjë nuk rregullohet duke rinisur daemonin IKE.

Mbajeni logun të dukshëm gjatë diagnostikimit: shkëmbimi fillestar, pastaj vërtetimi i identitetit, pastaj vërtetimi i përdoruesit ku zbatohet, pastaj instalimi i CHILD dhe në fund trafiku i aplikacionit. Faza që ndalon është faza për t'u rregulluar, dhe një dështim rrugëtimi i mëvonshëm nuk është kurrë arsye për të lehtësuar kontrollet e identitetit që kaluan tashmë.