IKEv2 palvelimen osoite vs identiteetti: mitä asiakas todella tarkistaa
Osoite kertoo minne soittaa; identiteetti kertoo, mikä vertais hyväksyy. Niiden sekoittaminen aiheuttaa sen, että siirretty yhdyskäytävä tai uusi varmenne rikkoutuu IKEv2.
Osoitetta vaihtava yhdyskäytävä voi jatkaa toimintaansa, kun sama yhdyskäytävä uuden varmenteen takana pysähtyy, ja tapahtuu myös päinvastoin. Osoite kertoo asiakkaalle, minne paketit lähetetään; todennettu identiteetti kertoo asiakkaalle, onko vertaisvastaava se, johon sen pitäisi luottaa. IKEv2 säilyttää ne kahtena erillisenä kenttänä, mikä on hyödyllistä, kun lopetat niiden käsittelemisen yhtenä merkkijonona. Ne on myös konfiguroitu eri paikkoihin, joten yksi voi olla oikein, kun taas toinen on väärä.
Tarkista ne tässä järjestyksessä ja lopeta ensimmäiseen yhteensopimattomuuteen, koska myöhemmissä tarkistuksissa oletetaan, että aikaisemmat ovat läpäisseet.
Ensinnäkin mikä arvo on osoite
Yhteysosoite on se, mitä asiakas valitsee: IP-osoite, DNS-nimi, joka ratkaisee yhdeksi, tai kuormitettu käyttöliittymä. Se on liikennetietoa eikä mitään muuta. Identiteetti kulkee IKEv2 ID-hyötykuormassa ja sitä verrataan sitten vertaissertifikaattiin. Osoiteruudussa olevasta DNS-nimestä ei tule odotettua identiteettiä, eikä raaka-IP:stä tule identiteettiä vain siksi, että siihen on liitetty pistoke.
strongSwan:ssa osoite on right tai left ja odotettu identiteetti on rightid tai leftid, ja tämä kuvataan IKEv2-määritysdokumentaatiossa. Jos olet vain muokannut osoitetta, olet määrittänyt puolet parista.
Toiseksi, mitä todistus voi todistaa
Tunnuksella on tyyppi, ja varmenteessa on oltava vastaava nimi. DNS-identiteetti tyydytetään dNSName-merkinnällä aiheen vaihtoehtoisessa nimessä; IP-identiteetti tarvitsee iPAddress-merkinnän. vpn.example.com:lle myönnetty todistus ei todista mitään kirjaimellisesta osoitteesta 203.0.113.10, ja tälle osoitteelle annettu todistus ei todista mitään nimestä. Uudelleenjulkaiseminen toiselle nimelle ei siis ole drop-in-korvaus, vaikka samaa avainta ja CA käytettäisiin uudelleen.
Nykyaikaiset asiakkaat jättävät huomioimatta yleisnimen, kun aiheen vaihtoehtoinen nimi on olemassa, ja monet jättävät sen huomiotta kokonaan. Jos SAN-luettelo ei sisällä asiakkaan tarkistamaa arvoa, kättely epäonnistuu sen jälkeen, kun varmenne on jo hyväksytty luotettavaksi, minkä vuoksi loki lukee identiteettivirheen eikä luottamusvirheen.
Kolmanneksi, kuinka kukin asiakas ilmaisee odotuksensa
Windows ottaa kirjoittamasi palvelimen nimen tai osoitteen ja vaatii varmenteen vastaavan sitä, joten IP-osoitteen kirjoittaminen luo IP-odotuksen. Android:n IKEv2-asiakasohjelma käyttäytyy samalla tavalla ja kumpikin hylkää voimassa olevan, julkisesti luotetun varmenteen, joka nimeää eri isäntäkoneen. Profiili voi alkaa epäonnistua vain siksi, että joku korvasi isäntänimen osoitteellaan siirron aikana. Katso, mitä asiakas kysyi, ennen kuin katsot, mitä varmenne sisältää.
Kohdassa strongSwan odotus on selvä: aseta rightid palvelimen todellisuudessa esittämään identiteettiin, joka voi poiketa oikeasta. Asettamalla sen arvoon %any hyväksyy kaiken vertaisohjelman ja poistaa tarkalleen sekin, jonka yrität pitää.
Neljänneksi, erota käyttäjän kirjautuminen vertaisidentiteetistä
EAP todennus ja palvelimen identiteetti vastaavat eri kysymyksiin. EAP-identiteetti, kuten [email protected], kertoo kuka käyttäjä on, kun asiakas on päättänyt, että palvelin on oikea. Salasanan kiertäminen ei voi korjata vertaisidentiteettivirhettä, koska yhteys ei koskaan saavuta käyttäjän kirjautumisvaihetta.
Puhdistetun raportin tulee nimetä molemmat: asiakkaan odottama identiteetti, palvelimen esittämä identiteetti ja varmenteen SAN-merkinnät.
Viidenneksi, vaihda se vahvistetun kanavan kautta
Kun yhdyskäytävä laillisesti liikkuu, päivitä ensin osoite ja jätä identiteetti rauhaan, koska näin IKEv2 käsittelee hyvin. Kun itse identiteetti muuttuu, käsittele sitä luottamustapahtumana ja hanki uusi arvo lähteestä, johon jo luotat, ei päätepisteestä, joka tällä hetkellä epäonnistuu. Vahvistamasi yhteyden kautta toimitettu viesti ei ole todiste kyseisestä yhteydestä.
Kirjoita lopullinen osoite, henkilöllisyys ja SAN luettelo yhdessä profiilimuistiinpanoihin. Seuraava henkilö, joka koskettaa varmennetta, näkee sitten, kumpi kolmesta saa liikkua.