Añada una VPN de sitio junto al router del ISP sin cortar las llamadas

La mayoría de las sedes pequeñas ya tienen un equipo que hace internet, DHCP y la línea de voz, y ese equipo no va a llevar el túnel de su sede. Añadir una segunda puerta de enlace para la ruta privada funciona si antes de tocar un cable decide quién es dueño de cada ruta. El riesgo real no es el túnel; es cambiar en silencio el dispositivo que mantiene los teléfonos registrados. Haga las cinco comprobaciones en orden y deténgase donde una falle.

Anote las funciones que ya funcionan

Registre la puerta de enlace predeterminada, el servidor DHCP, el resolutor y el dispositivo que tiene el registro de voz del proveedor. En este ejemplo el router del ISP es 10.50.0.1, la nueva puerta de enlace será 10.50.0.2 y la sede remota es 10.60.0.0/24. Nada de ese plan cambia las tres primeras funciones, y ese es justamente el punto. Después confirme que el segundo equipo puede terminar de verdad el túnel: revise el protocolo, el rendimiento esperado y si recibe actualizaciones de firmware o de paquetes. Un dispositivo con logotipo de VPN y sin ruta de actualización es una carga, no un añadido.

Si no puede decir quién es dueño del servicio de voz, deténgase. Cambiar el router que tiene un registro sin un plan de reversión convierte un proyecto de VPN en una caída telefónica.

Dé a la nueva puerta de enlace una dirección y una tarea

Reserve su dirección LAN fuera del grupo DHCP para que no se mueva tras un reinicio, y no le dé una ruta predeterminada propia salvo que quiera que sea una ruta de internet. Su tarea es mantener el túnel y responder por los prefijos remotos. En los equipos de la LAN que deben llegar a la sede remota, demuestre qué ruta usan ahora y cuál quiere después del cambio; los mismos dos comandos antes y después son la prueba más barata.

ip route get 10.60.0.55
ip neigh show 10.50.0.2
traceroute -n 10.60.0.55

Si la consulta devuelve el router del ISP y el traceroute muere en el borde de internet, el equipo aún no tiene ruta remota, lo cual es esperable. Si devuelve algo inesperado, resuélvalo primero, porque cada paso posterior da por sentada esta base.

Elija quién es dueño de la ruta del prefijo remoto

La opción A es el router del ISP: mantiene una ruta estática para 10.60.0.0/24 hacia la puerta de enlace y cada equipo sigue su puerta de enlace predeterminada como antes. La opción B es por equipo: solo las máquinas que necesitan la sede remota reciben una ruta explícita por 10.50.0.2, y todo lo demás queda intacto. A es más limpia para muchos equipos, pero suele exigir que el router del proveedor acepte una ruta estática, cosa que algunos no hacen. B no necesita cooperación del proveedor, pero le deja el mantenimiento de la configuración de los equipos, así que encaja con un conjunto pequeño de máquinas aprobadas.

En ambos casos debe existir la dirección de vuelta. Si una respuesta remota llega a la puerta de enlace y esta la reenvía directamente a un equipo de la LAN, el tráfico se salta el estado de cortafuegos que el router del ISP mantenía en el camino de ida. Cuando la puerta de enlace no es el router predeterminado de la LAN, esa asimetría es una decisión de diseño, no un fallo que pueda ignorarse.

ip route add 10.60.0.0/24 via 10.50.0.2 dev eth0
ip route get 10.60.0.55 from 10.50.0.77

Haga permanente la entrada a través del dueño de la configuración del equipo, no de un script de inicio de sesión. Una ruta que solo existe después de que alguien inicie sesión fallará la primera vez que la máquina se reinicie por un motivo ajeno.

Prepare un punto de entrada accesible

La puerta de enlace necesita una dirección a la que la sede remota pueda llegar. Detrás del router del ISP eso significa una redirección de puertos o una entrada DMZ, y ambas dependen de que el proveedor entregue de verdad el tráfico. Una redirección local no supera el NAT de nivel de operador del lado del proveedor. Si el proveedor no da un punto accesible, invierta la dirección: deje que ambas sedes inicien hacia un concentrador que usted controle. Es un diseño válido, pero añade una tercera dependencia para el reenvío, la confianza y la disponibilidad, y el DNS dinámico no la sustituye.

Confirme la redirección con una captura en la puerta de enlace, no con un sitio web que escanee puertos. Los escáneres informan del puerto cerrado hasta que el escucha se enlaza, y una redirección que nunca entrega tráfico se ve desde fuera igual que un puerto cerrado.

Acepte el servicio privado y la línea de voz a la vez

Pruebe el funcionamiento previsto desde un equipo de la LAN, con DNS privado y las credenciales de la propia aplicación. Un túnel enrutado no hace que la navegación remota parezca un segmento Ethernet local, así que el descubrimiento y la resolución de nombres necesitan sus propios arreglos.

curl -sS -o /dev/null -w '%{http_code}\n' https://files.example.net
ping -c 3 10.60.0.55

Luego confirme que el acceso normal a internet sigue funcionando desde el mismo equipo y que los teléfonos siguen registrados; esas dos comprobaciones atrapan un cambio accidental de la ruta predeterminada, la forma más habitual de que este proyecto rompa algo que nunca quiso tocar. Termine con una nota de recuperación escrita: qué dispositivo tiene cada función, las direcciones reservadas y cómo quitar la ruta del prefijo remoto en un solo paso. Una ruta privada que se puede retirar limpiamente vale más que una que solo funciona hoy.