A VPN e a LAN da casa comparten subrede: percorre primeiro a ruta
Os dous adaptadores reclaman 192.168.1.0/24 e só unha ruta gaña. Percorre a lista de adaptadores, a ruta gañadora e a volta antes de renumerar ou culpar o DNS.
Conectas coa VPN da oficina, a icona da bandexa vólvese verde, a intranet carga e a impresora que está a dous metros deixa de responder. O recurso compartido que funcionaba esta mañá dá tempo de espera esgotado na mesma máquina, e ningún rexistro menciona unha impresora. O reflexo é o DNS, porque un nome que non se resolve parece un nome que non existe, pero o problema é o enderezo: dous adaptadores reclaman agora 192.168.1.0/24 e só unha ruta pode gañar ese prefixo. Percórreo nesta orde e verás que adaptador o colleu antes de cambiar nada.
Comeza polo síntoma, non polo túnel
A pista é o alcance. Se a intranet funciona e falla cada dispositivo local, o túnel está san e a ruta local non. Se os dispositivos locais funcionan e falla a intranet, ao revés. Se todo funciona menos un equipo, estás ante un único enderezo que existe nos dous lados.
Anota un enderezo local e un remoto antes de tocar ningún axuste. “A impresora” non é comprobable; 192.168.1.40 si. Ese só paso evita a hora perdida máis habitual con este problema, que é reescribir os axustes de DNS por unha decisión de enrutamento.
Paso 1: ve os dous adaptadores reclamando o prefixo
Abre Conexións de rede (ncpa.cpl) e le os dous adaptadores un xunto ao outro. O adaptador Ethernet mostra 192.168.1.50/24 con pasarela 192.168.1.1. O adaptador VPN mostra 192.168.1.201/24, empurrado polo servidor. Ambos son lexítimos, ambos cren que o prefixo é on-link, e a pila manterá unha soa ruta para el.
Get-NetIPAddress -AddressFamily IPv4 enumera os enderezos, e Get-NetIPInterface | Sort-Object InterfaceMetric mostra a orde na que a pila os usará. Esa columna de métrica é a decisión que estás a piques de ler, así que anota os números en lugar de recordalos.
Demostra barato que a teoría do DNS é falsa: Resolve-DnsName printer.office.lan devolve o mesmo enderezo que onte. O nome resolveuse; despois o paquete saíu polo adaptador equivocado. Dous minutos aquí aforran unha tarde nos axustes do resolutor.
Paso 2: le a ruta que realmente gañou
Find-NetRoute -RemoteIPAddress 192.168.1.40 imprime a interface, o seguinte salto e a orixe que a pila usaría para ese enderezo. Trata esa saída como a resposta, non como unha pista. route print -4 dá toda a táboa cando queres ver que entrada perdeu e por canto.
A especificidade gaña á intención. Un 192.168.0.0/25 empurrado derrota un 192.168.0.0/24 local porque o prefixo é máis longo, así que de 192.168.0.0 a 192.168.0.127 saen polo túnel mentres a metade superior queda local. Que media LAN desapareza sen mensaxe de erro é o comportamento correcto desa táboa.
tracert -d 192.168.1.40 confírmao desde fóra da táboa: se o primeiro salto é un enderezo de túnel en vez do teu propio router, a ruta é toda a historia. En Linux a mesma pregunta é ip route get 192.168.1.40, que imprime enderezo de orixe e dispositivo nunha liña. Cando a resposta nomea tun0, deixa de mirar o navegador.
Paso 3: comproba a volta antes de culpar o cliente
Unha ruta de ida correcta falla igual se o lado afastado non pode responder. Cando se chega a unha LAN de cliente polo túnel, a pasarela desa LAN ten que saber onde vive o grupo do túnel: ip route add 10.8.0.0/24 via 192.168.1.12 nese router, e push “route 192.168.1.0 255.255.255.0” desde o servidor para que os clientes coñezan a volta.
Sen a primeira entrada, a resposta sae do destino cara á súa pasarela por defecto, que reenvía un enderezo privado ao provedor e descártao. O síntoma é unidireccional e fácil de malinterpretar: as peticións aparecen en tun0, as respostas nunca.
Unha regra masquerade no host VPN elimina a necesidade desa ruta estática: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Tamén agocha os enderezos de orixe reais, o que fai máis difícil cada pregunta posterior sobre rexistros. Un host de destino coa pasarela por defecto equivocada produce o mesmo silencio, cunha redirección ICMP como mellor caso e un burato negro como habitual, e por iso a captura corresponde aos dous extremos.
Paso 4: escolle unha reparación coa que poidas vivir
Para isto úsanse cinco reparacións e non son intercambiables. Escolle polo que debe seguir sendo alcanzable á vez, non por que comando é máis curto.
| 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 |
As métricas son a opción barata e a primeira á que a xente recorre. O cambio aplícase á interface, así que funciona mentres o túnel está levantado, e corresponde a un script xunto ao cliente, non a un shell que esquecerás. Non pode dar acceso simultáneo ao mesmo enderezo en dúas redes, e ese é o límite que manda a todos os demais ao resto da táboa.
Renumerar a LAN da casa a 10.10.0.0/24 é a solución limpa: unha renovación da concesión DHCP máis as reservas, as colas de impresión e os enderezos codificados que mencionan o rango antigo. Renumerar o lado da oficina normalmente non é a túa decisión. IPv6 elimina a colisión por completo cando ambas as redes o levan, usando un prefixo local único de fd00::/8 en lugar de algo memorizable, pero proba a aplicación por TCP, non cun ping, porque ICMP pode funcionar mentres o servizo non.
A propia opción de tradución de OpenVPN é o último recurso, empurrada desde o servidor a unha entrada de directorio específica do cliente. Toma catro parámetros tras o nome da opción — dirección, rede, máscara e alias — e o alias non é opcional: push "route 192.168.2.0 255.255.255.0" e push "client-nat dnat 192.168.2.0 255.255.255.0 192.168.1.0". A rede e a máscara son o rango que o cliente ve (192.168.2.0/24), o alias é o rango real da oficina no lado do servidor (192.168.1.0/24), e a ruta empurrada é o que fai alcanzable ese rango visible. A oficina aparece entón para ese cliente baixo 192.168.2.x. Documenta o mapeo no perfil, ou a seguinte persoa depurarallo como unha falla de enrutamento.
Publicar un só servizo é a versión estreita da tradución e non necesita en absoluto a opción de OpenVPN. Unha regra DNAT no host VPN republica un só porto, así que a LAN conserva os seus enderezos e chega ao servizo no enderezo de host que xa coñece. O custo é o habitual: o servizo ve o host VPN como orixe, así que os rexistros por cliente e as buscas inversas deixan de significar nada. Iso cobre unha cola de impresión ou unha páxina de administración, non hosts dos dous lados que se alcancen.
Que aínda non funcionará e que anotar
O broadcast non cruza un túnel enrutado. DLNA, UPnP, a exploración NetBIOS e Wake-on-LAN dependen de broadcast ou multicast que un dispositivo tun non transporta, así que ningunha ruta arranxa o descubrimento. A ponte con dev tap estende o segmento, e con el os broadcast de DHCP, ARP e calquera outro paquete de descubrimento; prefire unha ruta de host unicast como route 192.168.2.1 255.255.255.255 para o enderezo do lado LAN dun router remoto.
Dous routers que usan ambos 192.168.1.1 no mesmo camiño pertencen á mesma familia de problemas: o enderezo local sempre gaña, así que a páxina do router afastado segue inalcanzable ata que unha LAN se move. Engadir un segundo adaptador non cambia nada en ningún dos dous casos.
Anota as probas antes de editar nada: ip route get ou Find-NetRoute, ping -c 3 ao enderezo en cuestión, un traceroute, e tcpdump -ni tun0 icmp no cliente, despois a táboa de enrutamento e os contadores NAT no servidor. Un ping que funciona nun sentido e morre no outro apunta á volta, non ao túnel, e esa soa distinción decide cal das reparacións de arriba necesitas de verdade.