Företags-VPN inuti WireGuard: vilket lager kommer först?

Det finns två legitima skäl att nästla tunnlar på en utvecklardator. Antingen måste företagsklienten se ut att komma från ett visst land, eller så måste två privata nätverk vara nåbara samtidigt. Båda fallen kräver att den yttre tunneln bär den inre klientens egen anslutning.

Att starta två klienter i någon ordning ger inte det. Det är routingen som ger det.

Jämför de två möjliga ordningarna

Välj det yttre lagret som den tunnel vars ändpunkt går att nå från det publika internet. Det inre lagret är tunneln vars server bara svarar genom den utgången. I Windows är den praktiska uppdelningen WireGuard utanför och företagsklienten innanför. Den avgörande faktorn är kontroll.

Den officiella WireGuard-klienten tillämpar en fullständig konfigurationsfil, inklusive rutter och DNS. Kommersiella företagsklienter döljer vanligtvis båda. Att sätta en dold klient utanför lämnar dig att gissa vägen under den.

Den omvända ordningen är inte omöjlig. Den är bara svårare att resonera om, eftersom den yttre klienten skriver om rutter enligt ett schema du aldrig ser.

Låt AllowedIPs bara namnge företagsintervallet

AllowedIPs listar de destinationer som WireGuard routar in i tunneln. För nästling behöver den bara den inre serverns adress och företagets prefix. Allt annat stannar på det lokala nätet, inklusive skrivare och hypervisor. Det är en delad tunnel av design, och den undviker uteslutningsproblemet helt.

Ett yttre lager med full tunnel behöver 0.0.0.0/0 minus de lokala intervallen. Formatet kan inte uttrycka en uteslutning, så komplementet måste beräknas och klistras in.

[Interface]
PrivateKey = ...
Address = 10.99.4.2/32

[Peer]
PublicKey = ...
Endpoint = 198.51.100.44:51820
AllowedIPs = 198.51.100.44/32, 10.20.0.0/16, 10.21.0.0/16

När den inre klienten inte installerar sina egna rutter listar du företagets prefix själv. Ett prefix som saknas på den raden är en destination som den yttre tunneln aldrig bär. En föråldrad kopia av listan är värre än ingen, eftersom den fortfarande ser korrekt ut.

Ordning, metrik och den andra adaptern

Anslut den yttre tunneln först och starta sedan företagsklienten. Då går dess ändpunktsanslutning ut genom WireGuard i stället för den lokala gatewayen. Ge företagsgränssnittet lägre metrik så att dess prefix vinner för de adresser det äger.

# which interface currently claims the corporate prefix?
Find-NetRoute -RemoteIPAddress 10.20.10.5 | Select-Object -First 1

# prefer the corporate interface for its own prefixes
Set-NetIPInterface -InterfaceAlias 'Corp VPN' -InterfaceMetric 3
Set-NetIPInterface -InterfaceAlias 'wg-personal' -InterfaceMetric 40

wg show interfaces

Metrik är steget folk hoppar över. Utan en ordning vinner rutten som installerades sist för det överlappande prefixet. Det ändras mellan starter, och därför verkar problemet periodiskt.

Klienter byggda på OpenVPN 2.6 lägger till sin egen fälla. När adaptern för avlastning av datakanalen redan är upptagen vägrar en andra instans helt enkelt att starta. Att lägga till disable-dco i profilen faller tillbaka på den äldre TAP-vägen, och då kör båda sida vid sida.

Var den nästlade vägen bryts

Kopplar du från den yttre tunneln dör den inre. Att bara återansluta den inre klienten skickar den ofta rakt ut på internet och tar tyst bort nästlingen. Testa sekvensen från början varje gång, med båda tunnlarna stoppade.

Räkna med en mindre användbar MTU. Varje lager lägger till overhead, så ett startpar runt 1420 och 1400 är en plats att börja på. En överföring som hänger sig på stora paket medan små förfrågningar lyckas är det vanliga tecknet. Företagspolicyn är den andra gränsen, eftersom en klient som kräver en hanterad enhet kan se en nästlad väg som ett brott.

När båda ändarna är fasta nätverk tar en plats-till-plats-tunnel mellan gatewayerna bort ordningsproblemet i stället för att hantera det. På en enda bärbar dator kan två tunnlar bara finnas samtidigt när var och en har sitt eget gränssnitt och en regel som väljer destinationer per prefix.