La VPN i la LAN de casa fan servir la mateixa subxarxa: primer recorreu la ruta
Tots dos adaptadors reclamen 192.168.1.0/24 i només una ruta guanya. Recorreu la llista d'adaptadors, la ruta guanyadora i el camí de tornada abans de renumerar o culpar el DNS.
Et connectes a la VPN de l'oficina, la icona de la safata es posa verda, la intranet carrega i la impressora que és a dos metres deixa de respondre. El recurs compartit que funcionava aquest matí expira a la mateixa màquina, i cap registre no esmenta cap impressora. El reflex és el DNS, perquè un nom que no es resol sembla un nom que no existeix, però el problema és l'adreça: dos adaptadors reclamen ara 192.168.1.0/24 i només una ruta pot guanyar aquest prefix. Recorre-ho en aquest ordre i veuràs quin adaptador se l'ha quedat abans de canviar res.
Comenceu pel símptoma, no pel túnel
La pista és l'abast. Si la intranet funciona i tots els dispositius locals fallen, el túnel és sa i el camí local no ho és. Si els dispositius locals funcionen i la intranet falla, al revés. Si tot funciona excepte un equip, estàs davant d'una sola adreça que existeix als dos costats.
Anota una adreça local i una de remota abans de tocar cap paràmetre. “La impressora” no és verificable; 192.168.1.40 sí. Aquest sol pas evita l'hora perduda més habitual en aquest problema, que és reescriure la configuració del DNS per una decisió d'encaminament.
Pas 1: vegeu els dos adaptadors que reclamen el prefix
Obre Connexions de xarxa (ncpa.cpl) i llegeix els dos adaptadors costat a costat. L'adaptador Ethernet mostra 192.168.1.50/24 amb porta d'enllaç 192.168.1.1. L'adaptador VPN mostra 192.168.1.201/24, empès pel servidor. Tots dos són legítims, tots dos creuen que el prefix és on-link, i la pila en mantindrà una sola ruta.
Get-NetIPAddress -AddressFamily IPv4 llista les adreces, i Get-NetIPInterface | Sort-Object InterfaceMetric mostra l'ordre en què la pila les farà servir. Aquella columna de mètrica és la decisió que estàs a punt de llegir, així que anota els números en lloc de recordar-los.
Demostra barat que la teoria del DNS és falsa: Resolve-DnsName printer.office.lan retorna la mateixa adreça que ahir. El nom es va resoldre; el paquet després va sortir per l'adaptador equivocat. Dos minuts aquí estalvien una tarda en la configuració del resolutor.
Pas 2: llegiu la ruta que realment ha guanyat
Find-NetRoute -RemoteIPAddress 192.168.1.40 imprimeix la interfície, el següent salt i la font que la pila faria servir per a aquesta adreça. Tracta aquesta sortida com la resposta, no com una pista. route print -4 dóna tota la taula quan vols veure quina entrada ha perdut i per quant.
L'especificitat guanya la intenció. Un 192.168.0.0/25 empès derrota un 192.168.0.0/24 local perquè el prefix és més llarg, així que de 192.168.0.0 a 192.168.0.127 surten pel túnel mentre la meitat superior es queda local. Que mitja LAN desaparegui sense cap missatge d'error és el comportament correcte d'aquella taula.
tracert -d 192.168.1.40 ho confirma des de fora de la taula: si el primer salt és una adreça de túnel en lloc del teu propi router, la ruta és tota la història. A Linux la mateixa pregunta és ip route get 192.168.1.40, que imprimeix adreça d'origen i dispositiu en una línia. Quan la resposta anomena tun0, deixa de mirar el navegador.
Pas 3: comproveu el camí de tornada abans de culpar el client
Una ruta d'anada correcta encara falla si el costat llunyà no pot respondre. Quan s'arriba a una LAN de client pel túnel, la porta d'enllaç d'aquesta LAN ha de saber on viu el pool del túnel: ip route add 10.8.0.0/24 via 192.168.1.12 en aquell router, i push “route 192.168.1.0 255.255.255.0” des del servidor perquè els clients coneguin el camí de tornada.
Sense la primera entrada, la resposta surt del destí cap a la seva porta d'enllaç per defecte, que reenvia una adreça privada al proveïdor i la descarta. El símptoma és unidireccional i fàcil de malinterpretar: les peticions apareixen a tun0, les respostes mai.
Una regla masquerade a l'amfitrió VPN elimina la necessitat d'aquella ruta estàtica: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. També amaga les adreces d'origen reals, cosa que fa més difícil cada pregunta posterior sobre registres. Un amfitrió de destí amb la porta d'enllaç per defecte equivocada produeix el mateix silenci, amb una redirecció ICMP com a millor cas i un forat negre com a habitual, i per això la captura pertoca als dos extrems.
Pas 4: trieu una reparació que pugueu suportar
S'hi fan servir cinc reparacions i no són intercanviables. Tria per què ha de romandre accessible alhora, no per quina ordre és més curta.
| Repair | What it fixes | What it costs |
|---|---|---|
| Flip interface metrics | Alternating access: office now, home later, never both | Get-NetAdapter -Name "Ethernet 2" | Set-NetIPInterface -InterfaceMetric 21; set the VPN adapter back to 5000. A client that rewrites metrics on connect defeats it |
| Renumber one side | Every host reachable in both directions | DHCP reservations, printer queues, firewall rules and hard-coded addresses all move |
| Narrow the advertised prefix | Remote hosts really live in the upper half | Breaks the day someone adds a host below the cut |
| Translate with client-nat | Both address plans stay untouched | Stateless per-client mapping, unreadable logs, anything embedding addresses breaks |
| Publish one service with DNAT | One service on the VPN host reachable from the LAN | Both address plans stay; source addresses and reverse lookups stop being meaningful |
Les mètriques són l'opció barata i la primera a què la gent recorre. El canvi s'aplica a la interfície, així que funciona mentre el túnel és actiu, i pertoca en un script al costat del client, no en un shell que oblidaràs. No pot donar accés simultani a la mateixa adreça en dues xarxes, i aquest és el límit que envia tothom a la resta de la taula.
Renumerar la LAN de casa a 10.10.0.0/24 és la solució neta: una renovació de la concessió DHCP més les reserves, les cues d'impressió i les adreces codificades que esmenten el rang antic. Renumerar el costat de l'oficina normalment no és decisió teva. IPv6 elimina la col·lisió del tot quan les dues xarxes el porten, amb un prefix local únic de fd00::/8 en lloc d'alguna cosa memoritzable, però prova l'aplicació per TCP, no amb un ping, perquè ICMP pot funcionar mentre el servei no.
L'opció de traducció pròpia d'OpenVPN és l'últim recurs, empesa des del servidor cap a una entrada de directori específica del client. Pren quatre paràmetres després del nom de l'opció — direcció, xarxa, màscara i àlies — i l'àlies no és opcional: push "route 192.168.2.0 255.255.255.0" i push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". La xarxa i la màscara són el rang que veu el client (192.168.2.0/24), l'àlies és el rang real de l'oficina al costat del servidor (192.168.1.0/24), i la ruta empesa és el que fa accessible aquell rang visible. L'oficina apareix llavors a aquell client sota 192.168.2.x. Documenta el mapatge al perfil, o la propera persona ho depurarà com una fallada d'encaminament.
Publicar un sol servei és la versió estreta de la traducció i no necessita gens l'opció d'OpenVPN. Una regla DNAT a l'amfitrió VPN republica un sol port, així que la LAN conserva les seves adreces i arriba al servei a l'adreça d'amfitrió que ja coneix. El cost és l'habitual: el servei veu l'amfitrió VPN com a origen, així que els registres per client i les consultes inverses deixen de significar res. Això cobreix una cua d'impressió o una pàgina d'administració, no amfitrions als dos costats que s'arribin.
Què encara no funcionarà i què cal enregistrar
El broadcast no travessa un túnel encaminat. DLNA, UPnP, l'exploració NetBIOS i Wake-on-LAN depenen de broadcast o multicast que un dispositiu tun no transporta, així que cap ruta no arregla el descobriment. En pont amb dev tap s'estén el segment, i amb ell els broadcast DHCP, ARP i qualsevol altre paquet de descobriment; preferiu una ruta d'amfitrió unicast com route 192.168.2.1 255.255.255.255 per a l'adreça del costat LAN d'un router remot.
Dos routers que fan servir tots dos 192.168.1.1 al mateix camí pertanyen a la mateixa família de problemes: l'adreça local sempre guanya, així que la pàgina del router llunyà queda inaccessible fins que una LAN es mou. Afegir un segon adaptador no canvia res en cap dels dos casos.
Anota les proves abans d'editar res: ip route get o Find-NetRoute, ping -c 3 a l'adreça en qüestió, un traceroute, i tcpdump -ni tun0 icmp al client, després la taula d'encaminament i els comptadors NAT al servidor. Un ping que funciona en un sentit i mor en l'altre apunta al camí de tornada, no al túnel, i aquesta sola distinció decideix quina de les reparacions de dalt necessites realment.