Interruptor d’emergència o accés a la LAN? Dues respostes per a WireGuard
El client de Windows bloqueja el trànsit no tunelitzat quan el perfil diu 0.0.0.0/0. Decidiu quina propietat necessiteu i expresseu el valor per defecte en conseqüència.
L’apretada de mans es completa, la navegació funciona i la impressora, el NAS i els amfitrions SSH locals desapareixen. Al client de Windows això normalment no és cap fallada d’encaminament: un parell els prefixos permesos del qual inclouen el valor per defecte literal activa Bloca el trànsit no tunelitzat, i aquesta opció s’implementa com a regles de tallafoc que descarten els paquets que surten per qualsevol altra interfície. La taula d’encaminament encara llista la subxarxa local com a enllaç directe, i per això el símptoma sembla una mentida. Tres condicions decideixen què fer-hi, i només una és sobre encaminament.
Dues fallades porten el mateix símptoma
La primera fallada és el mode de tancament segur del client, i la seva signatura és que tot el que hi ha fora del túnel s’atura mentre el túnel funciona perfectament. La segona és un problema real d’abastabilitat: una ruta que falta, una entrada que falta al servidor per a una subxarxa darrere del client, o dues xarxes que comparteixen el mateix rang d’adreces. Totes dues produeixen una màquina que pot navegar i no pot imprimir, i tenen solucions oposades, així que el diagnòstic ha de venir abans de la configuració.
L’observació decisiva és si la subxarxa local encara és present a la taula d’encaminament mentre el trànsit cap a ella es descarta.
Tres condicions decideixen la resposta
Primer, aquesta màquina necessita tancament segur? Si la resposta és sí, un túnel que caigui ha d’aturar el trànsit en lloc de deixar-lo tornar a la interfície física, i aquest requisit pesa més que la comoditat local. Segon, els dispositius locals han de romandre abastables mentre el túnel és actiu? La impressió, l’emmagatzematge en xarxa i les consoles de gestió locals són els motius habituals, i són requisits legítims, no excepcions per les quals disculpar-se. Tercer, el perfil expressa el valor per defecte com a literal 0.0.0.0/0? Aquest detall és el que activa les regles del client, i és editable.
Responeu aquestes tres coses per escrit abans de tocar cap perfil, perquè cada resposta apunta a una configuració diferent.
Trieu el tancament segur i renuncieu a la LAN
Si les fuites importen més que l’abastabilitat local, conserveu el valor per defecte literal i deixeu Bloca el trànsit no tunelitzat activat. És una posició coherent: la màquina es tracta com un dispositiu que o bé és dins del túnel o bé és fora de línia, i els serveis locals s’assoleixen des d’un altre dispositiu o a través del túnel si el servidor els encamina. El cost és real i cal esmentar-lo a les notes de desplegament, en lloc que el descobreixi la persona que ha d’imprimir.
Aquesta és l’opció correcta per a màquines que fan feina que no ha d’aparèixer en una xarxa de cafè quan el túnel cau. És un mal valor per defecte per a un portàtil domèstic que també necessita l’escàner.
Trieu l’accés a la LAN i exposeu el valor per defecte d’una altra manera
Si els dispositius locals han de romandre abastables, expresseu la mateixa cobertura sense el prefix literal per defecte. Dos prefixos meitat cobreixen totes les adreces IPv4, la parella equivalent cobreix IPv6, i el client ja no insereix les regles de bloqueig perquè la cadena que busca no hi és.
[Peer]
AllowedIPs = 0.0.0.0/1
AllowedIPs = 128.0.0.0/1
AllowedIPs = ::/1
AllowedIPs = 8000::/1
Endpoint = vpn.example.net:51820
Desmarcar aquesta casella fa que el client escrigui les mateixes dues parelles al perfil, així que comparar el fitxer generat amb el bloc de dalt és una manera ràpida de confirmar el mecanisme en lloc d’endevinar-lo. Se’n deriven dues conseqüències. La cobertura és idèntica, així que res més del túnel canvia. La protecció no és idèntica: amb les regles fora, un túnel que cau deixa la màquina amb la seva interfície física, que és precisament el que el tancament segur evitava.
Comproveu els altres dos sospitosos de totes maneres
Un cop resolta la qüestió del tallafoc, confirmeu que la subxarxa local està realment encaminada i que l’extrem remot sap tot el que hi ha darrere d’aquest client. Un servidor que ha d’arribar a una LAN darrere d’un client necessita aquest prefix a la llista permesa del client al concentrador; si l’ometeu, el concentrador no pot triar un parell per a aquestes adreces, i cap configuració del client no en crea cap.
Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultOutboundAction
route print 0.0.0.0
La categoria de xarxa importa més del que la gent espera: un adaptador de túnel acabat de crear classificat com a públic canvia quines regles se li apliquen, i el resultat pot semblar un bloqueig del tallafoc a l’extrem remot. La impressió de rutes mostra si hi ha un valor per defecte en absolut, cosa que separa un problema de política d’una ruta que falta.
Aleshores proveu tres coses en una sola sessió: internet, un amfitrió local per adreça i un amfitrió a través del túnel. L’apretada de mans només demostra que les claus coincideixen, així que les tres proves són el que demostra la política. Si l’amfitrió local encara refusa amb l’opció desactivada, els sospitosos restants són la ruta, la llista permesa de l’extrem remot i la subxarxa duplicada, en aquest ordre.