Bedrijfs-VPN binnen WireGuard: welke laag komt eerst?
Twee clients op één machine werken alleen als de buitenste tunnel de eigen verbinding van de binnenste client draagt en metriek de juiste interface per prefix kiest.
Er zijn twee legitieme redenen om tunnels op een ontwikkelaarslaptop te nesten. Ofwel moet de bedrijfsclient lijken te komen uit een bepaald land, ofwel moeten twee particuliere netwerken tegelijk bereikbaar zijn. Beide gevallen vereisen dat de buitenste tunnel de eigen verbinding van de binnenste client draagt.
Twee clients in een of andere volgorde starten levert dat niet op. De routing levert dat op.
Vergelijk de twee mogelijke volgorden
Kies de buitenste laag als de tunnel waarvan het eindpunt vanaf het openbare internet bereikbaar is. De binnenste laag is de tunnel waarvan de server alleen via die uitgang antwoordt. Op Windows is de praktische verdeling WireGuard buiten en de bedrijfsclient binnen. De beslissende factor is controle.
De officiële WireGuard-client past een volledig configuratiebestand toe, inclusief routes en DNS. Commerciële bedrijfsclients verbergen meestal beide. Een verborgen client buiten zetten laat je raden naar het pad eronder.
De omgekeerde volgorde is niet onmogelijk. Het is alleen lastiger beredeneren, omdat de buitenste client routes herschrijft volgens een schema dat je nooit ziet.
Laat AllowedIPs alleen het bedrijfsbereik benoemen
AllowedIPs somt de bestemmingen op die WireGuard de tunnel in routeert. Voor nesting heeft het alleen het adres van de binnenste server en de bedrijfsprefixen nodig. Al het overige blijft op het lokale netwerk, printers en hypervisor inbegrepen. Dat is een gesplitste tunnel naar ontwerp, en het vermijdt het uitsluitingsprobleem volledig.
Een buitenste laag met volledige tunnel heeft 0.0.0.0/0 min de lokale bereiken nodig. Het formaat kan geen uitsluiting uitdrukken, dus het complement moet worden berekend en geplakt.
[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
Wanneer de binnenste client zijn eigen routes niet installeert, som dan zelf de bedrijfsprefixen op. Een prefix die op die regel ontbreekt, is een bestemming die de buitenste tunnel nooit draagt. Een verouderde kopie van de lijst is erger dan geen, omdat hij er nog steeds correct uitziet.
Volgorde, metriek en de tweede adapter
Verbind eerst de buitenste tunnel en start dan de bedrijfsclient. De verbinding met het eindpunt gaat dan via WireGuard naar buiten in plaats van via de lokale gateway. Geef de bedrijfsinterface een lagere metriek zodat de prefixen winnen voor de adressen die hij bezit.
# 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
Metriek is de stap die mensen overslaan. Zonder ordening wint de route die het laatst is geïnstalleerd voor de overlappende prefix. Dat verandert tussen opstarten, waardoor het probleem onregelmatig lijkt.
Clients gebouwd op OpenVPN 2.6 voegen hun eigen valstrik toe. Wanneer de adapter voor het offloaden van het datakanaal al bezet is, weigert een tweede instantie simpelweg te starten. Door disable-dco aan het profiel toe te voegen valt het terug op het oudere TAP-pad, en dan draaien beide naast elkaar.
Waar het geneste pad breekt
De buitenste tunnel verbreken doodt de binnenste. Alleen de binnenste client opnieuw verbinden stuurt hem vaak rechtstreeks naar het internet en verwijdert stil de nesting. Test de volgorde elke keer vanaf nul, met beide tunnels gestopt.
Verwacht een kleinere bruikbare MTU. Elke laag voegt overhead toe, dus een startpaar rond 1420 en 1400 is een punt om te beginnen. Een overdracht die blijft hangen bij grote pakketten terwijl kleine verzoeken slagen, is het gebruikelijke teken. Het bedrijfsbeleid is de andere grens, want een client die een beheerd apparaat eist, kan een genest pad als een schending zien.
Wanneer beide uiteinden vaste netwerken zijn, verwijdert een site-naar-site-tunnel tussen de gateways het ordeningsprobleem in plaats van het te beheren. Op één laptop bestaan twee tunnels alleen naast elkaar als elk zijn eigen interface heeft en een regel die bestemmingen per prefix selecteert.