VPN corporativa dins de WireGuard: quina capa va primer?

Dos clients en una mateixa màquina només funcionen quan el túnel exterior transporta el punt final del client interior i les mètriques trien la interfície correcta per a cada prefix.

Hi ha dues raons legítimes per niar túnels en un portàtil de desenvolupament. O el client corporatiu ha de semblar que ve d'un país concret, o dues xarxes privades han de ser abastables alhora. Els dos casos necessiten que el túnel exterior transporti la connexió pròpia del client interior.

Iniciar dos clients en un ordre qualsevol no ho aconsegueix. Ho aconsegueix l'encaminament.

Compareu els dos ordres possibles

Trieu la capa exterior com el túnel el punt final del qual és abastable des d'Internet públic. La capa interior és el túnel el servidor del qual només respon a través d'aquella sortida. A Windows la divisió pràctica és WireGuard a fora i el client corporatiu a dins. El factor decisiu és el control.

El client oficial de WireGuard aplica un fitxer de configuració complet, rutes i DNS inclosos. Els clients corporatius comercials normalment amaguen les dues coses. Posar un client ocult a l'exterior us deixa endevinant el camí que hi ha a sota.

L'ordre invers no és impossible. És més difícil de raonar, perquè el client exterior reescriu les rutes segons un calendari que mai no veieu.

Deixeu que AllowedIPs nomeni només el rang corporatiu

AllowedIPs llista les destinacions que WireGuard encamina dins del túnel. Per niar només necessita l'adreça del servidor interior i els prefixos corporatius. Tota la resta es queda a la xarxa local, impressores i hipervisor inclosos. Això és un túnel dividit per disseny i evita del tot el problema de l'exclusió.

Una capa exterior de túnel complet necessita 0.0.0.0/0 menys els rangs locals. El format no pot expressar una exclusió, així que el complement s'ha de calcular i enganxar.

[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

Quan el client interior no instal·la les seves pròpies rutes, llisteu els prefixos corporatius vosaltres mateixos. Un prefix que falta d'aquella línia és una destinació que el túnel exterior mai no transporta. Una còpia obsoleta de la llista és pitjor que cap, perquè encara sembla correcta.

Ordre, mètriques i el segon adaptador

Connecteu primer el túnel exterior i després inicieu el client corporatiu. Aleshores la connexió del seu punt final surt per WireGuard en lloc de la porta d'enllaç local. Doneu a la interfície corporativa una mètrica més baixa perquè els seus prefixos guanyin per a les adreces que posseeix.

# 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

Les mètriques són el pas que la gent s'estalvia. Sense un ordre, la ruta instal·lada més tard guanya per al prefix superposat. Això canvia entre arrencades, i per això el problema sembla intermitent.

Els clients basats en OpenVPN 2.6 afegeixen una trampa pròpia. Quan l'adaptador de descàrrega del canal de dades ja és ocupat, una segona instància simplement es nega a arrencar. Afegir disable-dco al perfil torna al camí TAP més antic, i llavors tots dos funcionen costat a costat.

On es trenca el camí niuat

Desconnectar el túnel exterior mata l'interior. Tornar a connectar només el client interior sovint l'envia directament a Internet i elimina en silenci el niament. Proveu la seqüència des de zero cada vegada, començant amb tots dos túnels aturats.

Espereu una MTU útil més petita. Cada capa afegeix sobrecost, així que una parella inicial al voltant de 1420 i 1400 és un bon punt de partida. Una transferència que es penja amb paquets grans mentre les peticions petites funcionen és el senyal habitual. La política corporativa és l'altre límit, perquè un client que vol un dispositiu gestionat pot considerar un camí niuat una infracció.

Quan els dos extrems són xarxes fixes, un túnel de lloc a lloc entre les portes d'enllaç elimina el problema de l'ordre en lloc de gestionar-lo. En un sol portàtil, dos túnels coexisteixen només quan cadascun té la seva pròpia interfície i una regla que selecciona destinacions per prefix.

Articles relacionats