IKEv2 adresa servera vs identita: čo vlastne klient kontroluje

Brána, ktorá zmení adresu, môže ďalej fungovať, kým sa tá istá brána za novým certifikátom zastaví a stane sa to aj naopak. Adresa hovorí klientovi, kam má posielať pakety; overená identita hovorí klientovi, či partnerská odpoveď je tá, ktorej by mal dôverovať. IKEv2 ich uchováva ako dve samostatné polia, čo je užitočné, keď ich prestanete považovať za jeden reťazec. Sú tiež nakonfigurované na rôznych miestach, takže jedno môže byť správne, zatiaľ čo druhé je nesprávne.

Skontrolujte ich v tomto poradí a zastavte sa pri prvom nezhode, pretože neskoršie kontroly predpokladajú, že predchádzajúce prešli.

Po prvé, ktorá hodnota je adresa

Adresa pripojenia je čokoľvek, čo klient vytočí: IP, DNS názov, ktorý sa preloží na jeden, alebo frontend s vyváženou záťažou. To sú informácie o doprave a nič viac. Identita sa nachádza v užitočnom zaťažení IKEv2 ID a potom sa porovnáva s certifikátom partnera. Názov DNS v poli adresy sa nestane očakávanou identitou a nespracovaná IP sa nestane identitou len preto, že je k nej pripojený soket.

V termínoch strongSwan je adresa right alebo left a očakávaná identita je rightid alebo leftid, a to je to, čo popisuje dokumentácia konfigurácie IKEv2. Ak ste niekedy upravovali iba adresu, nakonfigurovali ste polovicu páru.

Po druhé, čo môže osvedčenie preukázať

Identita má typ a certifikát musí niesť zodpovedajúci názov. Identita DNS je splnená záznamom dNSName v alternatívnej prípone názvu subjektu; IP identita potrebuje položku iPAddress. Certifikát vydaný pre vpn.example.com nedokazuje nič o doslovnej adrese 203.0.113.10 a certifikát vydaný pre túto adresu nedokazuje nič o mene. Opätovné vydanie pre iné meno preto nie je náhradou typu drop-in, aj keď sa znova použije rovnaký kľúč a CA.

Moderní klienti ignorujú bežné meno, ak existuje alternatívne meno subjektu, a mnohí ho ignorujú úplne. Ak zoznam SAN neobsahuje hodnotu, ktorú klient kontroluje, nadviazanie spojenia zlyhá po tom, čo už bol certifikát akceptovaný ako dôveryhodný, čo je dôvod, prečo sa protokol číta ako chyba identity a nie ako chyba dôveryhodnosti.

Po tretie, ako každý klient uvádza očakávania

Windows prevezme názov servera alebo adresu, ktorú ste zadali, a vyžaduje, aby sa certifikát zhodoval, takže zadanie adresy IP vytvára očakávanie adresy IP. Klient IKEv2 Android sa správa rovnako a obaja odmietajú platný, verejne dôveryhodný certifikát, ktorý pomenúva iného hostiteľa. Profil môže začať zlyhávať len preto, že niekto počas migrácie nahradil názov hostiteľa jeho adresou. Skôr ako sa pozriete na to, čo certifikát obsahuje, pozrite sa, čo klient požadoval.

Na strongSwan je očakávanie explicitné: nastavte rightid na identitu, ktorú server skutočne prezentuje, ktorá sa môže líšiť od pravej. Nastavenie na %any akceptuje čokoľvek, čo partner ponúka, a odstráni presne ten šek, ktorý sa snažíte ponechať.

Po štvrté, oddeľte prihlásenie používateľa od identity partnera

Autentifikácia EAP a identita servera odpovedajú na rôzne otázky. Identita EAP, ako napríklad [email protected] hovorí, kto je používateľ, keď sa klient rozhodol, že server je ten správny. Otočenie tohto hesla nemôže vyriešiť nesúlad identity partnera, pretože pripojenie nikdy nedosiahne fázu prihlásenia používateľa.

Dezinfikovaná správa by mala uvádzať obe: identitu, ktorú klient očakával, identitu prezentovanú serverom a položky SAN certifikátu.

Po piate, zmeňte ho cez overený kanál

Keď sa brána legitímne pohybuje, aktualizujte najprv adresu a nechajte identitu na pokoji, pretože v tomto prípade sa IKEv2 dobre ovláda. Keď sa zmení samotná identita, zaobchádzajte s tým ako s udalosťou dôvery a získajte novú hodnotu zo zdroja, ktorému už dôverujete, nie z koncového bodu, ktorý momentálne zlyháva. Správa doručená cez pripojenie, ktoré sa pokúšate overiť, nie je dôkazom tohto pripojenia.

Zaznamenajte si konečnú adresu, identitu a zoznam SAN spolu do poznámok k profilu. Ďalšia osoba, ktorá sa dotkne certifikátu, potom uvidí, ktorý z troch sa môže pohybovať.