Shkëmbimi IKEv2 funksionon, pastaj vërtetimi dështon: ku të kërkosh

Një klient që merr një përgjigje IKEv2 ka provuar që porta është e arritshme, që të dyja palët mund të negociojnë një propozim dhe që shkëmbimi fillestar i çelësave përfundoi. Nuk ka provuar se dikush është vërtetuar. Shkëmbimi i ardhshëm mbart identitete, certifikata ose EAP, dhe aty lidhja zakonisht ndalon. Leximi i asaj se cili prej këtyre kontrollimeve dështoi është i gjithë diagnozi, dhe mesazhi i gabimit i vetëm rrallë e thotë.

Kontrolli 1: lexoni fazën, jo mesazhin

Një refuzim mund të vijë nga tre vende: klienti që refuzon identitetin e serverit, porta që refuzon provën e klientit dhe një shërbim i jashtëm vërtetimi që refuzon llogarinë.

Secili prodhon një rresht tjetër regjistri në një makinë tjetër, dhe secili ka një rregullim tjetër. Një refuzim i certifikatës së serverit në anën e klientit është problem besimi ose emërtimi tek klienti; një refuzim i certifikatës së klientit në anën e portës është problem besimi tek porta; një dështim EAP është problem llogarie ose backend-i. Mesazhi që shihni është zakonisht përmbledhja e klientit për një prej këtyre, prandaj regjistri i portës është po aq i rëndësishëm sa ai i klientit.

Kontrolli 2: cili identitet u kontrollua

Klienti mund të refuzojë certifikatën e serverit ose identitetin e pritur përpara se të ofrohet ndonjë kredencial përdoruesi, dhe një adresë serveri që funksionon nuk e zëvendëson atë kontroll. Identifikuesi që klienti pret duhet të përputhet me atë që paraqet porta, që është fakt konfigurimi dhe jo fakt rrjeti.

Në termat e strongSwan kjo është rightid te klienti dhe identiteti i vetë portës në anën tjetër, dhe mospërputhja dështon përpara se të diskutohet edhe EAP.

Porta, veçmas, mund të refuzojë certifikatën e klientit, provën e çelësit ose vërtetimin e llogarisë, dhe këto të treja nuk janë të këmbyeshme. Rivendosja e fjalëkalimit të një përdoruesi nuk rinovon një certifikatë pajisjeje, dhe riinstalimi i një certifikate pajisjeje nuk rregullon një identitet të gabuar serveri. Për dështimet e certifikatave, kontrolloni fillimisht orën, pastaj zinxhirin e besimit, pastaj identifikuesin e pritur; një klient, ora e të cilit është disa minuta larg, dështon në një kontroll vlefshmërie që duket si dështim besimi. swanctl --list-certs në të dy skajet tregon se çfarë mban në të vërtetë secila palë.

Kontrolli 3: nëse EAP është në lojë

Klienti dhe serveri duhet të bien dakord për një metodë të mbështetur, dhe backend-i duhet të pranojë identitetin e dhënë.

Një emër përdoruesi mund të ketë nevojë për një prapashtesë domeni ose një format të caktuar llogarie që kërkon vendosja, dhe formati është i dokumentuar dhe jo i hamendësueshëm. Dhënia e fushave të dokumentuara të operatorit është më e shpejtë se provimi i varianteve, dhe shmang një problem të dytë: përpjekjet e përsëritura mund të shkaktojnë bllokim llogarie, që pastaj fsheh fazën origjinale pas një dështimi të ri. Nëse metoda është EAP-MSCHAPv2 kundër një drejtorie, dështimi mund t'i përkasë drejtorisë dhe jo VPN-së.

Mos i provoni problemet e identitetit duke çaktivizuar kontrollet e identitetit. Kjo e kthen një dështim të diagnozueshëm në të padiagnozueshëm dhe e lë lidhjen më të dobët se më parë.

Kontrolli 4: çfarë ndodh pas një hyrjeje të suksesshme

Pasi IKE_AUTH përfundon, negociimi i CHILD_SA vendos cilët përzgjedhës trafiku instalohen, dhe pikërisht aty një lidhje mund të ketë sukses dhe gjithsesi të mos kalojë asgjë.

Një hyrje që sapo ka filluar të funksionojë shpesh zbulon një problem përzgjedhësi ose rruge që më parë ishte i fshehur pas dështimit të vërtetimit. Nëse tuneli ngrihet dhe një aplikacion ende nuk arrin destinacionin, shikoni përzgjedhësit dhe rrugët e negociuara dhe jo përsëri identitetin. Ndryshimi i cilësimeve të identitetit në atë moment synon fazën e gabuar dhe zakonisht prish një hyrje që funksionon. Konfirmoni me swanctl --list-sas, që tregon fëmijët dhe përzgjedhësit e tyre veçmas nga IKE SA.

Kontrolli 5: çfarë t'i jepet mbështetjes

Një kronologji e pastruar dhe refuzimi i saktë vlejnë më shumë se një eksport i plotë diagnostik, dhe eksporti mund të përmbajë çelësa privatë ose kredenciale që nuk duhet t'i ndani.

Shënoni kohën me zonën kohore, versionet e klientit dhe të portës, metodën, vargun e identitetit të ofruar dhe jo fjalëkalimin, dhe fazën e saktë që e refuzoi. dokumentacioni i konfigurimit IKEv2 të strongSwan përshkruan cilësimet e identitetit dhe EAP që i përcaktojnë këto rezultate, dhe është referenca që duhet lexuar përpara se të ndryshohet një fushë. Pastaj ndryshoni një gjë dhe ritestoni një lidhje të re, sepse një sesion i ruajtur në cache do t'ju tregojë për konfigurimin e vjetër.