Klēpjdators pieslēdzas Wi-Fi pirms jūs apsēžaties, un VPN joprojām gaida klikšķi. Automātiskās pieslēgšanās iestatīšana VPN profilā neko nemaina, jo šis slēdzis pārvalda paša profila aktivizāciju, un NetworkManager uzskata VPN par bāzes savienojuma pavadoni. Dokumentētais mehānisms ir bāzes savienojuma sekundāro savienojumu saraksts, un tā ir cita īpašība citā vietā.

Automātiskā pieslēgšanās nav VPN slēdzis

Wi-Fi vai Ethernet profils var aktivizēties pats, jo tam pieder ierīce. VPN spraudņa profilam tādā pašā nozīmē nepieder ierīce; tas tiek palaists līdzās savienojumam, kuram tā pieder. Tāpēc automātiskās pieslēgšanās karodziņš uz VPN izskatās pareizi, saglabājas korekti un nerada tuneli. Karodziņš atbild uz jautājumu par profilu, nevis par tīklu, kas tam vajadzīgs.

Šāda modeļa lasīšana izskaidro arī kļūmes veidu. Bāze pieslēdzas, nekas neprasa VPN sākt, un darbvirsma rāda atvienotu VPN blakus pieslēgtam tīklam. Nekas nav salauzts; asociācija nekad netika izveidota.

Identificējiet abus profilu pēc UUID

nmcli -f NAME,UUID,TYPE connection show

Izvēlieties Wi-Fi vai Ethernet profilu, kuram jāiedarbina tunelis, tad paredzēto VPN profilu. Izmantojiet UUID, nevis nosaukumus, jo nosaukums ir birka, ko var dublēt vai rediģēt, un UUID ir tas, ko aktivizācijas ceļš patiešām atrisina.

Nejauciet profila nosaukumu ar saskarnes nosaukumu vai adresi, kas mašīnai pašlaik ir. Tie ir trīs dažādi identifikatori, kas terminālī nejauši izskatās līdzīgi, un to sajaukšana rada izmaiņas, kas vērstas uz neko.

Pievienojiet VPN bāzes savienojumam

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

Forma ar plusu pievieno esošajam sarakstam; to izlaižot, saraksts tiek aizstāts, kas klusi noņem jebkuru citu jau konfigurētu sekundāro savienojumu. Vispirms apskatiet pašreizējo vērtību un pierakstiet to, pirms kaut ko maināt.

NetworkManager savienojumu iestatījumi sekundāros raksturo kā VPN savienojumus, kas tiek palaisti kopā ar bāzes savienojumu. Vai vietējais WireGuard profils ir tāda paša veida objekts, atkarīgs no tā, kā NetworkManager to pārvalda, tāpēc tā pati komanda var būt nepareizs rīks tunelim, kas parādās kā saskarne, nevis kā VPN spraudnis.

Šīs ir savienojuma politikas maiņa, nevis izpildlaika slēdzis. Piemērojiet to, izmantojot jebkuru atkārtotas pievienošanās procesu, ko apstiprina izvietošana, un gaidiet, ka pirmā aktivizācija pēc izmaiņām uzvedīsies citādi nekā sesija, kurā tagad sēžat.

Slepenie dati nav asociācijas daļa

Sekundārais ieraksts saka «palaid šo ar to». Nekas tajā nenodod paroli, neatver atslēgu glabātavu un neatbild uz uzvedni. Profils, kas pēc darbvirsmas pieteikšanās labi autentificējas, tomēr var neizdoties, kad to aktivizē kontekstā, kur slepeno datu aģents nav pieejams.

Faktiskajai izvietošanai izmantojiet atbalstīto sistēmas vai slepeno datu aģenta risinājumu. Visu paroļu glabāšana skriptā, lai tunelis varētu startēt bez uzraudzības, autentifikācijas dizainu pārvērš failā, kas pārdzīvo sava īpašnieka darba attiecības.

Izlasiet abus notikumus, pēc tam pārbaudiet resursu

Viena mēģinājuma laikā vērojiet bāzes savienojumu un VPN aktivizāciju. Trūkstošs VPN notikums nozīmē, ka trigeris nekad netika konfigurēts vai UUID ir nepareizs. VPN notikums, kam seko autentifikācijas kļūda, nozīmē, ka trigeris nostrādāja un atlikušā problēma ir akreditācijas dati, un tas ir cits labojums.

Pēc aktivizācijas pieprasiet resursu, kas motivēja iestatīšanu, nevis uzticieties ikonai. Pēc tam apzināti atvienojieties un vērojiet, kas notiks tālāk, jo automātiskas palaišanas asociācija nav avārijas slēdzis un nesola bezgalīgus atkārtojumus. Ja prasība ir «nav trafika bez tuneļa», tā ir atsevišķa politika, kurai vajadzīga sava konfigurācija un savs tests. Abu sajaukšana ir veids, kā mašīna sāk atkārtoti pievienoties cilpā, kamēr lietotājs tic, ka tā ir aizsargāta.

Saistītie raksti