Įmonės VPN „WireGuard“ viduje: kuris sluoksnis pirmas?

Kūrėjo nešiojamajame kompiuteryje tunelius sudėti vieną į kitą yra dvi pagrįstos priežastys. Arba įmonės klientas turi atrodyti atvykstantis iš konkrečios šalies, arba du privatūs tinklai turi būti pasiekiami vienu metu. Abiem atvejais išorinis tunelis turi nešti paties vidinio kliento ryšį.

Dviejų klientų paleidimas bet kokia tvarka to neduoda. Tai duoda maršrutizavimas.

Palyginkite dvi galimas tvarkas

Išoriniu sluoksniu pasirinkite tunelį, kurio galinį tašką galima pasiekti iš viešojo interneto. Vidinį sluoksnį sudaro tunelis, kurio serveris atsako tik per tą išėjimą. „Windows“ praktinis padalijimas yra „WireGuard“ lauke, o įmonės klientas viduje. Lemiamas veiksnys yra kontrolė.

Oficialus „WireGuard“ klientas taiko visą konfigūracijos failą, įskaitant maršrutus ir DNS. Komerciniai įmonės klientai paprastai slepia abu. Padėjus paslėptą klientą lauke, tenka spėlioti, koks kelias yra po juo.

Atvirkštinė tvarka neįmanoma nėra. Tiesiog apie ją sunkiau mąstyti, nes išorinis klientas perrašo maršrutus pagal grafiką, kurio niekada nematote.

Tegul AllowedIPs įvardija tik įmonės diapazoną

AllowedIPs išvardija paskirties vietas, kurias „WireGuard“ nukreipia į tunelį. Sudėjimui jam reikia tik vidinio serverio adreso ir įmonės prefiksų. Visa kita lieka vietiniame tinkle, įskaitant spausdintuvus ir hipervizorių. Tai pagal projektą padalytas tunelis, ir jis visiškai išvengia išskyrimo problemos.

Išoriniam sluoksniui su visu tuneliu reikia 0.0.0.0/0 atėmus vietinius diapazonus. Formatas negali išreikšti išskyrimo, todėl papildinį reikia apskaičiuoti ir įklijuoti.

[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

Kai vidinis klientas neįdiegia savo maršrutų, patys išvardykite įmonės prefiksus. Toje eilutėje praleistas prefiksas yra paskirties vieta, kurios išorinis tunelis niekada neneša. Pasenusi sąrašo kopija yra blogiau nei jokia, nes ji vis dar atrodo teisinga.

Tvarka, metrikos ir antrasis adapteris

Pirmiausia prisijunkite prie išorinio tunelio, tada paleiskite įmonės klientą. Tada jo galinio taško ryšys išeina per „WireGuard“, o ne per vietinį tinklų sietuvą. Suteikite įmonės sąsajai mažesnę metriką, kad jos prefiksai laimėtų jai priklausančiuose adresuose.

# 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

Metrikos yra žingsnis, kurį žmonės praleidžia. Be tvarkos, persidengiančiam prefiksui laimi paskutinį kartą įdiegtas maršrutas. Tai keičiasi tarp paleidimų, todėl problema atrodo periodiška.

Klientai, sukurti „OpenVPN 2.6“ pagrindu, prideda savo spąstus. Kai duomenų kanalo iškrovimo adapteris jau užimtas, antroji instancija tiesiog atsisako startuoti. Pridėjus disable-dco prie profilio, grįžtama prie senesnio TAP kelio, ir tada abu veikia greta.

Kur lūžta įdėtas kelias

Atjungus išorinį tunelį, žūva vidinis. Prijungus iš naujo tik vidinį klientą, jis dažnai nukreipiamas tiesiai į internetą ir tyliai pašalinamas įdėjimas. Kiekvieną kartą tikrinkite seką nuo nulio, sustabdę abu tunelius.

Tikėkitės mažesnio naudingo MTU. Kiekvienas sluoksnis prideda papildomų išlaidų, todėl pradinė pora apie 1420 ir 1400 yra vieta pradėti. Perdavimas, kuris stringa su dideliais paketais, o mažos užklausos pavyksta, yra įprastas požymis. Įmonės politika yra kita riba, nes klientas, kuris reikalauja valdomo įrenginio, įdėtą kelią gali laikyti pažeidimu.

Kai abu galai yra fiksuoti tinklai, svetainės-svetainės tunelis tarp tinklų sietuvų pašalina tvarkos problemą, o ne ją valdo. Viename nešiojamajame kompiuteryje du tuneliai kartu egzistuoja tik tada, kai kiekvienas turi savo sąsają ir taisyklę, pasirenkančią paskirties vietas pagal prefiksą.