Firemný VPN vnútri WireGuardu: ktorá vrstva ide prvá?

Dvaja klienti na jednom počítači fungujú len vtedy, keď vonkajší tunel nesie vlastné pripojenie vnútorného klienta a metriky vyberajú správne rozhranie pre každý prefix.

Pre vnorovanie tunelov na vývojárskom notebooku existujú dva opodstatnené dôvody. Buď sa firemný klient musí tváriť, že prichádza z konkrétnej krajiny, alebo musia byť súčasne dostupné dve súkromné siete. V oboch prípadoch musí vonkajší tunel niesť vlastné pripojenie vnútorného klienta.

Spustenie dvoch klientov v ľubovoľnom poradí to nezaistí. Zaistí to smerovanie.

Porovnajte dve možné poradia

Zvoľte vonkajšiu vrstvu ako tunel, ktorého koncový bod je dostupný z verejného internetu. Vnútorná vrstva je tunel, ktorého server odpovedá len cez tento výstup. Na Windows je praktické rozdelenie WireGuard vonku a firemný klient vnútri. Rozhodujúcim faktorom je kontrola.

Oficiálny klient WireGuard aplikuje celý konfiguračný súbor vrátane trás a DNS. Komerčné firemné klienty zvyčajne skrývajú oboje. Keď skrytého klienta postavíte von, zostáva vám len hádať, aká cesta vedie pod ním.

Opačné poradie nie je nemožné. Len sa o ňom ťažšie uvažuje, pretože vonkajší klient prepisuje trasy podľa plánu, ktorý nikdy nevidíte.

Nech AllowedIPs pomenuje len firemný rozsah

AllowedIPs vypisuje ciele, ktoré WireGuard smeruje do tunela. Na vnorenie potrebuje len adresu vnútorného servera a firemné prefixy. Všetko ostatné zostáva v lokálnej sieti vrátane tlačiarní a hypervizora. To je split tunel už z princípu a úplne sa vyhýba problému s vylúčením.

Vonkajšia vrstva s plným tunelom potrebuje 0.0.0.0/0 mínus lokálne rozsahy. Formát nevie vyjadriť vylúčenie, takže doplnok sa musí vypočítať a vložiť ručne.

[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

Keď vnútorný klient neinštaluje vlastné trasy, vypíšte firemné prefixy sami. Prefix vynechaný na tom riadku je cieľ, ktorý vonkajší tunel nikdy nenesie. Zastaraná kópia zoznamu je horšia ako žiadna, pretože stále vyzerá správne.

Poradie, metriky a druhý adaptér

Najprv pripojte vonkajší tunel, potom spustite firemného klienta. Jeho pripojenie ku koncovému bodu potom vychádza cez WireGuard namiesto lokálnej brány. Dajte firemnému rozhraniu nižšiu metriku, aby jeho prefixy vyhrali pre adresy, ktoré 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 sú krok, ktorý ľudia preskakujú. Bez poradia pre prekrývajúci sa prefix vyhrá trasa nainštalovaná naposledy. To sa medzi štartmi mení, a preto problém vyzerá občasne.

Klienti postavené na OpenVPN 2.6 pridávajú vlastnú pascu. Keď je adaptér na odľahčenie dátového kanála už obsadený, druhá inštancia jednoducho odmietne naštartovať. Pridanie disable-dco do profilu sa vráti k staršej ceste TAP a potom obidva bežia vedľa seba.

Kde sa vnorená cesta láme

Odpojenie vonkajšieho tunela zabije vnútorný. Opätovné pripojenie len vnútorného klienta ho často pošle priamo na internet a ticho odstráni vnorenie. Testujte postupnosť vždy od nuly, so zastavenými oboma tunelmi.

Očakávajte menšiu použiteľnú MTU. Každá vrstva pridáva réžiu, takže počiatočný pár okolo 1420 a 1400 je miesto, kde začať. Prenos, ktorý sa zasekne na veľkých paketoch, zatiaľ čo malé požiadavky prechádzajú, je obvyklý príznak. Firemná politika je druhá hranica, pretože klient, ktorý chce spravované zariadenie, môže vnorenú cestu považovať za porušenie.

Keď sú oba konce pevné siete, tunel medzi bránami typu site-to-site problém s poradím odstráni, namiesto toho, aby ho riadil. Na jednom notebooku dva tunely koexistujú len vtedy, keď má každý svoje rozhranie a pravidlo, ktoré vyberá ciele podľa prefixu.

Súvisiace články