Unha VM de Azure necesita o túnel: cliente convidado ou pasarela VPN?

Unha carga de traballo nunha VM de Azure ten que chegar a unha rede privada a través dun túnel. A pregunta que decide o deseño non é que produto VPN é mellor, senón se algunha outra máquina necesitará algún día ese camiño. Responda iso primeiro e o resto da arquitectura adoita escollerse só. Se se equivoca, herda unha VM que en silencio se converteu nun enrutador que ninguén documentou.

Dous traballos que se parecen

Unha VM pode ser un punto final ou un punto de tránsito, e a diferenza non é o software que instala senón quen consume o túnel. Como punto final, o convidado executa un cliente para os seus propios procesos. Como punto de tránsito, reenvía os paquetes doutras cargas de traballo, o que a converte en parte da súa topoloxía de rede.

A maioría das peticións dunha soa VM son o primeiro traballo coa linguaxe do segundo. Alguén di «a VM é o noso VPN» cando quere dicir que unha aplicación nela ten que chegar a unha base de datos do outro lado.

Condición unha: necesita algo máis o lado afastado?

Se a resposta é non, instale o cliente no convidado e deixe de deseñar. Nada desa escolla esixe a pasarela xestionada e nada nela converte a VM nunha pasarela para os seus veciños. Está a engadir unha ruta dentro dun só sistema operativo.

Se a resposta é si, ou probablemente si nun ano, tráteo agora como un deseño de rede. Outras VM chegan a unha VM de tránsito só cando a táboa de rutas da subrede as envía alí e a NIC acepta o tráfico reenviado, así que o traballo é táboas de rutas e permisos de reenvío, non outra instalación de cliente.

Condición dúas: pode conservar o camiño de administración?

Un cliente VPN que instala unha ruta ampla pode capturar o camiño co que administra a VM. Se a lista de destinos do túnel se solapa coa rede de xestión, a súa sesión SSH ou RDP cae no momento en que o cliente se conecta, e a corrección ten que aplicarse pola consola serie ou mediante unha reconstrución.

Comprobe antes e despois. En Linux, ip route get <management-ip> indica que interface e que orixe usaría o núcleo agora mesmo; compáreo coa resposta mentres o túnel está activo. Un túnel dividido cunha lista explícita de destinos é máis doado de defender que unha ruta por defecto, e adoita ser o que a carga de traballo realmente necesita.

Condición tres: quen o parchea a medianoite?

Un cliente convidado é o seu sistema operativo, a súa versión de cliente e os seus certificados. Iso está ben cando xa opera a VM e o seu ciclo de parches. É un mal negocio cando a VM só existe para soster o túnel. Contabilice as horas de parcheo antes de chamar máis barato ao cliente convidado. Unha actualización de cliente que esixe reiniciar é unha interrupción que vostede programou para unha máquina que existe para manter o túnel en pé.

A pasarela xestionada traslada ese mantemento á plataforma. Vostede segue a ser dono da identidade, a autorización e as rutas de rede detrás, pero non reinicia unha máquina para aplicar unha actualización de cliente.

O que a pasarela xestionada non fai

Azure VPN Gateway é un servizo de conectividade de VNet cos seus propios axustes de sitio a sitio e de punto a sitio. Non é unha regra que prohiba software VPN no convidado nin é un substituto directo dun cliente que unha aplicación necesita.

O que ofrece é unha conexión na capa de rede, alcanzable por moitas cargas de traballo mediante enrutamento. O que non ofrece é un túnel que só use un proceso nunha VM e que estea limitado á identidade dese proceso. Ese alcance non é unha limitación da que haxa que desculparse; é xustamente o sentido do deseño con cliente convidado. Unha aplicación, unha ruta, un conxunto de credenciais, ningún efecto sobre as demais VM da subrede.

Así que a comparación non é xestionado fronte a software. É conectividade de alcance de rede fronte a conectividade de alcance de proceso, e a segunda é lexítima cando só un proceso a necesita.

Planifique a ruta de crecemento antes de necesitala

Se o requisito crece dunha VM a unha subrede, refaga o deseño en lugar de ampliar os prefixos permitidos do cliente. Reutilizar unha sesión cómoda como enrutador non documentado liga cada consumidor á vida desa VM, ás súas credenciais e á súa xanela de parcheo.

O punto de partida correcto, unha vez que a conexión é de alcance de rede e non de carga de traballo, é a visión xeral de Azure VPN Gateway.

Antes de escoller, escriba tres liñas: que necesita o lado afastado, quen administra a VM e quen parchea o túnel. Se as tres respostas apuntan a unha soa carga de traballo, un cliente convidado é o deseño honesto. Se calquera delas apunta a unha subrede, deseñe a capa de rede agora.