Poate acest plugin NetworkManager să ruleze două VPN-uri simultan?

În lista de conexiuni stau două intrări VPN, ambele spun conectat, și doar una dintre ele transportă traficul pe care îl așteptați. Sau a doua refuză complet să pornească, și nimeni nu poate spune dacă vina este a pluginului, a clientului sau a unei politici uitate. Afirmațiile despre o limită de un singur VPN descriu implementări anume, iar implementările diferă. Parcurgeți mai întâi capabilitatea, apoi coordonarea.

Numărați profilurile salvate, apoi activările

Un profil salvat este un obiect de configurare, iar o conexiune activă este o instanță în execuție. Lista contopește vizual cele două concepte, de aceea ambele rapoarte sună adevărat. Începeți prin a numi obiectele exacte cu UUID-urile lor, pentru că numele afișat nu este unic și un import vechi împarte adesea o etichetă cu o intrare mai nouă. Apoi verificați separat lista activelor și vedeți ce UUID-uri apar. Abia atunci știți dacă comparați două configurații sau două tuneluri vii.

Activarea aceluiași UUID de două ori este un al treilea caz și nu este concurență. Este o reactivare a unei singure instanțe.

Citiți metadatele proprii ale pluginului

Fiecare plugin VPN livrează un mic fișier de metadate pe care managerul îl citește, iar acele fișiere pot declara dacă pluginul suportă mai multe conexiuni simultan. Citiți fișierul instalat pe această mașină în loc să repetați ce scrie acum un proiect upstream, pentru că pachetul distribuției decide ce aveți de fapt. Aceeași verificare se aplică pentru fiecare protocol: un răspuns pentru un plugin nu spune nimic despre altul. Notați versiunea pachetului lângă rezultat, ca o comparație ulterioară să însemne ceva.

Sfaturile vechi despre o limită de un singur VPN descriau integrațiuni mai vechi. Nu este nici veșnic adevărat, nici sigur de presupus ca fix, iar fișierul din fața dumneavoastră lămurește asta local.

Concurrent nu înseamnă coordonat

Faptul că două pluginuri pornesc cu succes dovedește capabilitatea, nu proiectarea. Două tuneluri care oferă amândouă o rută implicită vor concura, iar cel care și-a instalat ruta ultimul câștigă de obicei fără să anunțe. Intervalele private suprapuse au aceeași problemă într-o formă mai mică.

Decideți ce destinații aparțin cărui profil înainte de a activa ceva. Redenumirea unui profil nu distinge destinațiile.

DNS alege un câștigător, fie că faceți asta, fie că nu

Setările resolverului sunt pe profil, iar când două sunt active, ordinea de rezolvare este decisă de politică și prioritate, nu de intenție. Profilul care a urcat ultimul poate deține în liniște fiecare nume corporativ.

Atribuiți fiecare spațiu de nume privat resolverului care ar trebui să răspundă pentru el și stabiliți preferința de rutare în mod deliberat, în loc să vă bazați pe ordine. Apoi testați un nume din fiecare spațiu cu ambele tuneluri sus, și din nou cu unul dintre ele deconectat. Un resolver care funcționează doar cât timp ambele tuneluri sunt sus este un proiect care va surprinde pe cineva în cel mai rău moment posibil.

Implementați într-o ordine fixă și inspectați între pași

Activați un profil, inspectați starea rutelor și a resolverului său, apoi activați al doilea și inspectați din nou. Compararea celor două stări vă spune ce s-a schimbat și ce profil deține ce. Nu le activați pe amândouă și apoi diagnosticați rezultatul.

Testați fiecare resursă necesară prin tunelul care ar trebui să o transporte, apoi deconectați un profil și confirmați că celălalt își păstrează rutele, DNS-ul și comportamentul de eșec prevăzut. Dacă pluginul implementat chiar nu poate face ce aveți nevoie, alegeți o actualizare acceptată sau o alternativă explicit izolată în loc să reînviați un protocol învechit lângă manager. Un al doilea tunel separat pe care nimeni nu îl administrează nu este izolare; este o altă sursă de rute surprinzătoare.