Casa i oficina fan servir tots dos 192.168.1.x: i ara què?

Recorreu quatre comprovacions: a quina adreça es resol el nom, quin prefix fa servir la xarxa local, quina ruta tria el nucli per a aquesta destinació i què respon a l’extrem llunyà. L’inici de sessió de la VPN no és una d’elles, perquè es completa independentment de quina xarxa guanyi. Feu les comprovacions en ordre i la superposició es farà visible al segon pas en lloc del quart.

Un inici de sessió correcte diu que el túnel està aixecat; no diu res sobre on apunta una adreça concreta.

Una adreça, dues màquines

Un amfitrió tria un camí de la seva taula d’encaminament i de les regles de política, fent servir l’adreça de destinació. Res no li diu que una petició al salt 192.168.1.20 està pensada per al servidor de l’oficina i no per a un dispositiu de la sala del costat. Amb les dues xarxes en el mateix rang privat, guanya la ruta més específica i tota la resta depèn de quina entrada va instal·lar una reconnexió. Res a l’adreça mateixa no porta aquesta distinció.

ip route get 192.168.1.20

Aquesta consulta anomena la interfície i el salt següent que va triar el nucli, que és la segona comprovació de la llista. Compareu els prefixos local i remot abans de fer res més. Si la LAN local és 192.168.1.0/24 i el lloc remot també és 192.168.1.0/24, la superposició és la troballa i cap opció del client la repara.

Renumereu el costat que controleu

Un encaminador personal sol ser el costat més fàcil de moure. Trieu un rang que no xoqui amb les xarxes remotes que realment feu servir, i tingueu en compte que 10.x.x.x tampoc no és lliure automàticament, perquè molts llocs el fan servir. Planifiqueu el canvi: les concessions DHCP, les adreces reservades, les cues d’impressió i qualsevol cosa amb una adreça codificada necessiten atenció. Feu la renumeració en una finestra en què pugueu recuperar l’encaminador sense la VPN.

Comproveu la llista de prefixos remots primer, no després. Triar un rang nou que xoqui amb un altre lloc d’oficina produeix el mateix problema amb més feina invertida.

Quan cap dels dos costats no pot canviar

Si cap de les dues xarxes no es pot renumerar, les opcions restants viuen al servidor. Una passarel·la pot traduir una xarxa remota en una subxarxa diferent per als clients de VPN, fent servir NAT basat en polítiques o una variant bidireccional, de manera que el client veu una adreça única. Això és un disseny de passarel·la i no un commutador que proporcioni cada client d’escriptori, i canvia quina adreça escriuen els usuaris i quins noms han de coincidir. Una ruta copiada d’un fòrum no pot distingir dues destinacions idèntiques.

Els rangs d’adreces privades continuen sent privats; el problema és la reutilització, no els rangs en si.

Demostreu quina màquina ha respost

openssl s_client -connect 192.168.1.20:443 -servername office.example 2>/dev/null | openssl x509 -noout -subject

Després de qualsevol canvi, proveu el recurs de l’oficina i els dispositius locals alhora. Si un dispositiu domèstic conegut respon on hauria de ser el servidor de l’oficina, o el certificat TLS anomena un amfitrió equivocat, atureu-vos i identifiqueu la destinació abans de continuar. Obtenir una resposta d’aquella adreça no estableix quina màquina la va enviar. Comprovar el subjecte del certificat és un dels pocs senyals fiables disponibles en aquell moment.

No substituïu les adreces privades de l’oficina per adreces públiques arbitràries que no controleu. Això canvia una superposició per un problema d’encaminament i propietat que és pitjor i més difícil d’explicar.

Anoteu el prefix local, el prefix remot i el canvi que ho va resoldre. La propera superposició semblarà diferent però seguirà el mateix patró.