IKEv2 adresa serveru vs identita: co klient skutečně kontroluje

Brána, která změní adresu, může dál fungovat, zatímco se stejná brána za novým certifikátem zastaví, a stane se to i obráceně. Adresa říká klientovi, kam má odesílat pakety; ověřená identita sděluje klientovi, zda je partner, kterému odpovídá, ten, kterému by měl důvěřovat. IKEv2 je ponechává jako dvě samostatná pole, což je užitečné, jakmile je přestanete považovat za jeden řetězec. Jsou také konfigurovány na různých místech, takže jedno může být správné, zatímco druhé je špatné.

Zkontrolujte je v tomto pořadí a zastavte se u první neshody, protože pozdější kontroly předpokládají, že dřívější prošly.

Za prvé, která hodnota je adresa

Adresa připojení je cokoliv, co klient vytočí: IP, DNS název, který se převede na jeden, nebo frontend s vyváženým zatížením. To jsou dopravní informace a nic víc. Identita je součástí užitečného zatížení IKEv2 ID a je pak porovnána s certifikátem partnera. Jméno DNS v poli adresy se nestane očekávanou identitou a nezpracovaná IP se nestane identitou jen proto, že je k ní připojen soket.

Z hlediska strongSwan je adresa right nebo left a očekávaná identita je rightid nebo leftid, a to popisuje konfigurační dokumentace IKEv2. Pokud jste někdy upravovali pouze adresu, nakonfigurovali jste polovinu páru.

Za druhé, co může certifikát prokázat

Identita má typ a certifikát musí nést odpovídající název. Identita DNS je splněna záznamem dNSName v alternativní příponě názvu subjektu; Identita IP vyžaduje položku iPAddress. Certifikát vydaný pro vpn.example.com nedokazuje nic o doslovné adrese 203.0.113.10 a certifikát vydaný pro tuto adresu neprokazuje nic o jméně. Opětovné vydání pro jiné jméno proto není náhradou typu drop-in, i když je znovu použit stejný klíč a CA.

Moderní klienti ignorují běžný název, pokud existuje alternativní název subjektu, a mnozí ho ignorují úplně. Pokud seznam SAN neobsahuje hodnotu, kterou klient kontroluje, handshake selže poté, co byl certifikát již přijat jako důvěryhodný, což je důvod, proč se protokol čte jako chyba identity, nikoli jako chyba důvěryhodnosti.

Za třetí, jak každý klient uvádí očekávání

Windows převezme název serveru nebo adresu, kterou jste zadali, a vyžaduje, aby se certifikát shodoval, takže zadání IP vytvoří očekávání IP. Klient Android IKEv2 se chová stejně a oba odmítají platný, veřejně důvěryhodný certifikát, který pojmenovává jiného hostitele. Profil může začít selhávat pouze proto, že někdo během migrace nahradil název hostitele jeho adresou. Než se podíváte na to, co certifikát obsahuje, podívejte se na to, co klient požadoval.

Na strongSwan je očekávání explicitní: nastavte rightid na identitu, kterou server skutečně prezentuje, která se může lišit od pravé. Nastavením na %any akceptujete vše, co partner nabízí, a odstraní přesně ten šek, který se snažíte zachovat.

Za čtvrté, samostatné přihlášení uživatele od identity peer

Ověření EAP a identita serveru odpovídají na různé otázky. Identita EAP, jako je [email protected] říká, kdo je uživatel poté, co se klient rozhodl, že server je ten správný. Otočením tohoto hesla nelze vyřešit nesoulad identity peer, protože připojení nikdy nedosáhne fáze přihlášení uživatele.

Dezinfikovaná zpráva by měla obsahovat obě: identitu, kterou klient očekával, identitu prezentovanou serverem a položky SAN certifikátu.

Za páté, změňte jej prostřednictvím ověřeného kanálu

Když se brána legitimně přesune, aktualizujte nejprve adresu a ponechte identitu na pokoji, protože v takovém případě IKEv2 se dobře ovládá. Když se změní samotná identita, považujte to za důvěryhodnou událost a získejte novou hodnotu ze zdroje, kterému již důvěřujete, nikoli z koncového bodu, který aktuálně selhává. Zpráva doručená přes připojení, které se pokoušíte ověřit, není důkazem tohoto připojení.

Zaznamenejte si konečnou adresu, identitu a seznam SAN společně do poznámek k profilu. Další osoba, která se dotkne certifikátu, pak uvidí, který z těchto tří se může pohybovat.