Bedrifts-VPN inne i WireGuard: hvilket lag kommer først?

Det finnes to legitime grunner til å neste tunneler på en utviklerbærbar. Enten må bedriftsklienten se ut som den kommer fra et bestemt land, eller to private nettverk må være tilgjengelige samtidig. Begge tilfellene krever at den ytre tunnelen bærer den indre klientens egen tilkobling.

Å starte to klienter i en eller annen rekkefølge gir ikke det. Rutingen gir det.

Sammenlign de to mulige rekkefølgene

Velg det ytre laget som tunnelen der endepunktet kan nås fra det offentlige internettet. Det indre laget er tunnelen der serveren bare svarer gjennom den utgangen. På Windows er den praktiske delingen WireGuard utenfor og bedriftsklienten innenfor. Den avgjørende faktoren er kontroll.

Den offisielle WireGuard-klienten anvender en fullstendig konfigurasjonsfil, inkludert ruter og DNS. Kommersielle bedriftsklienter skjuler vanligvis begge. Setter man en skjult klient utenfor, blir man stående å gjette på veien under.

Den motsatte rekkefølgen er ikke umulig. Den er bare vanskeligere å resonnere om, fordi den ytre klienten skriver om ruter etter en tidsplan du aldri ser.

La AllowedIPs bare navngi bedriftsområdet

AllowedIPs lister opp destinasjonene som WireGuard ruter inn i tunnelen. For nesting trenger den bare adressen til den indre serveren og bedriftsprefiksene. Alt annet blir på det lokale nettet, inkludert skrivere og hypervisor. Dette er en delt tunnel av design, og den unngår utelukkelsesproblemet helt.

Et ytre lag med full tunnel trenger 0.0.0.0/0 minus de lokale områdene. Formatet kan ikke uttrykke en utelukkelse, så komplementet må beregnes og limes inn.

[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 indre klienten ikke installerer sine egne ruter, lister du opp bedriftsprefiksene selv. Et prefiks som mangler på den linjen, er en destinasjon som den ytre tunnelen aldri bærer. En utdatert kopi av listen er verre enn ingen, fordi den fortsatt ser riktig ut.

Rekkefølge, metrikker og den andre adapteren

Koble til den ytre tunnelen først, og start deretter bedriftsklienten. Da går endepunktstilkoblingen dens ut gjennom WireGuard i stedet for den lokale gatewayen. Gi bedriftsgrensesnittet lavere metrikk slik at prefiksene vinner for adressene det eier.

# 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

Metrikker er trinnet folk hopper over. Uten en rekkefølge vinner ruten som ble installert sist for det overlappende prefikset. Det endrer seg mellom oppstarter, og derfor virker problemet periodisk.

Klienter bygget på OpenVPN 2.6 legger til sin egen felle. Når adapteren for avlasting av datakanalen allerede er opptatt, nekter en andre instans rett og slett å starte. Å legge til disable-dco i profilen faller tilbake til den eldre TAP-veien, og da kjører begge side om side.

Hvor den nestede veien bryter sammen

Kobler du fra den ytre tunnelen, dør den indre. Å koble til bare den indre klienten igjen sender den ofte rett ut på internett og fjerner nesting i stillhet. Test sekvensen fra bunnen hver gang, med begge tunnelene stoppet.

Forvent en mindre brukbar MTU. Hvert lag legger til overhead, så et startpar rundt 1420 og 1400 er et sted å begynne. En overføring som henger på store pakker mens små forespørsler lykkes, er det vanlige tegnet. Bedriftspolicy er den andre grensen, fordi en klient som krever en administrert enhet kan se en nestet vei som et brudd.

Når begge ender er faste nettverk, fjerner en nettsted-til-nettsted-tunnel mellom gatewayene rekkefølgeproblemet i stedet for å administrere det. På én bærbar kan to tunneler bare eksistere samtidig når hver har sitt eget grensesnitt og en regel som velger destinasjoner per prefiks.