Una Azure VM necessita el túnel: client convidat o passarel·la VPN?

Una càrrega de treball en una Azure VM ha d'arribar a una xarxa privada a través d'un túnel. La pregunta que decideix el disseny no és quin producte VPN és millor; és si alguna altra màquina necessitarà mai aquest camí. Responeu això primer i la resta de l'arquitectura normalment es tria sola. Si us equivoqueu, hereteu una VM que va esdevenir en silenci un encaminador que ningú no va documentar.

Dues feines que s'assemblen

Una VM pot ser un punt final o un punt de trànsit, i la diferència no és el programari que instal·leu sinó qui consumeix el túnel. Com a punt final, el convidat executa un client per als seus propis processos. Com a punt de trànsit, reenvia els paquets d'altres càrregues, cosa que el converteix en part de la topologia de xarxa.

La majoria de peticions d'una sola VM són la primera feina amb el llenguatge de la segona. Algú diu «la VM és la nostra VPN» quan vol dir que una aplicació que hi ha a sobre ha d'arribar a una base de dades de l'altre costat.

Condició primera: hi ha res més que necessiti el costat llunyà?

Si la resposta és no, instal·leu el client al convidat i pareu de dissenyar. Res d'aquesta tria no requereix la passarel·la gestionada i res no converteix la VM en passarel·la per als seus veïns. Esteu afegint una ruta dins d'un sol sistema operatiu.

Si la resposta és sí, o probablement sí d'aquí a un any, tracteu-ho ara com un disseny de xarxa. Les altres VM arriben a una VM de trànsit només quan la taula de rutes de subxarxa les hi envia i la NIC accepta el trànsit reenviat, així que la feina és taules de rutes i permisos de reenviament, no una altra instal·lació de client.

Condició segona: podeu mantenir el camí d'administració?

Un client VPN que instal·la una ruta àmplia pot capturar el camí amb què administreu la VM. Si la llista de destinacions del túnel se solapa amb la xarxa de gestió, la vostra sessió SSH o RDP cau en el moment que el client es connecta, i la correcció s'ha d'aplicar per la consola sèrie o reconstruint.

Comproveu abans i després. A Linux, ip route get <management-ip> us diu quina interfície i quin origen faria servir el nucli ara mateix; compareu-ho amb la resposta mentre el túnel és actiu. Un túnel dividit amb una llista explícita de destinacions és més fàcil de defensar que una ruta per defecte, i normalment és el que la càrrega necessita de debò.

Condició tercera: qui l'actualitza a mitjanit?

Un client convidat és el vostre sistema operatiu, la vostra versió de client i els vostres certificats. Això està bé quan ja gestioneu la VM i el seu cicle d'actualitzacions. És un mal intercanvi quan la VM només existeix per sostenir el túnel. Compteu les hores d'actualització abans de dir que el client convidat és més barat. Una actualització de client que necessita un reinici és una interrupció que heu programat per a una màquina que existeix per mantenir el túnel.

La passarel·la gestionada trasllada aquest manteniment a la plataforma. Encara posseïu la identitat, l'autorització i els camins de xarxa al darrere, però no reinicieu cap màquina per aplicar una actualització de client.

Què no fa la passarel·la gestionada

Azure VPN Gateway és un servei de connectivitat de VNet amb els seus propis arranjaments de lloc a lloc i de punt a lloc. No és una regla que prohibeixi programari VPN al convidat ni és un substitut directe d'un client que una aplicació necessita.

El que us dona és una connexió a la capa de xarxa, abastable per moltes càrregues mitjançant encaminament. El que no us dona és un túnel que només faci servir un procés en una VM i que estigui limitat a la identitat d'aquest procés. Aquest abast no és una limitació de la qual calgui disculpar-se; és precisament el sentit del disseny amb client convidat. Una aplicació, una ruta, un conjunt de credencials, cap efecte sobre les altres VM de la subxarxa.

Així, la comparació no és gestionat contra programari. És connectivitat d'abast de xarxa contra connectivitat d'abast de procés, i la segona és legítima quan només un procés la necessita.

Planifiqueu el camí de creixement abans que calgui

Si el requisit creix d'una VM a una subxarxa, refer el disseny en comptes d'ampliar els prefixos permesos del client. Reutilitzar una sessió convenient com a encaminador no documentat lliga cada consumidor a la vida d'aquesta VM, a les seves credencials i a la seva finestra d'actualitzacions.

El punt de partida correcte, un cop la connexió és d'abast de xarxa i no de càrrega, és la visió general d'Azure VPN Gateway.

Abans de triar, escriviu tres línies: què necessita el costat llunyà, qui administra la VM i qui actualitza el túnel. Si les tres respostes apunten a una sola càrrega, un client convidat és el disseny honest. Si qualsevol d'elles apunta a una subxarxa, dissenyeu la capa de xarxa ara.