IKEv2 serveradres vs identiteit: wat de kliïnt eins kontrolearret

In poarte dy't adres feroaret kin wurkje bliuwe wylst deselde poarte efter in nij sertifikaat ophâldt, en it omkearde bart ek. It adres fertelt de kliïnt wêr't pakketten ferstjoerd wurde; de autentike identiteit fertelt de kliïnt oft it antwurd fan 'e peer dejinge is dy't hy fertrouwe moat. IKEv2 hâldt dy as twa aparte fjilden, wat nuttich is as jo ophâlde om se as ien tekenrige te behanneljen. Se binne ek konfigureare op ferskate plakken, sadat ien korrekt kin wêze, wylst de oare ferkeard is.

Kontrolearje se yn dizze folchoarder en stopje by de earste mismatch, om't de lettere kontrôles oannimme dat de eardere trochjûn binne.

Earst, hokker wearde is it adres

It ferbiningsadres is wat de kliïnt ek belt: in IP, in DNS namme dy't oplost nei ien, of in load-balansearre frontend. Dat is ferfier ynformaasje en neat mear. De identiteit rydt yn 'e IKEv2 ID-lading en wurdt dan matched mei it sertifikaat fan 'e peer. In DNS namme yn it adres fak wurdt net de ferwachte identiteit, en in rau IP wurdt net de identiteit krekt omdat de socket ferbûn oan it.

Yn strongSwan termen is it adres right of left, en de ferwachte identiteit is rightid of leftid, en dat is wat de IKEv2 konfiguraasjedokumintaasje beskriuwt. As jo allinich it adres hawwe bewurke, hawwe jo de helte fan it pear konfigureare.

Twad, wat it sertifikaat kin bewize

De identiteit hat in type, en it sertifikaat moat in oerienkommende namme drage. A DNS identiteit wurdt tefreden troch in dNSName yngong yn it ûnderwerp alternative namme útwreiding; in IP-identiteit hat in iPAddress yngong nedich. In sertifikaat útjûn foar vpn.example.com bewiist neat oer it letterlike adres 203.0.113.10, en ien útjûn foar dat adres bewiist neat oer de namme. Opnij útjaan foar in oare namme is dus gjin drop-in ferfanging, sels as deselde kaai en CA wurde opnij brûkt.

Moderne kliïnten negearje de mienskiplike namme as in ûnderwerp alternative namme bestiet, en in protte negearje it folslein. As de SAN list net de wearde befettet dy't de kliïnt kontrolearret, mislearret de handshake nei't it sertifikaat al akseptearre is as betrouber, dat is de reden wêrom't it log as in identiteitsflater lêst as in fertrouwenflater.

Tredde, hoe't elke klant de ferwachting stelt

Windows nimt de servernamme of adres dy't jo ynfierd hawwe en fereasket dat it sertifikaat der oerienkomt, dus it typen fan in IP makket in IP-ferwachting. Android's IKEv2-kliïnt gedraacht deselde manier, en beide wegerje in jildich, iepenbier fertroud sertifikaat dat in oare host neamt. In profyl kin begjinne te mislearjen allinnich om't immen de hostnamme ferfong troch syn adres by in migraasje. Sjoch wêr't de klant om frege foardat jo sjogge wat it sertifikaat befettet.

Op strongSwan is de ferwachting eksplisyt: set rightid op de identiteit dy't de tsjinner eins presintearret, dy't oars kin fan rjochts. It ynstellen op %any akseptearret wat de peer biedt en ferwideret krekt de kontrôle dy't jo besykje te hâlden.

Fjirde, aparte brûkersoanmelding fan peer-identiteit

EAP autentikaasje en de serveridentiteit beantwurdzje ferskate fragen. In EAP identiteit lykas [email protected] seit wa't de brûker is, neidat de kliïnt besletten hat dat de tsjinner de juste is. It rotearjen fan dat wachtwurd kin gjin peer-identiteitsmismatch reparearje, om't de ferbining noait it brûker-oanmeldstadium berikt.

In sanearre rapport moat beide neame: de identiteit dy't de kliïnt ferwachte, de identiteit dy't de tsjinner presintearre, en de yngongen fan it sertifikaat SAN.

Fyfde, feroarje it fia in ferifiearre kanaal

As de gateway legitime beweecht, fernij dan earst it adres en lit de identiteit allinnich, want dat is it gefal IKEv2 behannelet goed. As de identiteit sels feroaret, behannelje it dan as in fertrouwensevenemint en krije de nije wearde fan in boarne dy't jo al fertrouwe, net fan it einpunt dat op it stuit mislearret. In berjocht levere oer de ferbining dy't jo besykje te falidearjen is gjin bewiis oer dy ferbining.

Notysje it definitive adres, identiteit en SAN list tegearre yn 'e profylnotysjes. De folgjende persoan dy't it sertifikaat oanrekke sil dan sjen wa fan 'e trije ferhúzje mei.