Wi-Fi konektiĝas memstare; la VPN bezonas duarangan asociigon

La tekkomputilo aliĝas al Wi-Fi antaŭ ol vi sidiĝas, kaj la VPN ankoraŭ atendas klakon. Ŝalti aŭtomatan konekton en la VPN-profilo ŝanĝas nenion, ĉar tiu ŝaltilo regas la propran aktivigon de la profilo kaj NetworkManager traktas VPN kiel kunulon de baza konekto. La dokumentita mekanismo estas la duaranga listo de la baza konekto, kaj tio estas alia eco en alia loko.

Aŭtomata konekto ne estas la VPN-ŝaltilo

Wi-Fi aŭ Ethernet-profilo povas aktivigi sin mem ĉar ĝi posedas aparaton. VPN-kromaĵa profilo ne posedas aparaton en la sama senco; ĝi startas apud konekto, kiu posedas. Tial la aŭtomata-konekta flago ĉe la VPN aspektas ĝusta, konserviĝas korekte kaj produktas neniun tunelon. La flago respondas demandon pri la profilo, ne pri la reto, kiun ĝi bezonas.

Lego de la modelo tiel ankaŭ klarigas la malsukcesan reĝimon. La bazo konektiĝas, nenio petas la VPN starti, kaj la labortablo montras malkonektitan VPN apud konektita reto. Nenio rompiĝis; la asociigo neniam estis farita.

Identigu ambaŭ profilojn per UUID

nmcli -f NAME,UUID,TYPE connection show

Elektu la Wi-Fi aŭ Ethernet-profilo, kiu devas lanĉi la tunelon, poste la celatan VPN-profilo. Uzu UUID-ojn anstataŭ nomoj, ĉar nomo estas etikedo, kiun oni povas duobligi aŭ redakti, kaj UUID estas tio, kion la aktiviga vojo vere solvas.

Ne konfuzu profilnomon kun interfaca nomo aŭ adreso, kiun la maŝino nun havas. Tiuj estas tri malsamaj identigiloj, kiuj hazarde aspektas similaj en terminalo, kaj miksado de ili produktas modifon celantan nenion.

Aldonu la VPN al la baza konekto

nmcli connection modify uuid "PRIMARY_UUID" +connection.secondaries "VPN_UUID"

La plusa formo aldonas al la ekzistanta listo; se vi ĝin preterlasas, la listo anstataŭiĝas, kio silente forigas ĉiun alian duarangan konekton jam agordan. Unue kontrolu la nunan valoron kaj notu ĝin antaŭ ol ŝanĝi ion.

La konektaj agordoj de NetworkManager priskribas duarangajn konektojn kiel VPN-konektojn lanĉatajn kune kun la baza konekto. Ĉu indiĝena WireGuard-profilo estas la sama speco de objekto dependas de tio, kiel NetworkManager administras ĝin, do la sama komando povas esti la malĝusta ilo por tunelo, kiu aperas kiel interfaco anstataŭ kiel VPN-kromaĵo.

Ĉi tio estas ŝanĝo de konekta politiko, ne funkciigilo dum la rulado. Apliku ĝin per kiu ajn rekonekta procezo, kiun la lanĉado aprobas, kaj atendu, ke la unua aktivigo post la ŝanĝo kondutos alie ol la sesio, en kiu vi nun sidas.

Sekretoj ne estas parto de la asociigo

Duaranga enskribo diras „startigu ĉi tion kun tio“. Nenio en ĝi transdonas pasvorton, malŝlosas ŝlosilringon aŭ respondas al invito. Profilo, kiu sukcese aŭtentikigas post labortabla ensaluto, ankoraŭ povas malsukcesi, kiam ĝi aktiviĝas en kunteksto, kie la sekreta agento ne haveblas.

Uzu la subtenatan sisteman aŭ sekretagentan aranĝon por la reala lanĉado. Konservi la pasvorton de ĉiuj en skripto, por ke la tunelo povu starti sen observado, transformas aŭtentikigan dezajnon en dosieron, kiu postvivas sian posedanton en la laboro.

Legu ambaŭ eventojn, poste kontrolu la rimedon

Observu la bazan konekton kaj la VPN-aktivigon dum unu provo. Mankanta VPN-evento signifas, ke la ellasilo neniam estis agordita aŭ ke la UUID estas malĝusta. VPN-evento sekvata de aŭtentikiga malsukceso signifas, ke la ellasilo funkciis kaj la restanta problemo estas la akreditaĵo, kio estas alia ripeto.

Post aktivigo, petu la rimedon, kiu motivis la agordon, anstataŭ fidi la ikonon. Poste malkonektu intence kaj observu, kio okazas sekve, ĉar aŭtomata starta asociigo ne estas sekura ŝaltilo kaj ne promesas senfinajn reprovojn. Se la postulo estas „neniu trafiko sen la tunelo“, tio estas aparta politiko bezonanta propran agordon kaj propran teston. Konfuzi la du estas kiel maŝino finas rekonektante en buklo dum la uzanto kredas, ke ĝi estas protektita.