Pot aquest connector de NetworkManager executar dos VPN alhora?

A la llista de connexions hi ha dues entrades VPN, totes dues diuen que estan connectades i només una porta el trànsit que esperàveu. O la segona es nega a arrencar i ningú no pot dir si el problema és el connector, el client o una política que heu oblidat. Les afirmacions sobre un límit d'una sola VPN descriuen implementacions concretes, i les implementacions difereixen. Primer comproveu la capacitat i després la coordinació.

Compteu els perfils desats i, després, les activacions

Un perfil desat és un objecte de configuració i una connexió activa és una instància en execució. La llista barreja visualment els dos conceptes, i per això tots dos informes sonen certs. Comenceu anomenant els objectes exactes amb els seus UUID, perquè el nom mostrat no és únic i una importació antiga sovint comparteix etiqueta amb una entrada més nova. Després mireu la llista d'actius per separat i vegeu quins UUID hi apareixen. Només llavors sabreu si compareu dues configuracions o dos túnels vius.

Activar dues vegades el mateix UUID és un tercer cas i no és concurrència. És una reactivació d'una sola instància.

Llegiu les metadades pròpies del connector

Cada connector VPN inclou un petit fitxer de metadades que el gestor llegeix, i aquests fitxers poden declarar si el connector admet diverses connexions alhora. Llegiu el fitxer instal·lat en aquesta màquina en lloc de repetir el que escriu ara el projecte original, perquè el paquet de la distribució decideix què teniu realment. La mateixa comprovació val per a cada protocol: una resposta per a un connector no diu res sobre un altre. Anoteu la versió del paquet al costat del resultat, perquè una comparació posterior signifiqui alguna cosa.

Els consells antics sobre un límit d'una sola VPN descrivien integracions més antigues. No és ni permanentment cert ni segur donar-ho per fix, i el fitxer que teniu davant ho resol localment.

Concurrent no vol dir coordinat

Que dos connectors arrenquin correctament demostra la capacitat, no el disseny. Dos túnels que ofereixen una ruta per defecte competiran, i el qui va instal·lar la seva ruta més tard sol guanyar sense anunciar-ho. Els rangs privats solapats tenen el mateix problema en una forma més petita.

Decidiu quines destinacions pertanyen a cada perfil abans d'activar res. Canviar el nom d'un perfil no distingeix les destinacions.

El DNS tria un guanyador tant si ho voleu com si no

La configuració del resolutor és per perfil, i quan n'hi ha dos d'actius l'ordre de resolució el decideixen la política i la prioritat, no la intenció. El perfil que va pujar més tard pot posseir en silenci tots els noms corporatius.

Assigneu cada espai de noms privat al resolutor que li ha de respondre i fixeu la preferència d'encaminament deliberadament en lloc de confiar en l'ordre. Després proveu un nom de cada espai amb els dos túnels aixecats, i de nou amb un d'ells desconnectat. Un resolutor que només funciona mentre tots dos túnels són amunt és un disseny que sorprendrà algú en el pitjor moment possible.

Desplegueu en un ordre fix i inspeccioneu entre passos

Activeu un perfil, reviseu l'estat de les seves rutes i del resolutor, després activeu el segon i torneu a revisar. Comparar els dos estats us diu què ha canviat i quin perfil posseeix què. No activeu tots dos i després diagnostiqueu el resultat.

Proveu cada recurs necessari a través del túnel que l'ha de portar, després desconnecteu un perfil i confirmeu que l'altre conserva les seves rutes, el seu DNS i el seu comportament de fallada previst. Si el connector desplegat de debò no pot fer el que necessiteu, trieu una actualització suportada o una alternativa explícitament aïllada en lloc de revifar un protocol obsolet al costat del gestor. Un segon túnel separat que ningú no gestiona no és aïllament; és una altra font de rutes sorprenents.