Kan denne NetworkManager-utvidelsen kjøre to VPN-er samtidig?

To VPN-oppføringer står i tilkoblingslisten, begge sier tilkoblet, og bare én av dem bærer trafikken du forventet. Eller den andre nekter å starte i det hele tatt, og ingen kan si om det er utvidelsen, klienten eller en policy du glemte. Påstander om en grense på én VPN beskriver bestemte implementasjoner, og implementasjoner er forskjellige. Gå gjennom egenskapen først, deretter koordineringen.

Tell lagrede profiler, deretter aktiveringer

En lagret profil er et konfigurasjonsobjekt, og en aktiv tilkobling er en kjørende instans. Listen smelter de to begrepene sammen visuelt, og derfor høres begge rapportene riktige ut. Begynn med å navngi de nøyaktige objektene med UUID-ene deres, fordi visningsnavnet ikke er unikt og en gammel import ofte deler en etikett med en nyere oppføring. Sjekk deretter den aktive listen separat og se hvilke UUID-er som dukker opp. Først da vet du om du sammenligner to konfigurasjoner eller to levende tunneler.

Å aktivere samme UUID to ganger er et tredje tilfelle, og det er ikke samtidighet. Det er en reaktivering av én instans.

Les utvidelsens egne metadata

Hver VPN-utvidelse leverer en liten metadatafil som lederen leser, og disse filene kan erklære om utvidelsen støtter flere tilkoblinger samtidig. Les filen som er installert på denne maskinen i stedet for å gjenta det et upstream-prosjekt skriver akkurat nå, fordi distribusjonspakken avgjør hva du faktisk har. Den samme kontrollen gjelder per protokoll: et svar for én utvidelse sier ingenting om en annen. Noter pakkeversjonen sammen med resultatet, slik at en senere sammenligning betyr noe.

Gamle råd om en grense på én VPN beskrev eldre integrasjoner. Det er verken evig sant eller trygt å anta som fast, og filen foran deg avgjør det lokalt.

Samtidig er ikke koordinert

At to utvidelser starter med suksess beviser egenskapen, ikke designet. To tunneler som begge tilbyr en standardrute vil konkurrere, og den som installerte ruten sin sist vinner vanligvis uten å kunngjøre det. Overlappende private områder har samme problem i mindre form.

Bestem hvilke destinasjoner som hører til hvilken profil før du aktiverer noe. Å gi en profil nytt navn skiller ikke destinasjonene.

DNS velger en vinner, enten du gjør det eller ikke

Innstillingene for oppløseren er per profil, og når to er aktive, avgjøres rekkefølgen av policy og prioritet fremfor av hensikt. Profilen som kom opp sist kan stille eie hvert eneste bedriftsnavn.

Tildel hvert private navnerom til oppløseren som skal svare for det, og sett rutepreferansen bevisst i stedet for å stole på rekkefølgen. Test deretter et navn fra hvert navnerom med begge tunnelene oppe, og igjen med én av dem frakoblet. En oppløser som bare virker så lenge begge tunnelene er oppe, er et design som vil overraske noen på det verst tenkelige tidspunktet.

Rull ut i fast rekkefølge og undersøk imellom

Aktiver én profil, undersøk rute- og oppløserstatusen dens, aktiver deretter den andre og undersøk igjen. Å sammenligne de to tilstandene forteller deg hva som endret seg og hvilken profil som eier hva. Ikke aktiver begge og diagnostiser resultatet etterpå.

Test hver nødvendige ressurs gjennom tunnelen som skal bære den, koble deretter fra én profil og bekreft at den andre beholder rutene, DNS-en og den tiltenkte feilatferden sin. Hvis den utrullede utvidelsen virkelig ikke kan gjøre det du trenger, velg en støttet oppgradering eller et uttrykkelig isolert alternativ i stedet for å gjenopplive en utdatert protokoll ved siden av lederen. En andre, separat tunnel som ingen administrerer er ikke isolasjon; det er en annen kilde til overraskende ruter.