Remote ID sa VPN sa iPhone: ano talaga ang ibig sabihin ng field na iyon

Nasa Settings ka at nagdadagdag ng IKEv2 na configuration, at may dalawang field na humihingi ng tekstong walang nagbigay sa iyo: Remote ID at Local ID. Wala sa kanila ang iyong username, at wala sa kanila ang pangalawang kopya ng field na Server. Ang Remote ID ay ang pagkakakilanlang dapat patunayan ng gateway sa iyong iPhone; ang Local ID ay ang pagkakakilanlang inaangkin ng iyong iPhone sa gateway. Magkamali ka sa alinman at mamamatay ang tunnel pagkatapos nang sumagot ang server, kaya ang kabiguan ay mukhang problema sa password ngunit hindi.

Saan matatagpuan ang mga field sa iOS

Buksan ang Settings > Pangkalahatan > VPN at pamamahala ng device > VPN at magdagdag ng IKEv2 na configuration. Sa ilalim ng Authentication pipiliin mo ang Username o Certificate, at doon lamang lilitaw ang Remote ID at Local ID bilang malayang text box. Mga identifier ang mga ito, hindi address: dinadala sila ng iOS sa IKE_AUTH exchange, kung saan tinatawag ng IKEv2 na IDi ang pagkakakilanlan ng nagpasimula at IDr ang sa tumugon.

Pagkatapos mong i-save, tinutupi ng iOS ang configuration sa isang hilera at hindi na ipinapakita ang mga value. I-tap ang info button o buksan muli ang profile bago ka magpasya na walang laman ang mga field. Ang configuration na itinulak ng MDM ay maaaring gawing buong abo ang mga ito, at binabago niyon kung sino ang makakapag-ayos ng problema.

Ang Remote ID ay ang pangalan ng gateway

Ito ang value na inaasahan ng iyong iPhone na patunayan ng server. Sa authentication gamit ang certificate, ito ay inihahambing sa pangalan sa certificate ng server, karaniwang subject o isang subjectAltName entry. Kung ang certificate ay inilabas para sa vpn.example.com, ang hostname na iyon ang Remote ID, kahit na marating mo ang makina sa hubad na IP address.

Ang hindi pagkakatugmang iyon ang klasikong kabiguan: dumarating ang mga packet, sumasagot ang server, at bumabagsak pa rin ang koneksyon dahil ang pagkakakilanlan sa certificate ay hindi tugma sa hinihingi ng profile. Hindi nakakatulong ang ituro ang field na Server sa hilaw na IP, at sa maraming gateway ay tumitigil na lang ang server sa pagsagot sa pagkakakilanlang hindi nito kayang itugma.

May katumbas na setting ang gateway. Ang server na strongSwan ay nagpapadala ng sariling pagkakakilanlan gamit ang leftid at maaaring limitahan ang pagkakakilanlan ng kliyente gamit ang rightid; kung hindi magkasundo ang dalawang panig sa string, nabigo ang IKE_AUTH sa parehong direksyon. Itanong sa operator kung para sa aling pagkakakilanlan inilabas ang certificate sa halip na kopyahin ang URL mula sa address bar.

Idinodokumento ng Apple ang mga payload key bilang RemoteIdentifier at LocalIdentifier sa reference ng mga setting ng IKEv2. Parehong ordinaryong string ang mga ito, kaya maaaring mahalaga ang malaking maliit na titik at puwang sa dulo.

Ang Local ID ay ang inaangkin ng iyong iPhone

Sa authentication gamit ang username, sinusuri ng EAP ang pangalan at password, at ang Local ID ay hiwalay na IKE identity na ipinapatupad din ng ilang gateway. Maaaring hilingin ng gateway na ang Local ID ay katumbas ng username, isang email address, o tugma sa isang entry sa patakaran ng koneksyon nito; hindi ito pinapansin ng iba. Ligtas lamang ang iwanan itong blangko kapag sinabi ng operator.

