Ĉu ĉi tiu NetworkManager-kromaĵo povas funkciigi du VPN samtempe?

Du VPN-enskriboj staras en la konekta listo, ambaŭ diras konektita, kaj nur unu el ili portas la trafikon, kiun vi atendis. Aŭ la dua tute rifuzas starti, kaj neniu povas diri ĉu temas pri la kromaĵo, la kliento aŭ politiko, kiun vi forgesis. Asertoj pri limo de unu VPN priskribas apartajn realigojn, kaj realigoj varias. Unue trairu la kapablon, poste la kunordigon.

Kalkulu konservitajn profilojn, poste aktivigojn

Konservita profilo estas agorda objekto, kaj aktiva konekto estas kuranta okazo. La listo vide kunfandas la du konceptojn, tial ambaŭ raportoj sonas veraj. Komencu nomante la precizajn objektojn per iliaj UUID, ĉar la montrata nomo ne estas unika kaj malnova importo ofte kunhavas etikedon kun pli nova ero. Poste kontrolu la aktivan liston aparte kaj vidu, kiuj UUID aperas. Nur tiam vi scias, ĉu vi komparas du agordojn aŭ du vivajn tunelojn.

Aktivigi la saman UUID dufoje estas tria kazo, kaj ĝi ne estas samtempeco. Ĝi estas reaktivigo de unu okazo.

Legu la proprajn metadatumojn de la kromaĵo

Ĉiu VPN-kromaĵo liveras malgrandan metadatumdosieron, kiun la administrilo legas, kaj tiuj dosieroj povas deklari, ĉu la kromaĵo subtenas plurajn konektojn samtempe. Legu la dosieron instalitan en ĉi tiu maŝino anstataŭ ripeti tion, kion upstream-projekto nun skribas, ĉar la distribua pako decidas, kion vi efektive havas. La sama kontrolo validas por ĉiu protokolo: respondo por unu kromaĵo diras nenion pri alia. Notu la pakan version kune kun la rezulto, por ke posta komparo signifu ion.

Malnova konsilo pri limo de unu VPN priskribis pli malnovajn integriĝojn. Ĝi estas nek eterne vera nek sekure supozi ĝin fiksa, kaj la dosiero antaŭ vi decidas tion loke.

Samtempeco ne estas kunordigo

Tio, ke du kromaĵoj sukcese startas, pruvas la kapablon, ne la dezajnon. Du tuneloj, kiuj ambaŭ proponas defaŭltan itineron, konkurencos, kaj tiu, kiu instalis sian itineron laste, kutime venkas sen anonci tion. Interkovrantaj privataj gamoj havas la saman problemon en pli malgranda formo.

Decidu, kiuj celoj apartenas al kiu profilo, antaŭ ol aktivigi ion ajn. Renomigo de profilo ne distingas la celojn.

DNS elektas venkanton, ĉu vi faras tion aŭ ne

Agordoj de la solvilo estas por ĉiu profilo, kaj kiam du estas aktivaj, la solva ordo estas decidita de politiko kaj prioritato, ne de intenco. La profilo, kiu leviĝis laste, povas silente posedi ĉiun korporacian nomon.

Atribuu ĉiun privatan nomspacon al la solvilo, kiu devus respondi por ĝi, kaj starigu itineran preferon konscie anstataŭ fidi la ordon. Poste testu nomon el ĉiu nomspaco kun ambaŭ tuneloj levitaj, kaj denove kun unu el ili malkonektita. Solvilo, kiu funkcias nur dum ambaŭ tuneloj estas levitaj, estas dezajno, kiu surprizos iun en la plej malbona ebla momento.

Enkonduku en fiksa ordo kaj inspektu intere

Aktivigu unu profilon, inspektu ĝian itineran kaj solvilan staton, poste aktivigu la duan kaj inspektu denove. Kompari la du statojn diras al vi, kio ŝanĝiĝis kaj kiu profilo posedas kion. Ne aktivigu ambaŭ kaj poste diagnozu la rezulton.

Testu ĉiun bezonatan rimedon tra la tunelo, kiu devus porti ĝin, poste malkonektu unu profilon kaj konfirmu, ke la alia konservas siajn itinerojn, sian DNS kaj sian celitan malsukcesan konduton. Se la deplojita kromaĵo vere ne povas fari tion, kion vi bezonas, elektu subtenatan ĝisdatigon aŭ eksplicite izolitan alternativon anstataŭ revivigi eksvalidiĝintan protokolon apud la administrilo. Dua, aparta tunelo, kiun neniu administras, ne estas izolado; ĝi estas alia fonto de surprizaj itineroj.