Executar la VPN a l'amfitrió o dins de la VM? Manual de decisió

Construir el túnel dins del convidat i construir-lo a l'amfitrió tots dos canvien l'adreça que informa un navegador, i aquí s'acaba el semblança. Un túnel propietat del convidat guarda les seves claus, la seva ruta per defecte i el seu resoledor dins del nucli del convidat, mentre que l'amfitrió reenvia paquets xifrats a una única adreça remota. Un túnel propietat de l'amfitrió és la imatge mirall: el client de l'amfitrió té la sessió i aplica rutes i política, i el convidat manlleva el que en surt. Trieu el propietari equivocat i cada símptoma posterior us envia a la màquina equivocada. Dues ordres resolen la qüestió en aproximadament un minut, i la resta d'aquest manual és què fer amb la resposta.

Decidiu el propietari abans de tocar el client

La regla tracta d'on es produeix el text xifrat, no de quina màquina mostra una icona de VPN. Si el produeix el convidat, el convidat necessita una ruta funcional cap al servidor VPN i res més de l'amfitrió. Si el produeix l'amfitrió, el convidat necessita que el camí per l'amfitrió sobrevisqui a qualsevol política que el client de l'amfitrió imposi al trànsit local.

Tres preguntes solen triar la ubicació per vosaltres. El trànsit del convidat ha de sobreviure a un client corporatiu a l'amfitrió? Aleshores el túnel és dins del convidat. Diversos convidats necessiten una sola credencial i una sola adreça de sortida? Aleshores és a l'amfitrió, amb l'encaminament configurat expressament. El trànsit del convidat ha de quedar-se totalment fora de la VPN de l'amfitrió? Aleshores un túnel al convidat és l'única disposició que us ho dóna per construcció.

Anoteu la resposta en una línia al costat del nom de la VM: guest-owned o host-owned. En un laboratori de sis màquines aquesta nota estalvia més temps que qualsevol pas de sota, perquè us impedeix diagnosticar un túnel que mai no era a la màquina on heu iniciat sessió.

WSL1 i WSL2 són casos oposats

WSL1 no és una màquina virtual, així que la qüestió de la ubicació s'esvaeix en bona part. Els seus binaris de Linux s'executen contra la pila de xarxa de Windows a través d'una capa de traducció, i un client VPN de Linux no té interfícies independents per configurar. La disposició que funciona és un túnel al costat de Windows, amb la distribució usant el resultat sense posseir res.

WSL2 és el revés. Executa un nucli real en una VM auxiliar lleugera darrere d'un commutador virtual d'Hyper-V, i el seu espai d'adreces es tradueix per NAT a través d'un adaptador del costat de l'amfitrió. Per tant, un client de Linux dins de la distribució es comporta com ho faria en una màquina Linux física: crea tun0 o wg0, instal·la les seves pròpies rutes i funciona. La fallada viu al costat de l'amfitrió. Quan un client VPN de Windows es connecta amb una política que bloqueja el trànsit a les xarxes locals, tracta la subxarxa WSL2 com una xarxa local no fiable i talla el camí NAT. Llavors la distribució perd DNS i accés de sortida mentre el seu propi túnel encara és sa: wg show informa d'un handshake, ip route sembla correcte i curl es penja.

Quina correcció podeu fer servir depèn de la compilació de Windows. La més antiga és una excepció al client de l'amfitrió per a la subxarxa WSL, afegida als paràmetres de xarxa local o de túnel dividit del client. La més nova, a les compilacions de Windows 11 que la suporten, és la xarxa mirall: poseu networkingMode=mirrored a la secció [wsl2] de %UserProfile%\.wslconfig, executeu wsl --shutdown, i la distribució comparteix les interfícies de l'amfitrió en lloc d'una subxarxa NAT privada. El mode mirall també canvia com es comporten localhost i els ports d'entrada, així que tracteu-lo com una migració i no com un commutador.

NAT, pont i què pot veure l'amfitrió

Sota NAT, els paquets del túnel del convidat s'adrecen a l'adreça pública del servidor VPN i surten per l'adaptador de l'amfitrió com a UDP o TCP xifrat. L'amfitrió veu un sol flux i el seu recompte de bytes, res sobre les destinacions que hi ha a dins. Sota un adaptador pont, el convidat té la seva pròpia identitat de capa 2 a la LAN física, pren el seu propi arrendament DHCP i sembla a qualsevol política basada en MAC un segon dispositiu. Cap dels dos modes deixa que l'amfitrió llegeixi la càrrega del túnel; el convidat amb pont simplement és molt més visible per a la xarxa del voltant.

