Kan det här NetworkManager-tillägget köra två VPN samtidigt?

Två VPN-poster står i anslutningslistan, båda säger ansluten, och bara en av dem bär trafiken du förväntade dig. Eller så vägrar den andra starta helt, och ingen kan säga om det är tillägget, klienten eller en policy du glömt. Påståenden om en gräns på ett VPN beskriver särskilda implementationer, och implementationer skiljer sig. Gå igenom förmågan först, sedan samordningen.

Räkna sparade profiler, sedan aktiveringar

En sparad profil är ett konfigurationsobjekt, och en aktiv anslutning är en körande instans. Listan smälter samman de två begreppen visuellt, vilket är varför båda rapporterna låter sanna. Börja med att namnge de exakta objekten med deras UUID, eftersom visningsnamnet inte är unikt och en gammal import ofta delar en etikett med en nyare post. Kontrollera sedan den aktiva listan separat och se vilka UUID som dyker upp. Först då vet du om du jämför två konfigurationer eller två levande tunnlar.

Att aktivera samma UUID två gånger är ett tredje fall, och det är inte samtidighet. Det är en reaktivering av en enda instans.

Läs tilläggets egna metadata

Varje VPN-tillägg levererar en liten metadatafil som hanteraren läser, och dessa filer kan deklarera om tillägget stöder flera anslutningar samtidigt. Läs filen som är installerad på den här maskinen i stället för att upprepa vad ett upstream-projekt skriver just nu, eftersom distributionspaketet avgör vad du faktiskt har. Samma kontroll gäller per protokoll: ett svar för ett tillägg säger ingenting om ett annat. Anteckna paketversionen tillsammans med resultatet, så att en senare jämförelse betyder något.

Gamla råd om en gräns på ett VPN beskrev äldre integrationer. Det är varken evigt sant eller säkert att anta som fast, och filen framför dig avgör det lokalt.

Samtidig är inte samordnad

Att två tillägg startar framgångsrikt bevisar förmågan, inte designen. Två tunnlar som båda erbjuder en standardrutt kommer att konkurrera, och den som installerade sin rutt sist vinner vanligtvis utan att meddela det. Överlappande privata intervall har samma problem i mindre form.

Bestäm vilka destinationer som hör till vilken profil innan du aktiverar något. Att byta namn på en profil skiljer inte destinationerna.

DNS väljer en vinnare, oavsett om du gör det eller inte

Inställningarna för matcharen är per profil, och när två är aktiva avgörs ordningen av policy och prioritet snarare än av avsikt. Profilen som kom upp sist kan stilla äga varje företagsnamn.

Tilldela varje privat namnutrymme till den matchare som ska svara för det, och sätt routinginställningen medvetet i stället för att lita på ordningen. Testa sedan ett namn från varje utrymme med båda tunnlarna uppe, och igen med en av dem frånkopplad. En matchare som bara fungerar så länge båda tunnlarna är uppe är en design som kommer att överraska någon i värsta möjliga ögonblick.

Rulla ut i fast ordning och inspektera emellan

Aktivera en profil, inspektera dess rutt- och matcharstatus, aktivera sedan den andra och inspektera igen. Att jämföra de två tillstånden säger vad som ändrades och vilken profil som äger vad. Aktivera inte båda och diagnostisera sedan resultatet.

Testa varje nödvändig resurs genom tunneln som ska bära den, koppla sedan från en profil och bekräfta att den andra behåller sina rutter, sin DNS och sitt avsedda felbeteende. Om det utrullade tillägget verkligen inte kan göra det du behöver, välj en stödd uppgradering eller ett uttryckligen isolerat alternativ i stället för att återuppliva ett föråldrat protokoll bredvid hanteraren. En andra, separat tunnel som ingen administrerar är inte isolering; det är en annan källa till överraskande rutter.