VPN e LAN de casa na mesma sub-rede: siga a rota primeiro
Os dois adaptadores reivindicam 192.168.1.0/24 e só uma rota vence. Siga a lista de adaptadores, a rota vencedora e o caminho de volta antes de renumerar ou culpar o DNS.
Você liga na VPN do escritório, o ícone da bandeja fica verde, a intranet carrega e a impressora a dois metros para de responder. O compartilhamento que funcionava de manhã expira na mesma máquina, e nenhum log menciona impressora. O reflexo é o DNS, porque um nome que não resolve parece um nome que não existe, mas o problema é o endereço: dois adaptadores agora reivindicam 192.168.1.0/24 e só uma rota pode vencer esse prefixo. Percorra nesta ordem e você verá qual adaptador ficou com ele antes de mudar qualquer coisa.
Comece pelo sintoma, não pelo túnel
A pista é o escopo. Se a intranet funciona e todos os dispositivos locais falham, o túnel está saudável e o caminho local não. Se os dispositivos locais funcionam e a intranet falha, o contrário. Se tudo funciona menos um host, você está diante de um único endereço que existe dos dois lados.
Anote um endereço local e um remoto antes de tocar em qualquer ajuste. “A impressora” não é testável; 192.168.1.40 é. Esse único passo evita a hora perdida mais comum neste problema, que é reescrever configurações de DNS por causa de uma decisão de roteamento.
Passo 1: veja os dois adaptadores reivindicando o prefixo
Abra Conexões de rede (ncpa.cpl) e leia os dois adaptadores lado a lado. O adaptador Ethernet mostra 192.168.1.50/24 com gateway 192.168.1.1. O adaptador VPN mostra 192.168.1.201/24, enviado pelo servidor. Os dois são legítimos, os dois acreditam que o prefixo é on-link, e a pilha manterá uma única rota para ele.
Get-NetIPAddress -AddressFamily IPv4 lista os endereços, e Get-NetIPInterface | Sort-Object InterfaceMetric mostra a ordem em que a pilha vai usá-los. Essa coluna de métrica é a decisão que você está prestes a ler, então anote os números em vez de tentar decorá-los.
Refute a teoria do DNS de forma barata: Resolve-DnsName printer.office.lan devolve o mesmo endereço de ontem. O nome foi resolvido; depois o pacote saiu pelo adaptador errado. Dois minutos aqui poupam uma tarde nos ajustes do resolvedor.
Passo 2: leia a rota que realmente venceu
Find-NetRoute -RemoteIPAddress 192.168.1.40 imprime a interface, o próximo salto e a origem que a pilha usaria para esse endereço. Trate essa saída como a resposta, não como uma pista. route print -4 dá a tabela inteira quando você quer ver qual entrada perdeu e por quanto.
A especificidade vence a intenção. Um 192.168.0.0/25 enviado derrota um 192.168.0.0/24 local porque o prefixo é mais longo, então de 192.168.0.0 a 192.168.0.127 saem pelo túnel enquanto a metade superior fica local. Meia LAN desaparecer sem mensagem de erro é o comportamento correto dessa tabela.
tracert -d 192.168.1.40 confirma isso de fora da tabela: se o primeiro salto for um endereço de túnel em vez do seu próprio roteador, a rota é toda a história. No Linux a mesma pergunta é ip route get 192.168.1.40, que imprime endereço de origem e dispositivo numa linha. Quando a resposta nomear tun0, pare de olhar o navegador.
Passo 3: confira a volta antes de culpar o cliente
Uma rota de ida correta ainda falha se o lado distante não puder responder. Quando se chega a uma LAN de cliente pelo túnel, o gateway dessa LAN precisa saber onde vive o pool do túnel: ip route add 10.8.0.0/24 via 192.168.1.12 nesse roteador, e push “route 192.168.1.0 255.255.255.0” do servidor para que os clientes conheçam a volta.
Sem a primeira entrada, a resposta sai do destino rumo ao seu gateway padrão, que encaminha um endereço privado ao provedor e o descarta. O sintoma é unidirecional e fácil de ler errado: as requisições aparecem em tun0, as respostas nunca.
Uma regra masquerade no host VPN elimina a necessidade dessa rota estática: iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE. Ela também esconde os endereços de origem reais, o que torna cada pergunta posterior sobre logs mais difícil. Um host de destino com o gateway padrão errado produz o mesmo silêncio, com um redirecionamento ICMP no melhor caso e um buraco negro no normal, e por isso a captura pertence aos dois extremos.
Passo 4: escolha um reparo com o qual possa conviver
Cinco reparos são usados para isso, e eles não são intercambiáveis. Escolha pelo que precisa continuar alcançável ao mesmo tempo, não pelo comando mais 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 são a opção barata e a primeira a que as pessoas recorrem. A mudança vale para a interface, então funciona enquanto o túnel está no ar, e pertence a um script ao lado do cliente, não a um shell que você vai esquecer. Não pode dar acesso simultâneo ao mesmo endereço em duas redes, e esse é o limite que manda todos os outros para o resto da tabela.
Renumerar a LAN de casa para 10.10.0.0/24 é a solução limpa: uma renovação de concessão DHCP mais as reservas, as filas de impressão e os endereços codificados que mencionam a faixa antiga. Renumerar o lado do escritório normalmente não é sua decisão. O IPv6 elimina a colisão por completo quando as duas redes o suportam, usando um prefixo local único de fd00::/8 em vez de algo memorizável, mas teste a aplicação por TCP, não com ping, porque o ICMP pode funcionar enquanto o serviço não.
A própria opção de tradução do OpenVPN é o último recurso, enviada do servidor para uma entrada de diretório específica do cliente. Ela recebe quatro parâmetros após o nome da opção — direção, rede, máscara e alias — e o alias não é 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 são a faixa que o cliente vê (192.168.2.0/24), o alias é a faixa real do escritório no lado do servidor (192.168.1.0/24), e a rota enviada é o que torna essa faixa visível alcançável. O escritório aparece então para aquele cliente sob 192.168.2.x. Documente o mapeamento no perfil, ou a próxima pessoa vai depurá-lo como falha de roteamento.
Publicar um único serviço é a versão estreita da tradução, e não precisa da opção do OpenVPN de jeito nenhum. Uma regra DNAT no host VPN republica uma única porta, então a LAN mantém seus endereços e alcança o serviço no endereço de host que já conhece. O custo é o de sempre: o serviço vê o host VPN como origem, então logs por cliente e consultas reversas deixam de significar algo. Isso cobre uma fila de impressão ou uma página de administração, não hosts dos dois lados que se alcançam.
O que ainda não vai funcionar e o que registrar
O broadcast não atravessa um túnel roteado. DLNA, UPnP, a navegação NetBIOS e Wake-on-LAN dependem de broadcast ou multicast que um dispositivo tun não carrega, então nenhuma rota conserta a descoberta. A ponte com dev tap estende o segmento, e com ele os broadcasts de DHCP, ARP e qualquer outro pacote de descoberta; prefira uma rota de host unicast como route 192.168.2.1 255.255.255.255 para o endereço do lado LAN de um roteador remoto.
Dois roteadores que usam ambos 192.168.1.1 no mesmo caminho pertencem à mesma família de problemas: o endereço local sempre vence, então a página do roteador distante continua inalcançável até uma LAN se mudar. Adicionar um segundo adaptador não muda nada em nenhum dos dois casos.
Anote as evidências antes de editar qualquer coisa: ip route get ou Find-NetRoute, ping -c 3 para o endereço em questão, um traceroute, e tcpdump -ni tun0 icmp no cliente, depois a tabela de roteamento e os contadores NAT no servidor. Um ping que funciona num sentido e morre no outro aponta o caminho de volta, não o túnel, e essa única distinção decide qual dos reparos acima você precisa de fato.