També hi ha un terra per a l'aïllament. Un convidat no es pot amagar de la màquina que posseeix la seva memòria, i qui controla l'amfitrió pot llegir claus de la RAM del convidat. El que us dóna un túnel al convidat és una frontera d'encaminament i una frontera de programari maliciós, no protecció contra la persona que té el portàtil. Val la pena tenir oberts els modes d'adaptador documentats mentre trieu, ja que el mode canvia tant el que veu l'amfitrió com el que veu la LAN.

Manual: col·loqueu-lo, configureu-lo, demostreu-lo

Executeu aquestes quatre comprovacions en ordre en una shell de convidat nova, i atureu-vos a la primera que no concordin amb el propietari que heu anotat.

1. ip route get 1.1.1.1 que retorna tun0 o wg0 vol dir propietat del convidat, i eth0 amb un salt següent privat vol dir propietat de l'amfitrió.
2. resolvectl query example.com, o llegiu /etc/resolv.conf allà on el convidat no executa cap servei resoledor. Un túnel que transporta trànsit però no DNS és l'estat mig configurat més habitual.
3. Compareu les sortides: curl -4 -s https://ifconfig.me al convidat contra curl.exe -4 -s https://ifconfig.me a l'amfitrió. Adreces diferents volen dir que el convidat posseeix el túnel, i un amfitrió a la VPN amb un convidat que mostra el proveïdor de casa és el cas de no heretar res.
4. Repetiu tots dos amb -6. Un túnel només v4 filtra v6 tret que el client el bloquegi o l'encamini, i molts clients deixen v6 a la interfície física per defecte.

Per a un disseny de passarel·la a l'amfitrió, on diversos convidats comparteixen un túnel, l'amfitrió ha de reenviar i traduir. En un amfitrió Linux això són tres peces, i el convidat torna silenciosament a la seva ruta senzilla quan en falta qualsevol:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Al costat de WireGuard, l'AllowedIPs del parell de l'amfitrió ha d'incloure la subxarxa dels convidats, per exemple 192.168.122.0/24, o els paquets de tornada no arriben mai i la configuració sembla un problema de tallafocs. Un amfitrió Windows obté el mateix resultat amb Internet Connection Sharing o una regla NAT al commutador Hyper-V, i necessita la mateixa comprovació del camí de tornada.

Quan la disposició encara és oberta, aquesta taula cobreix els arranjaments més freqüents:

Dos túnels, dos convidats i els conflictes entre ells

Quan necessiteu dues sortides alhora, el patró que aguanta és un túnel per convidat. Cada VM manté la seva ruta per defecte i el seu resoledor, l'amfitrió es queda a la xarxa ordinària, i els dos túnels no discuteixen mai per la mateixa taula d'encaminament. Enllaçar dos convidats amb un pont tampoc no ajunta les seves rutes: la xarxa virtual proporciona un camí, i a cada client encara cal dir-li que aquest trànsit local pot evitar el túnel.

Executar un túnel d'amfitrió i un de convidat alhora és legítim, i l'encaixament deliberat de vegades és exactament el que voleu, amb el convidat sortint pel seu propi túnel i aquest túnel sortint pel de l'amfitrió. El que ho converteix en una caiguda és que ningú no ha anotat quina destinació s'ha d'assolir per quina capa. Mantingueu una llista de dues columnes amb destinació i propietari, i un conflicte de rutes esdevé una consulta en lloc d'una tarda de descoberta.

Verifiqueu, i després deixeu la recuperació al propietari

Proveu des de dins del convidat amb un procés d'aplicació nou: trànsit, resolució de noms, les dues famílies d'adreces i què passa quan el túnel cau. La icona de VPN de l'amfitrió no diu res sobre la cobertura del convidat, i aquesta és la confirmació falsa més habitual en tot aquest àmbit.

La recuperació també pertany al propietari. Un túnel propietat del convidat es restaura amb el client propi del convidat i les rutes que va escriure. Un disseny propietat de l'amfitrió es restaura amb la seqüència d'arrencada de l'amfitrió, i les regles de reenviament no sobreviuen a un reinici tret que una unitat o una tasca d'inici les torni a aplicar. Una instantània restaurada és un desplegament, no una desfeta, perquè torna credencials velles i rutes velles juntament amb el disc. Abans de donar la feina per feta, confirmeu que el propietari encara coincideix amb la línia que heu anotat, que DNS i les dues famílies d'adreces es resolen dins del convidat, que un túnel mort deixa una xarxa utilitzable en lloc d'un forat negre, i que un reinici o una restauració d'instantània reprodueix el mateix estat.