VPN de companie în interiorul WireGuard: care strat vine primul?

Doi clienți pe aceeași mașină funcționează doar când tunelul exterior transportă propria conexiune a clientului interior și metricile aleg interfața corectă pentru fiecare prefix.

Există două motive legitime pentru a imbrica tuneluri pe laptopul unui dezvoltator. Fie clientul de companie trebuie să pară că vine dintr-o țară anume, fie două rețele private trebuie să fie accesibile în același timp. Ambele cazuri cer ca tunelul exterior să transporte propria conexiune a clientului interior.

Pornirea a doi clienți în orice ordine nu produce asta. Rutarea o produce.

Comparați cele două ordini posibile

Alegeți stratul exterior drept tunelul al cărui punct final este accesibil din internetul public. Stratul interior este tunelul al cărui server răspunde doar prin acea ieșire. În Windows împărțirea practică este WireGuard afară și clientul de companie înăuntru. Factorul decisiv este controlul.

Clientul oficial WireGuard aplică un fișier de configurare complet, inclusiv rute și DNS. Clienții de companie comerciali ascund de obicei ambele. Plasarea unui client ascuns afară vă lasă să ghiciți calea de dedesubt.

Ordinea inversă nu este imposibilă. Este doar mai greu de analizat, pentru că clientul exterior rescrie rutele după un program pe care nu îl vedeți niciodată.

Lăsați AllowedIPs să numească doar intervalul de companie

AllowedIPs enumeră destinațiile pe care WireGuard le direcționează în tunel. Pentru imbricare are nevoie doar de adresa serverului interior și de prefixele de companie. Tot restul rămâne în rețeaua locală, inclusiv imprimantele și hipervizorul. Acesta este un tunel divizat prin proiectare și evită complet problema excluderii.

Un strat exterior cu tunel complet are nevoie de 0.0.0.0/0 minus intervalele locale. Formatul nu poate exprima o excludere, deci complementul trebuie calculat și lipit.

[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

Când clientul interior nu își instalează propriile rute, enumerați dumneavoastră prefixele de companie. Un prefix omis din acea linie este o destinație pe care tunelul exterior nu o transportă niciodată. O copie învechită a listei este mai rea decât niciuna, pentru că încă pare corectă.

Ordine, metrici și al doilea adaptor

Conectați mai întâi tunelul exterior, apoi porniți clientul de companie. Atunci conexiunea lui la punctul final iese prin WireGuard în locul gateway-ului local. Dați interfeței de companie o metrică mai mică pentru ca prefixele ei să câștige pentru adresele pe care le deține.

# 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

Metricile sunt pasul pe care oamenii îl sar. Fără o ordine, pentru prefixul suprapus câștigă ruta instalată ultima. Asta se schimbă între porniri, de aceea problema pare intermitentă.

Clienții bazați pe OpenVPN 2.6 adaugă o capcană proprie. Când adaptorul de descărcare al canalului de date este deja ocupat, o a doua instanță pur și simplu refuză să pornească. Adăugarea disable-dco în profil revine la vechea cale TAP, iar atunci ambele rulează una lângă alta.

Unde se rupe calea imbricată

Deconectarea tunelului exterior îl ucide pe cel interior. Reconectarea doar a clientului interior îl trimite adesea direct pe internet și elimină în tăcere imbricarea. Testați secvența de la zero de fiecare dată, cu ambele tuneluri oprite.

Așteptați-vă la un MTU util mai mic. Fiecare strat adaugă suprasarcină, așa că o pereche de start în jurul valorilor 1420 și 1400 este un punct de început. Un transfer care se blochează la pachete mari în timp ce cererile mici reușesc este semnul obișnuit. Politica de companie este cealaltă limită, pentru că un client care cere un dispozitiv administrat poate considera o cale imbricată o încălcare.

Când ambele capete sunt rețele fixe, un tunel de la sit la sit între gateway-uri elimină problema ordinii în loc să o administreze. Pe un singur laptop, două tuneluri coexistă doar când fiecare are propria interfață și o regulă care selectează destinații după prefix.

Articole similare