IKEv2 adresa e serverit kundrejt identitetit: çfarë kontrollon në të vërtetë klienti

Një portë që ndryshon adresën mund të vazhdojë të funksionojë ndërsa e njëjta portë pas një certifikate të re ndalon, dhe e kundërta ndodh gjithashtu. Adresa i tregon klientit se ku të dërgojë paketat; identiteti i vërtetuar i tregon klientit nëse kolegu që përgjigjet është ai që duhet t'i besojë. IKEv2 i mban ato si dy fusha të veçanta, gjë që është e dobishme sapo të ndaloni t'i trajtoni ato si një varg. Ato janë konfiguruar gjithashtu në vende të ndryshme, kështu që njëra mund të jetë e saktë ndërsa tjetra është e gabuar.

Kontrolloni ato në këtë renditje dhe ndaluni në mospërputhjen e parë, sepse kontrollet e mëvonshme supozojnë se ato të mëparshmet kanë kaluar.

Së pari, cila vlerë është adresa

Adresa e lidhjes është çfarëdo që telefonon klienti: një IP, një emër DNS që zgjidhet në një, ose një front i balancuar me ngarkesë. Ky është informacioni i transportit dhe asgjë më shumë. Identiteti kalon në ngarkesën e ID-së IKEv2 dhe më pas përputhet me certifikatën e kolegut. Një emër DNS në kutinë e adresave nuk bëhet identiteti i pritur dhe një IP e papërpunuar nuk bëhet identitet vetëm sepse priza është e lidhur me të.

Në termat e strongSwan, adresa është right ose left, dhe identiteti i pritshëm është rightid ose leftid, dhe kjo është ajo që përshkruan dokumentacioni i konfigurimit IKEv2. Nëse e keni modifikuar ndonjëherë adresën, ju keni konfiguruar gjysmën e çiftit.

Së dyti, çfarë mund të vërtetojë certifikata

Identiteti ka një lloj dhe certifikata duhet të ketë një emër që përputhet. Një identitet DNS plotësohet nga një hyrje dNSName në zgjerimin e emrit alternativ të subjektit; një identitet IP ka nevojë për një hyrje iPAddress. Një certifikatë e lëshuar për vpn.example.com nuk dëshmon asgjë për adresën e mirëfilltë 203.0.113.10 dhe një certifikatë e lëshuar për atë adresë nuk dëshmon asgjë për emrin. Prandaj, rilëshimi për një emër tjetër nuk është një zëvendësim i lëshuar, edhe kur i njëjti çelës dhe CA ripërdoren.

Klientët modernë e injorojnë emrin e zakonshëm kur ekziston një emër alternativ subjekti, dhe shumë e injorojnë atë plotësisht. Nëse lista SAN nuk përmban vlerën që kontrollon klienti, shtrëngimi i duarve dështon pasi certifikata është pranuar tashmë si e besueshme, kjo është arsyeja pse regjistri lexohet si një gabim identiteti dhe jo si një gabim besimi.

Së treti, si çdo klient shpreh pritshmërinë

Windows merr emrin ose adresën e serverit që keni shkruar dhe kërkon që certifikata të përputhet me të, kështu që shtypja e një IP krijon një pritje IP. Klienti Android i IKEv2 sillet në të njëjtën mënyrë dhe të dy refuzojnë një certifikatë të vlefshme, të besuar publikisht që emërton një host të ndryshëm. Një profil mund të fillojë të dështojë thjesht sepse dikush zëvendësoi emrin e hostit me adresën e tij gjatë një migrimi. Shikoni se çfarë kërkoi klienti përpara se të shikoni se çfarë përmban certifikata.

Në strongSwan pritshmëria është e qartë: vendosni rightid në identitetin që serveri në të vërtetë paraqet, i cili mund të ndryshojë nga djathtas. Vendosja e tij në %any pranon çdo gjë që ofron kolegu dhe heq pikërisht çekun që po përpiqeni të mbani.

Së katërti, ndani hyrjen e përdoruesit nga identiteti i kolegëve

Autentifikimi EAP dhe identiteti i serverit u përgjigjen pyetjeve të ndryshme. Një identitet EAP si [email protected] thotë se kush është përdoruesi, pasi klienti ka vendosur që serveri është i duhuri. Rrotullimi i atij fjalëkalimi nuk mund të rregullojë një mospërputhje të identitetit të kolegëve, sepse lidhja nuk arrin kurrë në fazën e hyrjes nga përdoruesi.

Një raport i dezinfektuar duhet të emërtojë të dyja: identitetin që klienti priste, identitetin që serveri paraqiti dhe hyrjet SAN të certifikatës.

Së pesti, ndryshoni atë përmes një kanali të verifikuar

Kur porta lëviz në mënyrë legjitime, përditësoni adresën fillimisht dhe lini identitetin të qetë, sepse ky është rasti që IKEv2 trajtohet mirë. Kur vetë identiteti ndryshon, trajtojeni atë si një ngjarje besimi dhe merrni vlerën e re nga një burim që tashmë i besoni, jo nga pika përfundimtare që aktualisht po dështon. Një mesazh i dërguar mbi lidhjen që po përpiqeni të vërtetoni nuk është dëshmi për atë lidhje.

Regjistroni adresën përfundimtare, identitetin dhe listën SAN së bashku në shënimet e profilit. Personi tjetër që do të prekë certifikatën do të shohë se cili nga të tre lejohet të lëvizë.