Entreprena VPN ene de WireGuard: kiu tavolo venas unue?

Ekzistas du legitimaj kialoj por nesti tunelojn sur programista tekkomputilo. Aŭ la entreprena kliento devas ŝajni deveni el difinita lando, aŭ du privataj retoj devas esti atingeblaj samtempe. En ambaŭ kazoj la ekstera tunelo devas porti la propran konekton de la interna kliento.

Startigi du klientojn laŭ iu ajn ordo tion ne donas. La enkursigado tion faras.

Komparu la du eblajn ordojn

Elektu la eksteran tavolon kiel la tunelon, kies finpunkton la publika interreto povas atingi. La interna tavolo estas la tunelo, kies servilo respondas nur tra tiu eliro. En Windows la praktika divido estas WireGuard ekstere kaj la entreprena kliento interne. La decida faktoro estas kontrolo.

La oficiala WireGuard-kliento aplikas plenan agordan dosieron, inkluzive de vojoj kaj DNS. Komercaj entreprenaj klientoj kutime kaŝas ambaŭ. Se oni metas kaŝitan klienton ekstere, oni restas divenanta pri la vojo sub ĝi.

La inversa ordo ne estas neebla. Ĝi simple estas pli malfacile pripensebla, ĉar la ekstera kliento reskribas vojojn laŭ horaro, kiun oni neniam vidas.

Lasu AllowedIPs nomi nur la entreprenan aron

AllowedIPs listigas la celojn, kiujn WireGuard enkursigas en la tunelon. Por nestado ĝi bezonas nur la adreson de la interna servilo kaj la entreprenajn prefiksojn. Ĉio alia restas en la loka reto, inkluzive de printiloj kaj hipervizoro. Tio estas fendita tunelo laŭ la dezajno, kaj ĝi tute evitas la problemon de ekskludo.

Ekstera tavolo kun plena tunelo bezonas 0.0.0.0/0 minus la lokaj arnoj. La formato ne povas esprimi ekskludon, do la komplemento devas esti kalkulita kaj enmetita.

[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

Kiam la interna kliento ne instalas siajn proprajn vojojn, listigu la entreprenajn prefiksojn mem. Prefikso lasita ekster tiu linio estas celo, kiun la ekstera tunelo neniam portas. Malnova kopio de la listo estas pli malbona ol neniu, ĉar ĝi ankoraŭ aspektas ĝusta.

Ordo, metrikoj kaj la dua adaptilo

Konektu la eksteran tunelon unue, poste startigu la entreprenan klienton. Tiam ĝia finpunkta konekto eliras tra WireGuard anstataŭ la loka enirejo. Donu al la entreprena interfaco pli malaltan metrikon, por ke ĝiaj prefiksoj gajnu por la adresoj, kiujn ĝi posedas.

# 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

Metrikoj estas la paŝo, kiun homoj preterlasas. Sen ordo, por la interkovra prefikso gajnas la vojo instalita laste. Tio ŝanĝiĝas inter lanĉoj, kaj tial la problemo aspektas intermita.

Klientoj konstruitaj sur OpenVPN 2.6 aldonas sian propran kaptilon. Kiam la adaptilo por malŝarĝo de la datkanalo jam estas okupita, dua ekzemplero simple rifuzas starti. Aldoni disable-dco al la profilo reiras al la pli malnova vojo TAP, kaj tiam ambaŭ funkcias flanko ĉe flanko.

Kie rompiĝas la nestita vojo

Malkonekti la eksteran tunelon mortigas la internan. Rekonekti nur la internan klienton ofte sendas ĝin rekte al la interreto kaj silente forigas la nestadon. Testu la sinsekvon de nulo ĉiufoje, komencante kun ambaŭ tuneloj haltigitaj.

Atendu pli malgrandan uzeblan MTU. Ĉiu tavolo aldonas superkoston, do komenca paro ĉirkaŭ 1420 kaj 1400 estas loko por komenci. Transigo, kiu blokiĝas ĉe grandaj pakaĵoj dum malgrandaj petoj sukcesas, estas la kutima signo. Entreprena politiko estas la alia limo, ĉar kliento, kiu postulas administritan aparaton, povas konsideri nestitan vojon malobservo.

Kiam ambaŭ finoj estas fiksaj retoj, tunelo de loko al loko inter la enirejoj forigas la ordan problemon anstataŭ administri ĝin. Sur unu tekkomputilo, du tuneloj kunekzistas nur kiam ĉiu havas sian propran interfacon kaj regulon, kiu elektas celojn laŭ prefikso.