Kan dette NetworkManager-plugin køre to VPN'er samtidig?

To VPN-poster står i forbindelseslisten, begge siger forbundet, og kun den ene bærer den trafik, du forventede. Eller også nægter den anden at starte, og ingen kan sige, om det er plugin'et, klienten eller en politik, du glemte. Påstande om en grænse på én VPN beskriver bestemte implementeringer, og implementeringer er forskellige. Gå kapaciteten igennem først, derefter koordineringen.

Tæl gemte profiler, derefter aktiveringer

En gemt profil er et konfigurationsobjekt, og en aktiv forbindelse er en kørende instans. Listen smelter de to begreber sammen visuelt, og derfor lyder begge rapporter sande. Begynd med at navngive de præcise objekter med deres UUID'er, fordi visningsnavnet ikke er unikt, og en gammel import deler ofte et mærke med en nyere post. Kontrollér derefter den aktive liste særskilt og se, hvilke UUID'er der optræder. Først da ved du, om du sammenligner to konfigurationer eller to levende tunneller.

At aktivere samme UUID to gange er et tredje tilfælde og ikke samtidighed. Det er en reaktivering af én instans.

Læs pluginets egne metadata

Hvert VPN-plugin leverer en lille metadatafil, som manageren læser, og de filer kan erklære, om plugin'et understøtter flere forbindelser på én gang. Læs den fil, der er installeret på denne maskine, i stedet for at gentage, hvad et upstream-projekt skriver lige nu, fordi distributionspakken afgør, hvad du faktisk har. Den samme kontrol gælder pr. protokol: et svar for ét plugin siger intet om et andet. Notér pakkeversionen sammen med resultatet, så en senere sammenligning betyder noget.

Gamle råd om en grænse på én VPN beskrev ældre integrationer. Det er hverken evigt sandt eller sikkert at antage som fast, og filen foran dig afgør det lokalt.

Samtidig er ikke koordineret

At to plugins starter med succes beviser kapaciteten, ikke designet. To tunneller, der begge tilbyder en standardrute, vil konkurrere, og den, der installerede sin rute sidst, vinder normalt uden at meddele det. Overlappende private områder har samme problem i mindre målestok.

Beslut, hvilke destinationer der hører til hvilken profil, før du aktiverer noget. At omdøbe en profil adskiller ikke destinationerne.

DNS vælger en vinder, uanset om du gør

Resolverindstillinger er pr. profil, og når to er aktive, afgøres opløsningsrækkefølgen af politik og prioritet frem for af hensigt. Profilen, der kom op sidst, kan stille eje hvert eneste virksomhedsnavn.

Tildel hvert privat navnerum til den resolver, der skal svare for det, og sæt rutepræference bevidst i stedet for at stole på rækkefølgen. Test derefter et navn fra hvert navnerum med begge tunneller oppe og igen med en af dem afbrudt. En resolver, der kun virker, mens begge tunneller er oppe, er et design, der vil overraske nogen på det værst tænkelige tidspunkt.

Udrul i fast rækkefølge og undersøg indimellem

Aktivér en profil, undersøg dens rute- og resolverstatus, aktivér derefter den anden og undersøg igen. At sammenligne de to tilstande fortæller dig, hvad der ændrede sig, og hvilken profil der ejer hvad. Aktivér ikke begge og diagnosticér så resultatet.

Test hver nødvendig ressource gennem den tunnell, der skal bære den, afbryd derefter en profil og bekræft, at den anden beholder sine ruter, sin DNS og sin tilsigtede fejladfærd. Hvis det udrullede plugin virkelig ikke kan gøre det, du har brug for, så vælg en understøttet opgradering eller et udtrykkeligt isoleret alternativ i stedet for at genoplive en forældet protokol ved siden af manageren. En anden, separat tunnell, som ingen administrerer, er ikke isolering; det er en anden kilde til overraskende ruter.