Sa authentication gamit ang certificate, dapat tumugma ang Local ID sa pagkakakilanlang tinatanggap ng gateway para sa certificate ng kliyenteng iyon, madalas ang common name ng certificate o halagang nakamapa sa isang record ng device. Ang pagkopya ng profile ng katrabaho ay kinokopya rin ang pagkakakilanlan niya. Sa pinakamabuti, mali ang naitatalang device ng gateway; sa pinakamasama, tinatanggihan ka ng patakaran bawat device.

Ang bitag ay ang ipalagay na ang blangko ay walang pagkakakilanlan. Huwag punan ang blangkong field ng iyong email address dahil lang mukhang hindi pa tapos. Kumpirmahin ang nilalayong halaga at ilagay ito nang eksakto tulad ng ibinigay.

Limang minutong pagsusuri bago mag-save

Pagdaanan sila sa pagkakasunod-sunod; ang unang hakbang na mabibigo ang dapat ayusin.

1. Kumuha ng tatlong string mula sa operator: ang pangalan sa certificate ng server, ang inaasahang Local ID at ang paraan ng authentication.
2. Itugma ang paraan ng authentication. Hindi pinapalitan ng Remote ID at Local ID ang username at password, at hindi tatanggap ng password ang profile ng certificate.
3. I-type ang mga value nang eksakto, kasama ang malaking maliit na titik, walang puwang sa dulo.
4. Iwanang nakabukas ang validation ng certificate. Ang pag-install ng walang kaugnayang root certificate para patahimikin ang babala ay nagtatago ng hindi pagkakatugma ng pangalan sa halip na ayusin ito.
5. Subukan gamit ang mobile data, hindi ang Wi-Fi ng opisina, upang ang captive portal o split DNS ay hindi magpanggap na problema sa pagkakakilanlan.

Basahin ang talahanayan mula sa itaas. Ang timeout sa hilera ng Server ay nangangahulugang hindi kailanman nasubukan ang mga field ng pagkakakilanlan, kaya huminto doon. Ang error na lumilitaw lamang pagkatapos sumagot ang server ay halos palaging hindi pagkakatugma ng Remote ID o Local ID.

Mga error na tumuturo sa maling field

Ang mensaheng tulad ng "User authentication failed" ay tungkol sa credentials o EAP, hindi sa Remote ID. Ang babala ng certificate ay tungkol sa pangalan sa certificate, at doon nagtatagpo ang Remote ID at ang field na Server. Ang "The VPN server did not respond" ay karaniwang nangangahulugang hindi natapos ang UDP 500 at 4500, o nabigo ang NAT traversal, at walang pagkakakilanlang inihambing.

Sa panig ng gateway, iba ang hitsura ng mga kabiguan sa pagkakakilanlan: tinatanggihan ang peer habang IKE_AUTH, o pinapangalanan ng log ang ID na ipinadala ng kliyente at sinasabing hindi ito tugma sa anumang koneksyon. Ang linyang iyon sa log ang pinakamabilis na paraan upang tapusin ang debate, dahil ipinapakita nito ang eksaktong string na ipinadala ng telepono.

Hindi aayusin ng pag-reset ng password ang inaasahang pagkakakilanlan ng server, at hindi aayusin ng pagbabago ng Remote ID ang maling password. Ihiwalay muna ang yugto, pagkatapos ay i-edit ang field na kabilang sa yugtong iyon.

Kapag pinamamahalaan ang profile

Kung abo ang mga field, galing sa MDM ang configuration at hindi ang telepono ang lugar para ayusin iyon. Dinadala ng VPN payload ang mga identifier, kaya ang tamang pagbabago ay nasa profile sa management server, kasunod ang muling pag-install sa device.

Tingnan sa Settings > Pangkalahatan > VPN at pamamahala ng device kung pinamamahalaan ang profile at sino ang pumirma. Kung hindi mo ito matanggal, hindi mo maaaring i-edit ang mga identifier sa lokal, at ang pangalawang lokal na profile ay gumagawa lamang ng magkasalungat na configuration.

Bago mo isara ang Settings, isulat ang tatlong string na inilagay mo at kung saan sila nagmula. Sa susunod na mabigo ang tunnel, ihambing ang ID na natanggap sa log ng gateway sa talaang iyon: kung iba, tinitingnan mo ang field, hindi ang password.