Firemní VPN uvnitř WireGuardu: která vrstva jde první?

Pro vnořování tunelů na vývojářském notebooku existují dva oprávněné důvody. Buď se firemní klient musí tvářit, že přichází z konkrétní země, nebo musí být současně dostupné dvě privátní sítě. V obou případech musí vnější tunel nést vlastní připojení vnitřního klienta.

Spuštění dvou klientů v libovolném pořadí to nezařídí. Zařídí to směrování.

Porovnejte dvě možná pořadí

Zvolte vnější vrstvu jako tunel, jehož koncový bod je dostupný z veřejného internetu. Vnitřní vrstva je tunel, jehož server odpovídá jen přes tento výstup. Na Windows je praktické rozdělení WireGuard venku a firemní klient uvnitř. Rozhodujícím faktorem je kontrola.

Oficiální klient WireGuard aplikuje celý konfigurační soubor včetně tras a DNS. Komerční firemní klienti obvykle skrývají obojí. Když skrytého klienta postavíte ven, zůstane vám jen hádat, jaká cesta vede pod ním.

Opačné pořadí není nemožné. Jen se o něm hůř uvažuje, protože vnější klient přepisuje trasy podle plánu, který nikdy nevidíte.

Ať AllowedIPs pojmenuje jen firemní rozsah

AllowedIPs vypisuje cíle, které WireGuard směruje do tunelu. Pro vnoření potřebuje jen adresu vnitřního serveru a firemní prefixy. Všechno ostatní zůstává v lokální síti, včetně tiskáren a hypervizoru. To je split tunel už z principu a zcela se vyhýbá problému s vyloučením.

Vnější vrstva s plným tunelem potřebuje 0.0.0.0/0 minus lokální rozsahy. Formát neumí vyjádřit vyloučení, takže doplněk se musí spočítat a vložit ručně.

[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

Když vnitřní klient neinstaluje vlastní trasy, vypište firemní prefixy sami. Prefix vynechaný na tom řádku je cíl, který vnější tunel nikdy nenese. Zastaralá kopie seznamu je horší než žádná, protože pořád vypadá správně.

Pořadí, metriky a druhý adaptér

Nejprve připojte vnější tunel, potom spusťte firemního klienta. Jeho připojení ke koncovému bodu pak vychází přes WireGuard místo přes lokální bránu. Dejte firemnímu rozhraní nižší metriku, aby jeho prefixy vyhrály pro adresy, které vlastní.

# 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

Metriky jsou krok, který lidé přeskakují. Bez pořadí pro překrývající se prefix vyhraje trasa nainstalovaná naposledy. To se mezi starty mění, a proto problém vypadá občasně.

Klienti postavení na OpenVPN 2.6 přidávají vlastní past. Když je adaptér pro odlehčení datového kanálu už obsazený, druhá instance prostě odmítne nastartovat. Přidání disable-dco do profilu se vrátí ke starší cestě TAP a pak oba běží vedle sebe.

Kde se vnořená cesta láme

Odpojení vnějšího tunelu zabije vnitřní. Opětovné připojení jen vnitřního klienta ho často pošle přímo na internet a tiše odstraní vnoření. Testujte posloupnost pokaždé od nuly, se zastavenými oběma tunely.

Očekávejte menší použitelnou MTU. Každá vrstva přidává režii, takže počáteční pár kolem 1420 a 1400 je místo, kde začít. Přenos, který se zasekne na velkých paketech, zatímco malé požadavky procházejí, je obvyklý příznak. Firemní politika je druhá hranice, protože klient, který chce spravované zařízení, může vnořenou cestu považovat za porušení.

Když jsou oba konce pevné sítě, tunel mezi branami typu site-to-site problém s pořadím odstraní, místo aby ho řídil. Na jednom notebooku dva tunely koexistují jen tehdy, když má každý své rozhraní a pravidlo, které vybírá cíle podle prefixu.