Výměna IKEv2 funguje, pak ověřování selže: kde

Klient, který obdrží odpověď IKEv2, prokázal, že brána je dostupná, že obě strany se mohou dohodnout na návrhu a že počáteční výměna klíčů byla dokončena. Neprokázal však, že je někdo ověřen. Následující výměna nese identity, certifikáty nebo EAP, a právě tam se spojení obvykle zastaví. Přečíst, která z těchto kontrol selhala, je celá diagnóza, a chybová zpráva to sama říká jen zřídka.

Kontrola 1: čtěte fázi, ne zprávu

Odmítnutí může přijít ze tří míst: klient odmítne identitu serveru, brána odmítne klientův důkaz a externí ověřovací služba odmítne účet.

Každé vytváří jiný řádek protokolu na jiném stroji a každé má jinou opravu. Odmítnutí certifikátu serveru na straně klienta je problém důvěry nebo názvu na klientovi; odmítnutí certifikátu klienta na straně brány je problém důvěry na bráně; selhání EAP je problém účtu nebo backendu. Zpráva, kterou vidíte, je obvykle shrnutím klienta o jedné z těchto věcí, a proto je protokol brány stejně důležitý jako ten klientský.

Kontrola 2: která identita byla ověřena

Klient může odmítnout certifikát serveru nebo očekávanou identitu dříve, než se nabídne jakýkoli uživatelský údaj, a funkční adresa serveru tuto kontrolu nenahrazuje. Identifikátor, který klient očekává, se musí shodovat s tím, co brána předkládá, což je věc konfigurace, nikoli sítě.

V terminologii strongSwanu je to rightid na klientovi a na druhé straně vlastní identita brány, a neshoda selže dřív, než se vůbec mluví o EAP.

Brána zvlášť může odmítnout certifikát klienta, důkaz jeho klíče nebo ověření účtu, a ty tři nejsou zaměnitelné. Obnovení uživatelského hesla neobnoví certifikát zařízení a přeinstalování certifikátu zařízení neopraví špatnou identitu serveru. U selhání certifikátů zkontrolujte nejdřív hodiny, pak řetězec důvěry, pak očekávaný identifikátor; klient, jehož hodiny jdou o pár minut vedle, selže v kontrole platnosti, která vypadá jako selhání důvěry. swanctl --list-certs na obou koncích ukazuje, co každá strana skutečně má.

Kontrola 3: pokud hraje roli EAP

Klient a server se musí shodnout na podporované metodě a backend musí přijmout dodanou identitu.

Uživatelské jméno může potřebovat příponu domény nebo konkrétní formát účtu, který nasazení vyžaduje, a formát je dokumentovaný, ne uhádnutelný. Zadání polí dokumentovaných operátorem je rychlejší než zkoušení variant a vyhýbá se druhému problému: opakované pokusy mohou spustit uzamčení účtu, které pak skryje původní fázi za novým selháním. Pokud je metodou EAP-MSCHAPv2 proti adresáři, selhání může patřit adresáři, a ne VPN.

Netestujte problémy s identitou vypnutím kontrol identity. Tím se diagnostikovatelné selhání změní v nediagnostikovatelné a spojení zůstane slabší než dřív.

Kontrola 4: co se děje po úspěšném přihlášení

Jakmile IKE_AUTH skončí, vyjednávání CHILD_SA rozhodne, které selektory provozu se nainstalují, a právě tam může spojení uspět a přesto nic nepřenášet.

Nově fungující přihlášení často odhalí problém se selektorem nebo trasou, který byl dřív skrytý za selháním ověřování. Pokud tunel naskočí a aplikace se stále nedostane na své cílové místo, dívejte se na vyjednané selektory a trasy, ne znovu na identitu. Změna nastavení identity v tu chvíli míří na špatnou fázi a obvykle rozbije fungující přihlášení. Potvrďte to pomocí swanctl --list-sas, který ukazuje potomky a jejich selektory odděleně od IKE SA.

Kontrola 5: co předat podpoře

Vyčištěná časová osa a přesné odmítnutí mají větší cenu než úplný diagnostický export a export může obsahovat soukromé klíče nebo přihlašovací údaje, které byste neměli sdílet.

Zapište čas s časovým pásmem, verze klienta a brány, metodu, řetězec identity, který byl nabídnut, nikoli heslo, a přesnou fázi, která ho odmítla. dokumentace ke konfiguraci strongSwan IKEv2 popisuje nastavení identity a EAP, která tato vyústění určují, a je to reference, kterou je třeba si přečíst před změnou pole. Pak změňte jednu věc a znovu otestujte nové spojení, protože mezipamětí uložená relace vám bude vyprávět o staré konfiguraci.