Firmowy VPN wewnątrz WireGuard: która warstwa idzie pierwsza?

Istnieją dwa uzasadnione powody zagnieżdżania tuneli na laptopie dewelopera. Albo klient firmowy musi wyglądać, jakby pochodził z określonego kraju, albo dwie sieci prywatne muszą być osiągalne jednocześnie. W obu przypadkach zewnętrzny tunel musi przenosić własne połączenie wewnętrznego klienta.

Uruchomienie dwóch klientów w dowolnej kolejności tego nie daje. Daje to routing.

Porównaj dwa możliwe porządki

Wybierz warstwę zewnętrzną jako tunel, którego punkt końcowy jest osiągalny z publicznego internetu. Warstwa wewnętrzna to tunel, którego serwer odpowiada tylko przez to wyjście. W Windows praktyczny podział to WireGuard na zewnątrz i klient firmowy w środku. Decydującym czynnikiem jest kontrola.

Oficjalny klient WireGuard stosuje pełny plik konfiguracyjny, wraz z trasami i DNS. Komercyjne klienty firmowe zwykle ukrywają jedno i drugie. Umieszczenie ukrytego klienta na zewnątrz zostawia cię ze zgadywaniem drogi pod spodem.

Odwrotna kolejność nie jest niemożliwa. Jest tylko trudniejsza do przemyślenia, bo klient zewnętrzny przepisuje trasy według harmonogramu, którego nigdy nie widzisz.

Pozwól, by AllowedIPs nazywał tylko zakres firmowy

AllowedIPs wymienia cele, które WireGuard kieruje do tunelu. Do zagnieżdżenia potrzebuje tylko adresu wewnętrznego serwera i prefiksów firmowych. Wszystko inne zostaje w sieci lokalnej, wraz z drukarkami i hipervisorem. To tunel dzielony z założenia i całkowicie unika problemu wykluczenia.

Zewnętrzna warstwa z pełnym tunelem potrzebuje 0.0.0.0/0 minus zakresy lokalne. Format nie potrafi wyrazić wykluczenia, więc dopełnienie trzeba obliczyć i wkleić.

[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

Gdy wewnętrzny klient nie instaluje własnych tras, wypisz prefiksy firmowe samodzielnie. Prefiks pominięty w tym wierszu to cel, którego zewnętrzny tunel nigdy nie przenosi. Nieaktualna kopia listy jest gorsza niż żadna, bo nadal wygląda poprawnie.

Kolejność, metryki i drugi adapter

Najpierw połącz tunel zewnętrzny, potem uruchom klienta firmowego. Wtedy jego połączenie z punktem końcowym wychodzi przez WireGuard, a nie przez lokalną bramę. Daj interfejsowi firmowemu niższą metrykę, aby jego prefiksy wygrywały dla adresów, które posiada.

# 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

Metryki to krok, który ludzie pomijają. Bez uporządkowania dla nakładającego się prefiksu wygrywa trasa zainstalowana ostatnia. To zmienia się między rozruchami, dlatego problem wygląda na przerywany.

Klienty zbudowane na OpenVPN 2.6 dodają własną pułapkę. Gdy adapter odciążenia kanału danych jest już zajęty, druga instancja po prostu odmawia startu. Dodanie disable-dco do profilu wraca do starszej ścieżki TAP i wtedy oba działają obok siebie.

Gdzie łamie się zagnieżdżona ścieżka

Rozłączenie tunelu zewnętrznego zabija wewnętrzny. Ponowne połączenie tylko klienta wewnętrznego często wysyła go prosto do internetu i po cichu usuwa zagnieżdżenie. Testuj sekwencję od zera za każdym razem, przy obu tunelach zatrzymanych.

Spodziewaj się mniejszego użytecznego MTU. Każda warstwa dodaje narzut, więc para startowa około 1420 i 1400 to miejsce, od którego można zacząć. Transfer, który zawiesza się na dużych pakietach, gdy małe żądania przechodzą, to zwykły objaw. Polityka firmowa to druga granica, bo klient wymagający zarządzanego urządzenia może uznać zagnieżdżoną ścieżkę za naruszenie.

Gdy oba końce to sieci stałe, tunel lokacja-lokacja między bramami usuwa problem kolejności zamiast nim zarządzać. Na jednym laptopie dwa tunele współistnieją tylko wtedy, gdy każdy ma własny interfejs i regułę wybierającą cele według prefiksu.