Cap ruta arregla un pool VPN que se solapa amb la teva LAN

L'aplicació assegura que el túnel és sa, i tot i així la meitat de les destinacions que necessites no responen mai. El reflex és afegir una ruta o baixar una mètrica, i aquest reflex és el mite que cal matar primer. Quan la LAN pròpia del client i el pool del túnel reclamen el mateix prefix, la taula d'encaminament té dos fets incompatibles, i ni una ruta per defecte ni una mètrica els resol. La reparació és una decisió d'adreçament, i cap edició de rutes no la substitueix.

Per què una ruta extra no pot dividir un sol prefix

Una ruta no pot separar dues reclamacions sobre un mateix prefix, i per això el moviment sensat és deixar de buscar la línia de ruta correcta. La pila no col·locarà un prefix idèntic davant de la ruta connectada, i una entrada més específica sí que captura l'adreça, però deixa inaccessible l'amfitrió local que la posseeix. El que sembla un problema d'encaminament és una col·lisió d'adreces, i les dues reparacions canvien adreces, no rutes. Prova aquesta afirmació a la teva màquina abans d'acceptar-la.

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

Pregunta al sistema per una sola adreça i fixa't en quina interfície anomena. Linux, macOS i Windows responen amb una consulta de només lectura que informa de la interfície triada i del salt següent sense transmetre res. Quan la resposta apunta a l'adaptador físic mentre el túnel és actiu, el nucli tracta l'adreça com a enllaç directe i no com una cosa que el túnel podria portar.

Posa el prefix que ha concedit el proveïdor al costat del que serveix el router de casa i compara'ls com a cadenes. La coincidència exacta és el cas clar, i un pool més ampli del proveïdor que contingui la subxarxa de casa falla igual, però és més fàcil de passar per alt. Dos prefixos que només semblen similars no són cap col·lisió, així que anota tots dos abans de canviar res.

Llegeix el pool que el client ha rebut de debò

Llegeix què ha rebut el client, no la pàgina de màrqueting del proveïdor. Apuja el detall del registre d'un client OpenVPN i les rutes que empeny el servidor hi apareixeran, revelant els prefixos del túnel; en altres llocs el pool surt als detalls de la connexió o al mateix adaptador. Demana al proveïdor la llista completa de rangs privats que utilitza, perquè una sola /24 avui pot ser-ne dues demà. Evitar els blocs RFC 1918 habituals no és el mateix que evitar l'assignació que realment t'han donat.

Un pool també pot encongir-se o moure's entre regions, així que la llista necessita una data i un responsable. Tracta qualsevol resposta del proveïdor més antiga que el teu últim canvi de pla com una conjectura, no com un fet. Torna a preguntar abans de comprometre't amb un rang, i guarda la resposta amb les notes de xarxa perquè la següent persona hereti la prova.

La renumeració és la reparació que pots fer

Si el servidor VPN no és teu per canviar-lo, moure la LAN de casa és l'única reparació disponible, i aquesta és la situació habitual amb un proveïdor comercial. Tria un rang fora del pool del proveïdor i fora dels rangs que puguis necessitar més endavant, i comprova'l contra cada altre lloc a què arribes per un túnel. Espera una interrupció curta i una cua més llarga de dispositius oblidats: un que encara té l'adreça antiga sembla funcionar fins que necessita la passarel·la.

1. Primer inventari: l'adreça del mateix router, l'àmbit DHCP, les reserves, les redireccions de port i qualsevol dispositiu amb l'adreça escrita a mà.
2. Després canvia el prefix LAN del router i l'àmbit DHCP alhora dins d'una finestra de manteniment, i renova els contractes de cable abans que els sense fil.
3. A continuació corregeix les adreces estàtiques: impressores, emmagatzematge de xarxa, qualsevol cosa amb una passarel·la codificada.
4. Finalment, reconnecta el client VPN i confirma que l'adreça del túnel ja no xoca amb la LAN.

Recorre les adreces en aquest ordre i no totes de cop, i deixa el rang antic documentat un temps perquè un dispositiu obsolet sigui recognoscible i no misteriós. Un dispositiu que no renova mai s'anuncia fallant a arribar a la passarel·la, cosa que és un indici molt millor que una trucada al suport. Si el router lliura contractes de més d'un dia, escurça'ls durant la finestra.

Què pot i què no pot fer un àlies

Quan el servidor és teu, traduir adreces al client pot exposar el prefix remot dins d'un rang local lliure, de manera que el mateix amfitrió respon en una segona adreça. L'OpenVPN comunitari ho fa amb client-nat, i aquesta directiva és específica d'aquell client, absent dels clients comercials i mòbils amb què la gent la compara habitualment. El muntatge necessita una ruta que coincideixi amb la traducció, un rang lliure per a l'àlies i un servidor disposat a respondre a l'adreça no traduïda del client. Res d'això ajuda quan el client pertany a un proveïdor gestionat que no pots configurar.

Quan el canvi entri en vigor, arriba a un amfitrió local i a un de remot primer per adreça i després per nom, anotant la ruta que el sistema tria cada vegada. Un nom encara pot resoldre's al rang antic, així que adreces i noms mereixen comprovacions independents. Reinicia un client i un dispositiu del costat del servidor si algun va quedar engegat durant el canvi, perquè les entrades de veïnat en memòria cau sobreviuen a l'edició.

Escriu els prefixos on has decidit quedar-te allà on la gent mira de debò: les notes de xarxa, el camp de comentari del router, la pàgina d'acollida. Algú tornarà a triar 192.168.1.0/24, i la col·lisió tornarà amb ell.