IKEv2-varmenne ja SAN: miksi identiteettitarkistus epäonnistuu
Kelvollinen IKEv2-varmenne epäonnistuu silti, kun odotettu identiteetti ja SAN-tyyppi eivät vastaa toisiaan. Yhdistä DNS DNS:ään, IP IP:hen ja tarkista profiili ensin.
Varmenteesi ketjuutuu luotettuun CA:han, päivämäärät ovat kunnossa, ja vertaiskone silti kieltäytyy suorittamasta vaihetta 1 identiteettivirheellä. Tavoitettavuus ja kelvollinen allekirjoitus ovat vain puolet siitä, mitä IKEv2-asiakas tarkistaa. Toinen puoli on, esiintyykö odotettu identiteetti varmenteessa oikeassa kentässä, ja tämän odotuksen asettaa profiili, ei varmenteen tiedostonimi.
Oire on aina samanmuotoinen
Yhteysprofiili vaihdetaan isäntänimestä IP-osoitteeksi tai uusitaan varmenteesta, jossa oli DNS-nimi, sellaiseen, jossa on vain osoitteita, ja tunneli lopettaa neuvottelun. Verkkopolulla mikään ei muuttunut. Asiakas saavuttaa vertaiskoneen, saa varmenteen ja hylkää vertaiskoneen identiteetin, koska tunniste, jota sen piti odottaa, ei ole edustettuna kentässä, jonka se hyväksyy. Uusinnat ovat tavallinen laukaisija, sillä korvaava varmenne tulee usein eri mallista kuin korvattava.
Molemmat osapuolet kirjaavat sitten jotain hyödytöntä, minkä vuoksi vika raportoidaan yleensä varmenneongelmana. Asiakkaan loki saattaa nimetä identiteetin, jota se halusi, ja se nimi on etsimäsi vihje, ei vanhenemispäivä.
Sovita tunnisteen tyyppi, älä vain arvoa
dNSName-SAN ja iPAddress-SAN ovat eri kenttiä, joilla on eri vastaavuussäännöt, joten varmenne, jossa 203.0.113.10 on DNS-merkkijonona, ei tyydytä asiakasta, joka odottaa IP-identiteettiä. Nykyaikaiset validoijat jättävät yleisnimen suurelta osin huomiotta, joten varmenteen tietojen ystävällinen nimiö ei todista mitään siitä, mikä vastaa. Jos isäntänimi korvattiin osoitteella vianetsinnän aikana, oleta odotetun identiteetin siirtyneen mukana, kunnes olet tarkistanut. Vertaa profiilin merkkijonoa SAN:n merkkijonoon merkki merkiltä, sillä loppupiste tai ylimääräinen välilyönti riittää.
Jokerimerkit ovat mukavuus vain DNS:lle ja noudattavat omia vastaavuussääntöjään, mikä on toinen syy, miksi IP-pohjaisen profiilin ei koskaan pitäisi luottaa niihin.
Selvitä, mihin kukin asiakas tallentaa odotuksen
strongSwanissa varmenteeseen verrattava arvo tulee vertaiskoneen identiteettiasetuksesta: rightid klassisessa kokoonpanossa tai swanctlin etäyhteysosion id. Applen IKEv2-yhteentoimivuutta koskeva dokumentaatio on tässä hyödyllinen, koska se selittää identiteettikäytännöt, joita profiiliohjattu asiakas käyttää, ja nämä käytännöt selittävät luokan yhteensopimattomuuksia, jotka näyttävät verkossa satunnaisilta.
Applen kokoonpanoprofiilit sisältävät etätunnisteen kentän, ja sen arvo on se, mitä asiakas tarkistaa, ei palvelimen osoite yhteyden asetuksissa. Windows- ja laiteasiakkailla on kullakin oma kenttänsä ja oma oletusarvonsa, ja oletus seuraa usein kirjoittamaasi osoitetta. Kun kaksi kenttää ovat ristiriidassa, voittaa se, jota asiakas todella lukee, ja se on harvoin se, jota muokkasit.
Korjaa profiili tai varmenne tarkoituksella
Tarkastele vertaiskoneen varmenne hyväksytyillä työkaluilla ja luettele SAN-merkinnät tyyppeineen ennen kuin muutat mitään. Tämä tarkastelu ei vaadi yksityistä avainta eikä latausta, ja se ratkaisee kysymyksen sekunneissa. Jos käyttöönotto tarkoittaa yhtä DNS-identiteettiä, varmenteen on kannettava se dNSName-merkintänä, ja jos se tarkoittaa osoitetta, varmenne tarvitsee iPAddress-merkinnän täsmälleen sille osoitteelle.
Kun varmenne on väärä, pyydä operaattorilta korjattu varmenne, jossa on tarkka odotettu tunniste. Kun profiili on väärä, korjaa profiili ja jätä varmenne rauhaan. Identiteetin validoinnin poistaminen käytöstä saa virheen katoamaan ja poistaa tarkistuksen, että tunneli puhuu tarkoittamasi vertaiskoneen kanssa.
Dokumentoi odotettu identiteetti asiakasalustakohtaisesti, koska arvo, jonka yksi asiakas johtaa automaattisesti, voi toisessa vaatia nimenomaisen ilmoituksen.
Anna uusintapyynnölle neljä tosiasiaa
Kirjoita odotettu tunniste ja sen tyyppi, SAN-merkinnät, jotka nykyisessä varmenteessa todella on, tarkistuksen tekevä asiakas ja versio sekä virheen tarkka teksti. Näistä neljästä rivistä rakennettu uusintapyyntö saa oikean varmenteen ensimmäisellä kerralla, eikä vielä yhtä samalla tutulla tiedostonimellä.