Abres una sucursal nueva, un kiosco, una oficina pequeña en otra ciudad. El único internet disponible ahí es un plan casero de cable, un módem 4G o una fibra residencial: sin IP pública fija, detrás del CGNAT del proveedor, con una dirección que cambia sola. El consejo tradicional dice que para unir ese sitio a tu red corporativa necesitas contratar un enlace dedicado con IP fija. Y no siempre es cierto: con una VPN dial-up, ese internet "sencillo" basta para enlazarte a tu matriz. No es lo ideal —ya veremos por qué—, pero conecta a un sitio que, de otro modo, se quedaría fuera.
Qué es una VPN dial-up
En una VPN site-to-site clásica, los dos extremos tienen IP pública fija y cualquiera puede iniciar el túnel. En una dial-up el reparto de papeles es asimétrico: hay un concentrador (hub) en la matriz —el único que necesita IP pública fija, o un nombre estable— y los sitios remotos son clientes que "marcan" hacia él. El nombre es un guiño al viejo dial-up telefónico: el remoto es quien llama, el central quien contesta. El remoto nunca recibe la llamada; siempre la hace.
Por qué funciona con un internet cualquiera
Aquí está el truco, y es más simple de lo que parece: el sitio remoto solo hace una conexión saliente, exactamente igual que tu laptop cuando abre una página web. No necesita que nadie desde afuera pueda "alcanzarlo". Por eso funciona:
- Detrás de CGNAT —donde el proveedor te comparte una IP pública con cientos de clientes y no puedes abrir puertos—: el túnel sale, y con eso basta.
- Con IP dinámica que cambia cada tanto: como el remoto siempre inicia, no importa qué dirección tenga hoy.
- En 4G/LTE, cable o fibra residencial: cualquier acceso que permita salir a Internet sirve de portador.
El único que sí necesita una dirección estable es el hub —uno solo, en la matriz—. Todo el "no tengo IP pública" del lado remoto deja de ser un problema.
Qué lo sostiene por dentro
Para que ese túnel se levante y se quede arriba entran en juego tres piezas, sin misterio: NAT-T (encapsular en UDP 4500) para cruzar el NAT del proveedor; keepalives/DPD, pequeños latidos que mantienen viva la sesión y el mapeo del NAT para que no se "duerma"; y un direccionamiento asignado por el hub a cada remoto, para saber por dónde regresarle el tráfico. La autenticación se resuelve con llave precompartida por sitio o, mejor, con certificados. Nada de esto lo ve el usuario de la sucursal: para él, la caja simplemente conecta.
Lo honesto: por qué no es lo ideal
Que funcione no significa que sea gratis en calidad. Un internet de best-effort no trae garantías, y eso tiene consecuencias que conviene tener claras antes de decidir:
- Sin SLA. Latencia, jitter y pérdida variables. Perfecto para un punto de venta, correo o telemetría ligera; arriesgado para voz o cualquier cosa en tiempo real que no perdone microcortes.
- Sin alcance entrante. No puedes exponer directamente un servicio que viva en el sitio remoto; todo entra y sale por el túnel.
- El tráfico entre sucursales pasa por el hub. Dos remotos que quieran hablarse hacen escala en la matriz (más latencia), a menos que uses auto-descubrimiento —como ADVPN en Fortinet— que arma atajos directos bajo demanda.
- El hub es un punto único de falla si no lo respaldas con un segundo concentrador.
Por eso la regla práctica es sencilla: dial-up sobre internet común es excelente para aperturas rápidas, sitios temporales, ubicaciones donde no llega o no se justifica un dedicado, y como ruta de respaldo. Cuando el sitio corre voz, necesita alta disponibilidad, mueve mucho tráfico o cae bajo un requisito de cumplimiento, ahí sí toca subir a un enlace dedicado con VPN site-to-site.
Nosotros usamos las dos según el caso. En el despliegue de una cadena de retail tejimos un full-mesh sobre enlaces dedicados, porque cada tienda tenía dirección fija y el negocio no podía negociar con la disponibilidad. Pero cuando lo que hay es un internet sencillo, la elegancia del dial-up es justamente esa: nadie se queda fuera de la red por no tener una IP pública.