Una VM de Azure necesita el túnel: ¿cliente invitado o puerta de enlace VPN?

Una carga de trabajo en una VM de Azure tiene que llegar a una red privada a través de un túnel. La pregunta que decide el diseño no es qué producto VPN es mejor, sino si alguna otra máquina necesitará ese camino alguna vez. Responda eso primero y el resto de la arquitectura suele elegirse sola. Si se equivoca, hereda una VM que en silencio se convirtió en un enrutador que nadie documentó.

Dos trabajos que se parecen

Una VM puede ser un punto final o un punto de tránsito, y la diferencia no es el software que instala sino quién consume el túnel. Como punto final, el invitado ejecuta un cliente para sus propios procesos. Como punto de tránsito, reenvía los paquetes de otras cargas de trabajo, lo que la convierte en parte de su topología de red.

La mayoría de las peticiones de una sola VM son el primer trabajo con el lenguaje del segundo. Alguien dice «la VM es nuestro VPN» cuando quiere decir que una aplicación en ella necesita llegar a una base de datos del otro lado.

Condición uno: ¿algo más necesita el lado lejano?

Si la respuesta es no, instale el cliente en el invitado y deje de diseñar. Nada en esa elección exige la puerta de enlace administrada y nada en ella convierte la VM en puerta de enlace para sus vecinas. Está añadiendo una ruta dentro de un solo sistema operativo.

Si la respuesta es sí, o probablemente sí en un año, trátelo ahora como un diseño de red. Otras VM llegan a una VM de tránsito solo cuando la tabla de rutas de subred las envía allí y la NIC acepta el tráfico reenviado, así que el trabajo es tablas de rutas y permisos de reenvío, no otra instalación de cliente.

Condición dos: ¿puede conservar la ruta de administración?

Un cliente VPN que instala una ruta amplia puede capturar el camino con el que administra la VM. Si la lista de destinos del túnel se solapa con la red de gestión, su sesión SSH o RDP cae en el momento en que el cliente se conecta, y la corrección debe aplicarse por la consola serie o mediante una reconstrucción.

Compruebe antes y después. En Linux, ip route get <management-ip> indica qué interfaz y qué origen usaría el núcleo ahora mismo; compárelo con la respuesta mientras el túnel está activo. Un túnel dividido con una lista explícita de destinos es más fácil de defender que una ruta por defecto, y suele ser lo que la carga de trabajo necesita de verdad.

Condición tres: ¿quién lo parchea a medianoche?

Un cliente invitado es su sistema operativo, su versión de cliente y sus certificados. Eso está bien cuando ya opera la VM y su ciclo de parches. Es un mal negocio cuando la VM existe solo para sostener el túnel. Cuente las horas de parcheo antes de llamar más barato al cliente invitado. Una actualización de cliente que exige reiniciar es una interrupción que usted programó para una máquina que existe para mantener el túnel en pie.

La puerta de enlace administrada traslada ese mantenimiento a la plataforma. Usted sigue siendo dueño de la identidad, la autorización y las rutas de red que hay detrás, pero no reinicia una máquina para aplicar una actualización de cliente.

Lo que la puerta de enlace administrada no hace

Azure VPN Gateway es un servicio de conectividad de VNet con sus propios arreglos de sitio a sitio y de punto a sitio. No es una regla que prohíba el software VPN en el invitado ni es un sustituto directo de un cliente que una aplicación necesita.

Lo que ofrece es una conexión en la capa de red, alcanzable por muchas cargas de trabajo mediante enrutamiento. Lo que no ofrece es un túnel que use solo un proceso en una VM y que esté limitado a la identidad de ese proceso. Ese alcance no es una limitación de la que haya que disculparse; es justo el sentido del diseño con cliente invitado. Una aplicación, una ruta, un conjunto de credenciales, ningún efecto sobre las demás VM de la subred.

Así que la comparación no es administrado frente a software. Es conectividad de alcance de red frente a conectividad de alcance de proceso, y la segunda es legítima cuando solo un proceso la necesita.

Planifique la ruta de crecimiento antes de necesitarla

Si el requisito crece de una VM a una subred, rehaga el diseño en lugar de ampliar los prefijos permitidos del cliente. Reutilizar una sesión cómoda como enrutador no documentado ata a cada consumidor a la vida de esa VM, a sus credenciales y a su ventana de parcheo.

El punto de partida correcto, una vez que la conexión es de alcance de red y no de carga de trabajo, es la introducción a Azure VPN Gateway.

Antes de elegir, escriba tres líneas: qué necesita el lado lejano, quién administra la VM y quién parchea el túnel. Si las tres respuestas apuntan a una sola carga de trabajo, un cliente invitado es el diseño honesto. Si cualquiera de ellas apunta a una subred, diseñe la capa de red ahora.