Ettevõtte VPN WireGuardi sees: milline kiht tuleb esimesena?

Arendaja sülearvutis tunnelite pesastamiseks on kaks mõjuvat põhjust. Kas ettevõtte klient peab näima, nagu tuleks ta kindlast riigist, või peavad kaks privaatset võrku olema korraga kättesaadavad. Mõlemal juhul peab välimine tunnel kandma sisemise kliendi enda ühendust.

Kahe kliendi käivitamine ükskõik millises järjekorras seda ei anna. Seda annab marsruutimine.

Võrrelge kahte võimalikku järjekorda

Valige välimiseks kihiks tunnel, mille lõpp-punkt on avalikust internetist kättesaadav. Sisemine kiht on tunnel, mille server vastab ainult selle väljapääsu kaudu. Windowsis on praktiline jaotus WireGuard väljas ja ettevõtte klient sees. Otsustav tegur on kontroll.

Ametlik WireGuardi klient rakendab täielikku konfiguratsioonifaili, sealhulgas marsruudid ja DNS. Kaubanduslikud ettevõtte kliendid varjavad tavaliselt mõlemat. Peidetud kliendi väljapoole panek jätab teid selle all oleva tee üle oletama.

Vastupidine järjekord ei ole võimatu. Selle üle on lihtsalt raskem mõelda, sest välimine klient kirjutab marsruute ümber ajakava järgi, mida te kunagi ei näe.

Las AllowedIPs nimetab ainult ettevõtte vahemikku

AllowedIPs loetleb sihtkohad, mida WireGuard tunnelisse suunab. Pesastamiseks on tal vaja ainult sisemise serveri aadressi ja ettevõtte prefikseid. Kõik muu jääb kohalikku võrku, sealhulgas printerid ja hüperviisor. See on disaini järgi jaotatud tunnel ja see väldib täielikult välistamise probleemi.

Täistunneliga välimine kiht vajab 0.0.0.0/0 miinus kohalikud vahemikud. Vorming ei suuda välistamist väljendada, seega tuleb komplement välja arvutada ja kohale kleepida.

[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

Kui sisemine klient ei paigalda oma marsruute, loetlege ettevõtte prefiksid ise. Sellelt realt puuduv prefiks on sihtkoht, mida välimine tunnel kunagi ei kanna. Aegunud koopia nimekirjast on hullem kui mitte ükski, sest see näeb endiselt õige välja.

Järjekord, mõõdikud ja teine adapter

Ühendage esmalt välimine tunnel, seejärel käivitage ettevõtte klient. Siis väljub selle lõpp-punkti ühendus WireGuardi kaudu, mitte kohaliku lüüsi kaudu. Andke ettevõtte liidesele madalam mõõdik, et selle prefiksid võidaksid aadressidel, mida see omab.

# 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

Mõõdikud on samm, mille inimesed vahele jätavad. Ilma järjestuseta võidab kattuvan prefiksi puhul marsruut, mis paigaldati viimasena. See muutub käivituste vahel, mistõttu probleem näib katkendlik.

OpenVPN 2.6-le ehitatud kliendid lisavad oma lõksu. Kui andmekanali mahalaadimise adapter on juba hõivatud, keeldub teine eksemplar lihtsalt käivitumast. Profiilile disable-dco lisamine langeb tagasi vanemale TAP-teele ja siis töötavad mõlemad kõrvuti.

Kus pesastatud tee katkeb

Välimise tunneli katkestamine tapab sisemise. Ainult sisemise kliendi uuesti ühendamine saadab selle sageli otse internetti ja eemaldab vaikselt pesastamise. Testige järjekorda iga kord nullist, alustades mõlema tunneliga peatatud olekus.

Oodake väiksemat kasutatavat MTU-d. Iga kiht lisab üldkulu, seega algne paar umbes 1420 ja 1400 on koht, kust alustada. Ülekanne, mis jääb suurte pakettide juures kinni, samal ajal kui väikesed päringud õnnestuvad, on tavaline tunnus. Ettevõtte poliitika on teine piir, sest klient, kes nõuab hallatavat seadet, võib pesastatud teed pidada rikkumiseks.

Kui mõlemad otsad on fikseeritud võrgud, kõrvaldab lüüside vaheline saidilt-saidile tunnel järjekorraprobleemi selle haldamise asemel. Ühes sülearvutis eksisteerivad kaks tunnelit koos ainult siis, kui kummalgi on oma liides ja reegel, mis valib sihtkohti prefiksi järgi.