Sekundara VPN apartenas al unu Wi-Fi-profilo, ne al ĉiuj
Sekundara VPN estas UUID ligita al unu baza konekto. Planu, kiel estontaj Wi-Fi-profiloj heredos ĝin, kaj kio okazos, kiam tiu UUID estos anstataŭigita.
Agordu VPN kiel sekundaran de la hejma Wi-Fi-konekto kaj ĉio funkcias, ĝis la tekkomputilo aliĝos al alia alirpunkto kaj la tunelo restos mallevita. La nova konekto estas aparta agordobjekto kun propra UUID, kaj ĝi havas neniun kialon scii pri la ligo, kiun vi kreis por ĝia antaŭulo. Nenio misfunkciis; la asocio simple neniam ekzistis.
La konekta referenco de NetworkManager difinas sekundarajn kiel UUID-ojn, kiuj aktiviĝas kune kun aparta baza konekto. Ĝi ankaŭ notas, ke ordinaraj VPN-profiloj ne realigas aŭtomatan aktivigon tiel, kiel faras bazaj konektoj. Ambaŭ asertoj kondukas al la sama konkludo: la asocio estas por ĉiu profilo, kaj iu devas krei ĝin por ĉiu nova.
Kio efektive estas sekundara
Baza konekto havas identecon, UUID-on kaj liston de sekundaraj. Kiam ĝi aktiviĝas, la administranto ankaŭ aktivigas tiujn sekundarajn laŭorde, kaj tiel VPN sekvas Wi-Fi-retan sen mana klako. La rilato loĝas sur la baza konekto, skribita kiel UUID-ĉenoj anstataŭ nomoj. Tiu elekto de reprezentado ne estas hazarda; ĝi estas tio, kio igas la asocion postvivi renomigon.
Tiu detaleto pri nomoj gravas pli, ol ĝi aspektas. Renomigo de VPN-profilo lasas ĝian UUID-on netuŝita, do ekzistantaj asocioj daŭre funkcias. Forigo de la malnova profilo kaj enporto de nova produktas novan UUID-on, kaj ĉiu asocio, kiu montris al la malnova, nun montras al nenio.
Ekzamenu la ekzistantan liston antaŭ aldoni. Hejma profilo kun unu sekundara ne estas regulo, kiu konvenas al ĉiu SSID; ĝi estas unu vico en unu objekto, kaj ĝi ne estos konsultita, kiam alia bazo aktiviĝos.
Metu la asocion tie, kie profiloj kreiĝas
Sur persona maŝino, faru la alkroĉadon de la celata sekundara parto de aldoni ĉiun permesatan Wi-Fi-profilon. Tio estas kutimo, ne trajto, sed kutimo, kiu produktas konsekvencan staton, kaj ĝi postulas unu komandon aŭ du dialogvizitojn por reto. Tenu mallongan noton pri tio, kiuj retoj devus porti la tunelon, ĉar la listo estas la politiko.
Sur administrataj aparatoj, lasu la provizadon krei la Wi-Fi-eron kaj ĝian VPN-asocion en la sama paŝo, kaj aplikigu la saman traktadon al permesataj profiloj, kiuj jam ekzistas. Dissendo de VPN-profilo sola lasas la bazajn rilatojn nespecifitaj, kaj tiel aro da komputiloj finiĝas kun tunelo, kiun uzas nur duono de la tekkomputiloj.
Kie uzantoj ankoraŭ povas krei profilojn ekster la administrata vojo, decidu eksplicite, kio okazas al tiuj eroj. Supozi, ke ili heredas asocion, ne estas politiko; ĝi estas espero kun aldona subtena kosto.
Planu la ŝanĝiĝon de la identeco de la VPN
La provizfonto bezonas la UUID-on de la celata VPN, ne montran nomon, kiun iu divenis. Kiam bontenado anstataŭigas tiun VPN per ĵus enportita objekto, ĝisdatigu la provizŝablonon kaj la tuŝitajn ekzistantajn asociojn en la sama ŝanĝo. Renomigo ne estas anstataŭigo, kaj trakti la du kiel ekvivalentajn estas kiel funkcianta lanĉo rompiĝas semajnon poste.
Konservu la UUID-on apud la kialo, kial ĝi ekzistas. Estonta inĝeniero, kiu trovas nudan UUID-on en listo de sekundaraj, ne havas rimedon por diri, ĉu ĝi estas aktuala, kaj verŝajne forigos ĝin dum ordigado.
Aktivigo ne estas devigo
Peto pri sekundara okazas en la aktiviga momento. Ĝi ne blokas aplikojn dum la intervalo antaŭ ol aŭtentikigo finiĝos, kaj ĝi ne haltigas trafikon post kiam la tunelo fuŝiĝos. Tiuj estas malsamaj propraĵoj, provizitaj de malsamaj mekanismoj, kaj ilia konfuzado produktas dezajnon, kiu aspektas strikta en la profilo kaj estas indulgema en la praktiko.
Blokado de rekta trafiko estas aparta trajto kun propra agordo kaj propraj malsukcesmanieroj, kaj ĝi devas konsideri la trafikon, kiu devas atingi la reton antaŭ ol iu ajn tunelo povas ekzisti: kaptitaj portaloj, ensalutaj paĝoj, la finpunkto mem. Blokada politiko, kiun oni ne povas plenumi antaŭ aŭtentikigo, ŝlosas la maŝinon for de ĝuste tiu reto, kiun ĝi bezonas.
Metu tiun distingon en la instrukciojn, kiujn uzantoj efektive legas. Nova Wi-Fi-reto povas peti la tunelon; devigo decidas, ĉu io rajtas eliri, kiam ĝi ne povas konektiĝi. Uzantoj, al kiuj oni rakontas nur la unuan duonon, raportos la dezajnon kiel rompitan.
Testu per vere nova profilo
Uzu aprobatan testreton kaj ĵus kreitan bazan profilon, ne la hejman eron, kiu jam funkcias. Observu la bazan aktivigon, la petatan sekundaran UUID-on kaj ajnan aŭtentikigan instigon laŭvice, kaj notu, kiu stadio haltas, kiam ĝi haltas. Sekreta agento, kiu fariĝas disponebla post labortabla ensaluto, ne aŭtomate ĉeestas en ĉiu starta kunteksto, do restarto apartenas al la testplano. Poste kontrolu la celatan rimedon kaj la fiaskan vojon: ĉu la tunelo leviĝas antaŭ ol la apliko bezonas ĝin, kaj kio okazas al tiu apliko, kiam aŭtentikigo malsukcesas?
Poste kontrolu la celatan rimedon kaj la fiaskan vojon: ĉu la tunelo leviĝas antaŭ ol la apliko bezonas ĝin, kaj kio okazas al tiu apliko, kiam la tunelo ne povas aŭtentikigi? Tiuj du observoj estas la akceptkriterioj, kaj neniu el ili videblas en la profilo mem.