Una VM Azure ha bisogno del tunnel: client guest o gateway VPN?

Un carico di lavoro in una VM Azure deve raggiungere una rete privata attraverso un tunnel. La domanda che decide il progetto non è quale prodotto VPN sia migliore, ma se un'altra macchina avrà mai bisogno di quel percorso. Rispondete prima a questo e il resto dell'architettura di solito si sceglie da sola. Se sbagliate, ereditate una VM che è diventata silenziosamente un router che nessuno ha documentato.

Due lavori che si somigliano

Una VM può essere un endpoint o un punto di transito, e la differenza non è il software che installate ma chi consuma il tunnel. Come endpoint, il guest esegue un client per i propri processi. Come punto di transito, inoltra i pacchetti di altri carichi di lavoro, il che la rende parte della topologia di rete.

La maggior parte delle richieste per una sola VM è il primo lavoro vestito con il linguaggio del secondo. Qualcuno dice «la VM è la nostra VPN» quando intende che un'applicazione su di essa deve raggiungere un database dall'altra parte.

Condizione uno: qualcos'altro ha bisogno del lato remoto?

Se la risposta è no, installate il client nel guest e smettete di progettare. Nulla in quella scelta richiede il gateway gestito e nulla in essa rende la VM un gateway per i suoi vicini. State aggiungendo una route dentro un solo sistema operativo.

Se la risposta è sì, o probabilmente sì entro un anno, trattatelo ora come un progetto di rete. Altre VM raggiungono una VM di transito solo quando la tabella di route della subnet le manda lì e la NIC accetta il traffico inoltrato, quindi il lavoro è tabelle di route e autorizzazioni all'inoltro, non un'altra installazione di client.

Condizione due: riuscite a mantenere il percorso di amministrazione?

Un client VPN che installa una route ampia può catturare il percorso con cui amministrate la VM. Se l'elenco delle destinazioni del tunnel si sovrappone alla rete di gestione, la sessione SSH o RDP cade nel momento in cui il client si connette, e la correzione va applicata tramite la console seriale o una ricostruzione.

Verificate prima e dopo. Su Linux, ip route get <management-ip> indica quale interfaccia e quale sorgente il kernel userebbe adesso; confrontatelo con la risposta mentre il tunnel è attivo. Un tunnel diviso con un elenco esplicito di destinazioni è più facile da difendere di una route predefinita, e di solito è ciò che il carico di lavoro richiede davvero.

Condizione tre: chi lo aggiorna a mezzanotte?

Un client guest è il vostro sistema operativo, la vostra versione del client e i vostri certificati. Va bene quando gestite già la VM e il suo ciclo di patch. È un cattivo scambio quando la VM esiste solo per sostenere il tunnel. Contate le ore di patch prima di definire più economico il client guest. Un aggiornamento del client che richiede un riavvio è un'interruzione che avete pianificato per una macchina che esiste per tenere su il tunnel.

Il gateway gestito sposta quella manutenzione sulla piattaforma. Possedete ancora identità, autorizzazione e i percorsi di rete dietro di esso, ma non riavviate una macchina per applicare un aggiornamento del client.

Ciò che il gateway gestito non fa

Azure VPN Gateway è un servizio di connettività VNet con le proprie soluzioni site-to-site e point-to-site. Non è una regola che vieti software VPN nel guest e non è un sostituto diretto di un client che un'applicazione richiede.

Ciò che offre è una connessione a livello di rete, raggiungibile da molti carichi di lavoro tramite instradamento. Ciò che non offre è un tunnel usato solo da un processo su una VM, limitato all'identità di quel processo. Questo ambito non è un limite di cui scusarsi; è proprio il senso del progetto con client guest. Un'applicazione, una route, un insieme di credenziali, nessun effetto sulle altre VM della subnet.

Quindi il confronto non è gestito contro software. È connettività con ambito di rete contro connettività con ambito di processo, e la seconda è legittima quando solo un processo ne ha bisogno.

Pianificate il percorso di crescita prima di averne bisogno

Se il requisito cresce da una VM a una subnet, ricostruite il progetto invece di ampliare i prefissi consentiti del client. Riusare una sessione comoda come router non documentato lega ogni consumatore alla vita di quella VM, alle sue credenziali e alla sua finestra di patch.

Il punto di partenza corretto, una volta che la connessione è con ambito di rete e non di carico di lavoro, è la panoramica di Azure VPN Gateway.

Prima di scegliere, scrivete tre righe: cosa ha bisogno del lato remoto, chi amministra la VM e chi aggiorna il tunnel. Se tutte e tre le risposte indicano un solo carico di lavoro, un client guest è il progetto onesto. Se una di esse indica una subnet, progettate subito il livello di rete.