Ang group secret ng vpnc o ang iyong login: aling field ang tumatanggap ng ano?
Hinihiling ng profile ng vpnc ang isang group ID, group secret at XAuth login, at inilalagay ng mga tao ang password ng account sa maling kahon. Itugma ang bawat field sa papel nito.
Sa unang pagkakataon na bigyan ka ng isang tao ng profile ng vpnc, ang dialog ng mga kredensyal ay nagtatanong ng apat na bagay at parang isang password lang ang gusto. Hindi: ang group secret na ibinahagi nang maaga at ang indibidwal na XAuth login ay magkaibang halaga na may magkaibang may-ari, at ang paglalagay ng password ng account sa field ng grupo ay nagdudulot ng pagkabigo na mukhang maling password kaysa maling kahon. Ang tamang pagtutugma ang buong gawain dito. Ang protocol sa ilalim ay proyekto ng migration ng ibang tao, kaya wala sa mga ito ang argumento para bumuo ng mga bagong IKEv1 tunnel.
Dalawang sekreto, dalawang may-ari, isang dialog
Ang group secret ay pag-aari ng profile ng gateway. Lahat ng kumokonekta sa profile na iyon ay gumagamit ng parehong halaga, at iyon ang dahilan kung bakit hindi nito matukoy ang isang tao at hindi ito maaaring bawiin mula sa isang laptop nang hindi binabago para sa lahat ng iba pang gumagamit ng profile. Ang XAuth username at password ay pag-aari ng tao sa halip, at sinusuri ito ng gateway sa ikalawang yugto pagkatapos na nakatayo na ang IPsec association.
Ang anyong dalawang yugto ang madalas na hindi napapansin. Ang pagtatayo ng tunnel at ang pagpapatunay ng user ay magkaibang palitan na may magkaibang input, kaya ang client na hindi umabot sa prompt ng kredensyal ay hindi talaga nabigo sa login. Basahin ang dialog bilang dalawang hanay sa halip na isa: mga halagang pangbuong profile sa kaliwa, mga personal na halaga sa kanan. Kapag nabigo ang koneksyon, ang huling hanay na nilagyan mo ay hindi awtomatikong ang may kasalanan.
Itugma ang mga field sa papel, hindi sa label
Pinangalanan ng vpnc ang mga direktiba nito sa dokumentasyon ng proyekto, at binibigyan sila ng bagong pangalan ng bawat graphical frontend. Isalin ang papel ng bawat halaga, at hindi na mahalaga ang mga label:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
Ang frontend na nagpapakita ng «Username» at «Password» sa tabi ng field ng grupo ay hindi mali — ang mga ito ay parehong tatlong halaga sa magkaibang pangalan. Ang nasisira ay ang pagpuno ng kahon dahil kasya ang isang halaga dito. Ang group secret na idinikit bilang password ng user ay nagpapatunay sa profile at pagkatapos ay nabigo sa yugto ng user; ang password ng account na idinikit bilang group secret ay nabigo nang mas maaga, bago ang anumang hiling, at pinapunta ang mga tao sa mga firewall para sa problemang nakatira sa isang text field.
Ano ang hindi isang group identifier
Inaanyayahan ng salitang grupo ang maling pagbasa. Ang group identifier dito ay isang tagapili na nagsasabi sa gateway kung aling configuration ng profile ang ilalapat; wala itong sinasabi tungkol sa membership sa directory, at ang tugmang pangalan sa magkabilang panig ay aksidente hanggang kumpirmahin ito ng operator. Ang awtorisasyon ay nangyayari pagkatapos ng matagumpay na XAuth, pinagpapasyahan ng kung ano ang naka-configure na konsultahin ng gateway, at wala sa mga ito ang nakikita sa dialog ng client.
Ang parehong pag-iingat ay naaangkop sa group secret. Ang pag-alam dito ay hindi pagkakakilanlan, at ang pagpapalipat-lipat ng isang sekreto sa isang team ay desisyong pang-operasyon na may mga kahihinatnan na hindi maipakita sa iyo ng client.
Lutasin ang malabong tagubilin bago kumonekta
Ang mga tala ng turnover na namana ay madalas may linyang tulad ng «gamitin ang dedikadong public IP». Ang pariralang iyon ay maaaring mangahulugan ng address kung saan inaasahan ng allowlist sa kabilang panig na darating ang iyong trapiko, ito ay katangian ng labasan ng network ng operator at walang kinalaman sa endpoint na tina-type mo sa field ng gateway. Itanong kung alin sa dalawa ang tinutukoy bago pumunta ang halaga kahit saan. Kapag pinuno nang baliktad, ipinapadala nito ang bawat packet sa address na hindi kailanman tumutugon, at ang resultang timeout ay mababasa na parang naka-block na port.
Humingi ng apat na bagay sa verified channel ng organisasyon: aling client at protocol ang sinusuportahan, aling endpoint ang gagamitin, anong pagkakakilanlan ang ipapakita ng gateway, at paano ibinibigay ang mga kredensyal. Ilayo ang tunay na mga sekreto sa mga screenshot, ticket at ibinahaging tala sa pag-troubleshoot. Huwag i-disable ang mga pagsusuri ng certificate at huwag idikit ang lumang cipher list para magmukhang compatible ang isang serbisyong naka-configure nang iba, dahil ang koneksyong gumagana lamang sa pamamagitan ng pagpapahina ng verification ay hindi ang koneksyong hiniling sa iyo na buuin.
Panatilihing tapat ang lumang profile
Hindi na ginagamit ang IKEv1, at ang RFC 9395 ang dokumentong dapat banggitin kapag lumitaw ang tanong ng migration. Ang matagumpay na pagtutugma ng field ay hindi patunay na kabilang ang protocol sa isang bagong disenyo; ang binibili nito ay gumaganang koneksyon habang naka-iskedyul ang kapalit, kasama ang nakasulat na saklaw at may-ari para sa migration na iyon.
Pagkatapos, i-verify laban sa kinakailangan at hindi laban sa dialog. Pagkatapos kumonekta, kumpirmahin na ang interface ng tunnel ay may inaasahang address at ang panloob na destinasyon ay niruruta sa pamamagitan nito; kung pinangalanan ng orihinal na kinakailangan ang isang exit address para sa allowlist, kumpirmahin din ang address na iyon, dahil ibang katotohanan ito kaysa sa nakatayo ang tunnel. Ang profile na wastong nagpapatunay at walang niruruta ay nabigo pa rin sa gawaing ginawa ito.