Ang isang pangalawang VPN ay kabilang sa isang profile ng Wi-Fi, hindi sa lahat
Ang pangalawang VPN ay isang UUID na nakakabit sa isang baseng koneksyon. Planuhin kung paano ito mamanahin ng mga susunod na profile ng Wi-Fi at ano ang mangyayari kapag ang UUID na iyon ay pinalitan.
I-configure ang isang VPN bilang pangalawa ng koneksyon sa Wi-Fi sa bahay at gumagana ang lahat, hanggang sa sumali ang laptop sa ibang access point at manatiling nakababa ang tunnel. Ang bagong koneksyon ay isang hiwalay na object ng configuration na may sariling UUID, at wala itong dahilan para malaman ang ugnayang ginawa mo para sa nauna nito. Walang nasira; ang asosasyon ay hindi talaga kailanman umiral.
Ang sanggunian ng mga koneksyon ng NetworkManager ay tinutukoy ang mga pangalawa bilang mga UUID na nag-aaktibo kasama ng isang partikular na baseng koneksyon. Sinasabi rin nito na ang mga ordinaryong profile ng VPN ay hindi nagpapatupad ng awtomatikong pag-activate tulad ng ginagawa ng mga baseng koneksyon. Ang dalawang pahayag ay tumutungo sa parehong konklusyon: ang asosasyon ay para sa bawat profile, at kailangang gawin ito ng isang tao para sa bawat bago.
Ano ba talaga ang isang pangalawa
Ang isang baseng koneksyon ay may pagkakakilanlan, isang UUID at isang listahan ng mga pangalawa. Kapag nag-aaktibo ito, ina-activate din ng tagapamahala ang mga pangalawang iyon sa pagkakasunod-sunod, at ganoon sinusundan ng isang VPN ang isang network ng Wi-Fi nang walang klik na mano-mano. Ang relasyon ay naninirahan sa baseng koneksyon, nakasulat bilang mga string ng UUID sa halip na mga pangalan. Ang pagpiling iyon ng representasyon ay hindi nagkataon; ito ang nagpapahintulot sa asosasyon na mabuhay pagkatapos ng pagpapalit ng pangalan.
Ang detalyeng iyon tungkol sa mga pangalan ay mas mahalaga kaysa sa tila. Ang pagpapalit ng pangalan ng isang profile ng VPN ay iniiwan ang UUID nito na hindi nagalaw, kaya patuloy na gumagana ang mga umiiral na asosasyon. Ang pagtanggal ng lumang profile at pag-import ng bago ay lumilikha ng bagong UUID, at bawat asosasyong tumuturo sa luma ay hindi na tumuturo sa anuman.
Suriin ang umiiral na listahan bago magdagdag. Ang isang profile sa bahay na may isang pangalawa ay hindi isang tuntuning umaangkop sa bawat SSID; ito ay isang hilera sa isang object, at hindi ito sasangguni kapag nag-activate ang ibang base.
Ilagay ang asosasyon kung saan ginagawa ang mga profile
Sa isang personal na makina, gawing bahagi ng pagdaragdag ng bawat pinapayagang profile ng Wi-Fi ang pagkakabit ng nilalayong pangalawa. Ito ay ugali at hindi feature, ngunit ugali na gumagawa ng pare-parehong estado, at tumatagal ng isang utos o dalawang pagbisita sa dialog bawat network. Magtago ng maikling tala kung aling mga network ang dapat magdala ng tunnel, dahil ang listahan ang patakaran.
Sa mga pinamamahalaang device, hayaan ang workflow ng provisioning na gumawa ng entry ng Wi-Fi at ng asosasyon nito sa VPN sa parehong hakbang, at ilapat ang parehong pagtrato sa mga pinapayagang profile na mayroon na. Ang pamamahagi ng isang profile ng VPN nang mag-isa ay nag-iiwan sa mga baseng relasyon na hindi tinukoy, at ganoon nagtatapos ang isang fleet sa isang tunnel na kalahati lang ng mga laptop ang gumagamit.
Kung saan ang mga user ay makakagawa pa rin ng mga profile sa labas ng pinamamahalaang landas, magpasya nang tahasan kung ano ang mangyayari sa mga entry na iyon. Ang pagpapalagay na mamanahin nila ang isang asosasyon ay hindi patakaran; ito ay pag-asa na may kalakip na gastos sa suporta.
Planuhin ang pagbabago ng pagkakakilanlan ng VPN
Kailangan ng pinagmulan ng provisioning ang UUID ng nilalayong VPN, hindi isang display name na hinulaan ng isang tao. Kapag pinalitan ng maintenance ang VPN na iyon ng bagong na-import na object, i-update ang template ng provisioning at ang mga apektadong umiiral na asosasyon sa parehong pagbabago. Ang pagpapalit ng pangalan ay hindi pagpapalit, at ang pagtrato sa dalawa bilang katumbas ay kung paano nasisira ang isang gumaganang rollout makalipas ang isang linggo.
Itago ang UUID sa tabi ng dahilan kung bakit ito umiiral. Ang isang future engineer na makakahanap ng hubad na UUID sa isang listahan ng mga pangalawa ay walang paraan para sabihin kung ito ay kasalukuyan, at malamang na tanggalin ito habang naglilinis.
Ang pag-activate ay hindi pagpapatupad
Ang isang kahilingan para sa pangalawa ay nangyayari sa oras ng pag-activate. Hindi nito hinaharangan ang mga application sa pagitan bago makumpleto ang authentication, at hindi nito pinipigilan ang trapiko pagkatapos mabigo ang tunnel. Ito ay magkaibang mga katangian na ibinibigay ng magkaibang mekanismo, at ang paghahalo sa mga ito ay gumagawa ng disenyong mukhang mahigpit sa profile at mapagbigay sa praktika.
Ang pagharang ng direktang trapiko ay isang hiwalay na feature na may sariling configuration at sariling mga mode ng pagpalya, at dapat nitong isaalang-alang ang trapikong kailangang makarating sa network bago pa man umiral ang anumang tunnel: mga captive portal, mga pahina ng pag-sign in, ang endpoint mismo. Ang isang patakaran ng pagharang na hindi matutugunan bago ang authentication ay nagkakandado sa makina palabas ng mismong network na kailangan nito.
Ilagay ang pagkakaibang iyon sa mga tagubiling talagang binabasa ng mga user. Ang isang bagong network ng Wi-Fi ay maaaring humingi ng tunnel; ang pagpapatupad ang magpapasya kung may makakalabas kapag hindi makakonekta. Ang mga user na sinabihan lamang ng unang kalahati ay iuulat ang disenyo bilang sira.
Subukan gamit ang isang tunay na bagong profile
Gumamit ng isang aprubadong test network at isang bagong likhang baseng profile, hindi ang entry sa bahay na gumagana na. Obserbahan ang pag-activate ng base, ang hiniling na UUID ng pangalawa at anumang prompt ng authentication nang sunud-sunod, at itala kung aling yugto ang natigil kapag natigil. Ang isang lihim na agent na nagiging available pagkatapos ng pag-log in sa desktop ay hindi awtomatikong naroroon sa bawat konteksto ng startup, kaya ang isang reboot ay kabilang sa plano ng pagsubok. Pagkatapos ay suriin ang nilalayong resource at ang landas ng pagpalya: bumabangon ba ang tunnel bago ito kailanganin ng application, at ano ang nangyayari sa application na iyon kapag nabigo ang authentication?
Pagkatapos ay suriin ang nilalayong resource at ang landas ng pagpalya: bumabangon ba ang tunnel bago ito kailanganin ng application, at ano ang nangyayari sa application na iyon kapag hindi maka-authenticate ang tunnel? Ang dalawang obserbasyon na iyon ang pamantayan sa pagtanggap, at wala sa kanila ang nakikita sa profile mismo.