IKEv2 address ng server kumpara sa pagkakakilanlan: ano talaga ang sinusuri ng kliyente

Ang isang gateway na nagbabago ng address ay maaaring patuloy na gumagana habang ang parehong gateway sa likod ng isang bagong certificate ay humihinto, at ang kabaligtaran ay nangyayari rin. Ang address ay nagsasabi sa kliyente kung saan magpapadala ng mga packet; ang napatunayang pagkakakilanlan ay nagsasabi sa kliyente kung ang sagot ng kasamahan ay ang dapat nitong pagkatiwalaan. Pinapanatili ng IKEv2 ang mga iyon bilang dalawang magkahiwalay na field, na kapaki-pakinabang sa sandaling ihinto mo ang pagtrato sa kanila bilang isang string. Naka-configure din ang mga ito sa iba't ibang lugar, kaya maaaring tama ang isa habang mali ang isa.

Suriin ang mga ito sa pagkakasunud-sunod na ito at huminto sa unang mismatch, dahil ipinapalagay ng mga susunod na pagsusuri na pumasa ang mga naunang pagsusuri.

Una, aling halaga ang address

Ang address ng koneksyon ay anuman ang i-dial ng kliyente: isang IP, isang DNS na pangalan na nagre-resolve sa isa, o isang load-balanced na front end. Iyon ay impormasyon sa transportasyon at wala nang iba pa. Ang pagkakakilanlan ay sumasakay sa IKEv2 ID payload at pagkatapos ay itinugma sa certificate ng peer. Ang isang DNS na pangalan sa address box ay hindi nagiging inaasahang pagkakakilanlan, at ang isang raw IP ay hindi nagiging pagkakakilanlan dahil lamang ang socket ay nakakonekta dito.

Sa strongSwan termino, ang address ay right o left, at ang inaasahang pagkakakilanlan ay rightid o leftid, at iyon ang inilalarawan ng IKEv2 configuration documentation. Kung na-edit mo lang ang address, na-configure mo na ang kalahati ng pares.

Pangalawa, kung ano ang maaaring patunayan ng sertipiko

Ang pagkakakilanlan ay may isang uri, at ang sertipiko ay kailangang may katugmang pangalan. Ang isang DNS pagkakakilanlan ay nasiyahan sa pamamagitan ng isang dNSName na entry sa paksa na alternatibong extension ng pangalan; kailangan ng isang IP identity ng iPAddress entry. Ang isang sertipiko na inisyu para sa vpn.example.com ay walang pinatutunayan tungkol sa literal na address 203.0.113.10, at ang isa na ibinigay para sa address na iyon ay walang patunay tungkol sa pangalan. Samakatuwid, ang muling pag-isyu para sa ibang pangalan ay hindi isang drop-in na kapalit, kahit na ang parehong key at CA ay muling ginamit.

Binabalewala ng mga modernong kliyente ang karaniwang pangalan kapag mayroong isang alternatibong pangalan ng paksa, at marami ang hindi ganap na binabalewala ito. Kung ang listahan ng SAN ay hindi naglalaman ng value na sinusuri ng kliyente, ang handshake ay nabigo pagkatapos na matanggap ang certificate bilang mapagkakatiwalaan, kaya naman ang log ay nagbabasa na parang error sa pagkakakilanlan sa halip na isang trust error.

Pangatlo, kung paano sinasabi ng bawat kliyente ang inaasahan

Kinukuha ng Windows ang pangalan ng server o address na iyong na-type at nangangailangan ng certificate na tumugma dito, kaya ang pag-type ng IP ay lumilikha ng isang inaasahan sa IP. Ang kliyente ng Android ng IKEv2 ay kumikilos sa parehong paraan, at parehong tinatanggihan ang isang wasto, pinagkakatiwalaang sertipiko ng publiko na nagpapangalan sa ibang host. Maaaring magsimulang mabigo ang isang profile dahil lang pinalitan ng isang tao ang hostname ng address nito sa panahon ng paglilipat. Tingnan kung ano ang hiniling ng kliyente bago mo tingnan kung ano ang nilalaman ng sertipiko.

Sa strongSwan ang inaasahan ay tahasan: itakda ang rightid sa pagkakakilanlan na aktwal na ipinapakita ng server, na maaaring iba sa kanan. Ang pagtatakda nito sa %any ay tinatanggap ang anumang iniaalok ng kapantay at eksaktong inaalis ang tseke na sinusubukan mong panatilihin.

Pang-apat, paghiwalayin ang pag-login ng user mula sa pagkakakilanlan ng peer

Ang EAP authentication at ang pagkakakilanlan ng server ay sumasagot sa iba't ibang mga katanungan. Ang pagkakakilanlan ng EAP gaya ng [email protected] ay nagsasabi kung sino ang gumagamit, pagkatapos na mapagpasyahan ng kliyente na ang server ang tama. Ang pag-rotate sa password na iyon ay hindi makakapag-ayos ng peer identity mismatch, dahil ang koneksyon ay hindi umabot sa yugto ng user-login.

Parehong dapat pangalanan ng isang sanitized na ulat: ang pagkakakilanlan na inaasahan ng kliyente, ang pagkakakilanlan na ipinakita ng server, at ang mga entry ng SAN ng certificate.

Ikalima, baguhin ito sa pamamagitan ng isang na-verify na channel

Kapag ang gateway ay lehitimong lumipat, i-update muna ang address at iwanan ang pagkakakilanlan, dahil iyon ang kaso IKEv2 na humahawak nang maayos. Kapag ang mismong pagkakakilanlan ay nagbago, ituring ito bilang isang kaganapan ng pagtitiwala at kunin ang bagong halaga mula sa pinagkakatiwalaan mo na, hindi mula sa endpoint na kasalukuyang nabigo. Ang isang mensaheng inihatid sa koneksyon na sinusubukan mong patunayan ay hindi katibayan tungkol sa koneksyon na iyon.

Itala ang huling address, pagkakakilanlan at listahan ng SAN nang magkasama sa mga tala sa profile. Ang susunod na taong hahawak sa sertipiko ay makikita kung alin sa tatlo ang pinapayagang lumipat.