Der er to rimelige grunde til at indlejre tunneler på en udviklerbærbar. Enten skal virksomhedsklienten se ud som om den kommer fra et bestemt land, eller også skal to private netværk kunne nås samtidigt. Begge tilfælde kræver, at den ydre tunnel bærer den indre klients egen forbindelse.

At starte to klienter i en eller anden rækkefølge giver ikke det. Det er routing, der gør det.

Sammenlign de to mulige rækkefølger

Vælg det ydre lag som den tunnel, hvis endepunkt det offentlige internet kan nå. Det indre lag er den tunnel, hvis server kun svarer gennem den udgang. På Windows er den praktiske opdeling WireGuard udenfor og virksomhedsklienten indeni. Den afgørende faktor er kontrol.

Den officielle WireGuard-klient anvender en komplet konfigurationsfil, inklusive ruter og DNS. Kommercielle virksomhedsklienter skjuler normalt begge dele. Sætter man en skjult klient udenfor, står man tilbage og gætter på vejen nedenunder.

Den omvendte rækkefølge er ikke umulig. Den er sværere at ræsonnere om, fordi den ydre klient omskriver ruter efter en tidsplan, du aldrig ser.

Lad AllowedIPs kun navngive virksomhedsområdet

AllowedIPs oplister de destinationer, som WireGuard sender ind i tunnelen. Til indlejring har den kun brug for den indre servers adresse og virksomhedens præfikser. Alt andet bliver på det lokale netværk, inklusive printere og hypervisor. Det er en splittunnel af design, og den undgår helt udelukkelsesproblemet.

Et ydre lag med full tunnel har brug for 0.0.0.0/0 minus de lokale områder. Formatet kan ikke udtrykke en udelukkelse, så komplementet skal beregnes og indsættes.

[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 klient ikke installerer sine egne ruter, skal du selv angive virksomhedens præfikser. Et præfiks, der mangler på den linje, er en destination, som den ydre tunnel aldrig bærer. En forældet kopi af listen er værre end ingen, fordi den stadig ser rigtig ud.

Rækkefølge, metrikker og den anden adapter

Forbind den ydre tunnel først, og start derefter virksomhedsklienten. Dens endepunktsforbindelse går så ud gennem WireGuard i stedet for den lokale gateway. Giv virksomhedsgrænsefladen en lavere metrik, så dens præfikser vinder for de adresser, den ejer.

# 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 det trin, folk springer over. Uden en rækkefølge vinder den rute, der blev installeret sidst, for det overlappende præfiks. Det ændrer sig mellem opstarter, og derfor virker problemet periodisk.

Klienter bygget på OpenVPN 2.6 tilføjer deres egen fælde. Når adapteren til aflastning af datakanalen allerede er optaget, nægter en anden instans simpelthen at starte. Tilføjer man disable-dco til profilen, falder den tilbage til den ældre TAP-vej, og så kører begge side om side.

Hvor den indlejrede vej brækker

Afbrydes den ydre tunnel, dræbes den indre. Genoprettes kun den indre klient, sendes den ofte direkte ud på internettet og fjerner stille indlejringen. Test sekvensen fra bunden hver gang, med begge tunneler stoppet.

Forvent en mindre brugbar MTU. Hvert lag tilføjer overhead, så et startpar omkring 1420 og 1400 er et sted at begynde. En overførsel, der hænger på store pakker, mens små anmodninger lykkes, er det sædvanlige tegn. Virksomhedspolitik er den anden grænse, fordi en klient, der kræver en administreret enhed, kan betragte en indlejret vej som et brud.

Når begge ender er faste netværk, fjerner en site-til-site-tunnel mellem gateways rækkefølgeproblemet i stedet for at styre det. På én bærbar kan to tunneler kun eksistere samtidigt, når hver har sin egen grænseflade og en regel, der vælger destinationer pr. præfiks.

Relaterede artikler