Bedrifts-VPN inne i WireGuard: kva lag kjem først?

Det finst to legitime grunnar til å nesta tunnelar på ein utviklarbærbar. Anten må bedriftsklienten sjå ut som han kjem frå eit bestemt land, eller to private nettverk må vere tilgjengelege samtidig. Begge tilfella krev at den ytre tunnelen ber den indre klienten si eiga tilkopling.

Å starte to klientar i ein eller annan rekkjefølgje gjev ikkje det. Ruttinga gjev det.

Samanlikn dei to moglege rekkjefølgjene

Vel det ytre laget som tunnelen der endepunktet kan nåast frå det offentlege internettet. Det indre laget er tunnelen der tenaren berre svarar gjennom den utgangen. På Windows er den praktiske delinga WireGuard utanfor og bedriftsklienten innanfor. Den avgjerande faktoren er kontroll.

Den offisielle WireGuard-klienten nyttar ei fullstendig konfigurasjonsfil, inkludert ruter og DNS. Kommersielle bedriftsklientar skjuler vanlegvis begge. Set du ein skjult klient utanfor, blir du ståande å gjette på vegen under.

Den motsette rekkjefølgja er ikkje umogleg. Ho er berre vanskelegare å resonnere om, fordi den ytre klienten skriv om ruter etter ein tidsplan du aldri ser.

Lat AllowedIPs berre namngje bedriftsområdet

AllowedIPs listar opp destinasjonane som WireGuard rutar inn i tunnelen. For nesting treng han berre adressa til den indre tenaren og bedriftsprefiksa. Alt anna blir på det lokale nettet, inkludert skrivarar og hypervisor. Dette er ein delt tunnel av design, og han unngår utelukkingproblemet heilt.

Eit ytre lag med full tunnel treng 0.0.0.0/0 minus dei lokale områda. Formatet kan ikkje uttrykkje ei utelukking, så komplementet må reknast ut og limast 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 ikkje installerer sine eigne ruter, listar du opp bedriftsprefiksa sjølv. Eit prefiks som manglar på den lina, er ein destinasjon som den ytre tunnelen aldri ber. Ein utdatert kopi av lista er verre enn ingen, fordi han framleis ser rett ut.

Rekkjefølgje, metrikkar og den andre adapteren

Kopla til den ytre tunnelen først, og start deretter bedriftsklienten. Då går endepunktstilkoplinga hans ut gjennom WireGuard i staden for den lokale gatewayen. Gje bedriftsgrensesnittet lågare metrikk slik at prefiksa vinn for adressene det eig.

# 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

Metrikkar er trinnet folk hoppar over. Utan ei rekkjefølgje vinn ruta som vart installert sist for det overlappande prefikset. Det endrar seg mellom oppstartar, og difor verkar problemet periodisk.

Klientar bygde på OpenVPN 2.6 legg til si eiga felle. Når adapteren for avlasting av datakanalen allereie er oppteken, nektar ein andre instans rett og slett å starte. Å leggje til disable-dco i profilen fell tilbake til den eldre TAP-vegen, og då køyrer begge side om side.

Kvar den nesta vegen bryt saman

Koplar du frå den ytre tunnelen, døyr den indre. Å kople til berre den indre klienten igjen sender han ofte rett ut på internett og fjernar nesting i det stille. Test sekvensen frå botnen kvar gong, med begge tunnelane stoppa.

Rekn med ein mindre brukbar MTU. Kvart lag legg til overhead, så eit startpar rundt 1420 og 1400 er ein stad å byrje. Ei overføring som heng på store pakkar medan små førespurnader lukkast, er det vanlege teiknet. Bedriftspolicy er den andre grensa, fordi ein klient som krev ei administrert eining kan sjå ein nesta veg som eit brot.

Når begge endar er faste nettverk, fjernar ein nettstad-til-nettstad-tunnel mellom gatewayane rekkjefølgjeproblemet i staden for å administrere det. På éin bærbar kan to tunnelar berre eksistere samtidig når kvar har sitt eige grensesnitt og ein regel som vel destinasjonar per prefiks.