Ningunha ruta arranxa un grupo VPN que se solapa coa túa LAN

A aplicación afirma que o túnel está san e, con todo, a metade dos destinos que necesitas nunca responden. O reflexo é engadir unha ruta ou baixar unha métrica, e ese reflexo é o mito que hai que matar primeiro. Cando a LAN propia do cliente e o grupo do túnel reclaman o mesmo prefixo, a táboa de rutas sostén dous feitos incompatibles, e nin unha ruta por defecto nin unha métrica os resolve. A reparación é unha decisión de direccionamento, e ningunha edición de rutas a substitúe.

Por que unha ruta extra non pode dividir un só prefixo

Unha ruta non pode separar dúas reclamacións sobre un prefixo, por iso o sensato é deixar de buscar a liña de ruta correcta. A pila non colocará un prefixo idéntico diante da ruta conectada, e unha entrada máis específica si captura o enderezo, pero deixa inalcanzable o host local que o posúe. O que parece un problema de enrutamento é unha colisión de direccionamento, e as dúas reparacións cambian enderezos en lugar de rutas. Proba a afirmación na túa propia máquina antes de aceptala.

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

Pregunta ao sistema por un só enderezo e fixa a atención en que interface nomea. Linux, macOS e Windows responden cunha consulta só de lectura que informa da interface escollida e do seguinte salto sen transmitir nada. Cando a resposta apunta ao adaptador físico mentres o túnel está activo, o núcleo trata o enderezo como on-link e non como algo que o túnel puidese transportar.

Pon o prefixo que concedeu o provedor xunto ao que serve o router da casa e compáraos como cadeas. A coincidencia exacta é o caso claro, e un grupo máis amplo do provedor que conteña a subrede da casa falla igual, aínda que é máis fácil pasalo por alto. Dous prefixos que só se parecen non son unha colisión, así que anota ambos antes de cambiar nada.

Le o grupo que o cliente recibiu de verdade

Le o que recibiu o cliente, non a páxina de márketing do provedor. Sube o detalle do rexistro dun cliente OpenVPN e as rutas que empurra o servidor aparecerán nel, revelando os prefixos do túnel; noutros lugares o grupo aparece nos detalles da conexión ou no propio adaptador. Pide ao provedor a lista completa de rangos privados que usa, porque un só /24 hoxe pode ser dous mañá. Evitar os bloques RFC 1918 habituais non é o mesmo que evitar a asignación que realmente che deron.

Un grupo tamén pode encollerse ou mudarse entre rexións, así que a lista necesita unha data e un responsable. Trata calquera resposta do provedor máis antiga que o teu último cambio de plan como unha conxectura, non como un feito. Pregunta de novo antes de comprometerte cun rango, e garda a resposta coas notas de rede para que a seguinte persoa herde a proba.

A renumeración é a reparación que podes facer

Se o servidor VPN non é teu para cambialo, mover a LAN da casa é a única reparación dispoñible, e esa é a situación habitual cun provedor comercial. Escolle un rango fóra do grupo do provedor e fóra dos rangos que poidas necesitar máis adiante, e compróbao contra cada outro sitio ao que chegas por un túnel. Espera unha interrupción curta e unha cola máis longa de dispositivos esquecidos: un que aínda conserva o enderezo antigo parece funcionar ata que necesita a pasarela.

1. Primeiro o inventario: o enderezo do propio router, o ámbito DHCP, as reservas, as redireccións de porto e calquera dispositivo cuxo enderezo se escribise a man.
2. Despois cambia o prefixo LAN do router e o ámbito DHCP á vez dentro dunha xanela de mantemento, e renova os contratos por cable antes que os sen fíos.
3. A continuación corrixe os enderezos estáticos: impresoras, almacenamento en rede, calquera cousa cunha pasarela codificada.
4. Por último, reconecta o cliente VPN e confirma que o enderezo do túnel xa non choca coa LAN.

Percorre os enderezos nesa orde e non todos á vez, e deixa o rango antigo documentado un tempo para que un dispositivo obsoleto sexa recoñecible en lugar de misterioso. Un dispositivo que nunca renova anúnciase fallando ao chegar á pasarela, o que é unha pista moito mellor que unha chamada ao soporte. Se o router entrega contratos de máis dun día, acúrtaos durante a xanela.

Que pode e que non pode facer un alias

Cando o servidor é teu, traducir enderezos no cliente pode expoñer o prefixo remoto dentro dun rango local libre, de xeito que o mesmo host responde nun segundo enderezo. O OpenVPN comunitario faino con client-nat, e esa directiva é específica dese cliente, ausente nos clientes comerciais e móbiles cos que a xente adoita comparala. O montaxe necesita unha ruta que coincida coa tradución, un rango libre para o alias e un servidor disposto a responder ao enderezo non traducido do cliente. Nada diso axuda cando o cliente pertence a un provedor xestionado que non podes configurar.

Cando o cambio entre en vigor, chega a un host local e a un remoto primeiro por enderezo e despois por nome, anotando a ruta que o sistema escolle cada vez. Un nome aínda pode resolverse no rango antigo, así que enderezos e nomes merecen comprobacións independentes. Reinicia un cliente e un dispositivo do lado do servidor se algún seguiu aceso durante o cambio, porque as entradas de veciño na caché sobreviven á edición.

Escribe os prefixos nos que quedaches onde a xente mira de verdade: as notas de rede, o campo de comentarios do router, a páxina de benvida. Alguén volverá escoller 192.168.1.0/24, e a colisión volverá con el.