EC2 Windows: client VPN, server VPN o gateway AWS?
Un'istanza EC2 Windows può eseguire software VPN, ma un client, un server autogestito e un gateway AWS sono ruoli diversi con proprietari diversi.
Un team ha bisogno della connettività VPN per un'applicazione che gira su un'istanza EC2 Windows, trova software client compatibile, lo installa e poi chiede perché il resto del VPC non può usarlo. L'installazione ha funzionato; il ruolo non è mai stato deciso. Il software eseguito all'interno di un guest può essere un client che si unisce alla rete di qualcun altro, un server che accetta altri client, o nessuno dei due prodotti VPN gestiti da AWS, e ogni ruolo lascia un lavoro diverso a te.
Il sintomo è di solito il ruolo sbagliato
Il sintomo comune è un tunnel funzionante che risolve il problema sbagliato. Un client nella VM dà a quella VM un percorso in uscita; non dà al tuo portatile, al tuo ufficio o a un'altra sottorete un modo per entrare. Un server nella VM dà agli altri un modo per entrare, ma ora possiedi il listener, l'autenticazione e l'inoltro.
I servizi gestiti spostano l'esercizio del servizio su AWS e lasciano a te la progettazione. Site-to-Site VPN collega le reti tramite un gateway cliente e un gateway AWS, e Client VPN offre ai dispositivi remoti un endpoint gestito. In entrambi i casi le rotte, le regole di autorizzazione e l'origine dell'identità sono la tua configurazione, e nessuno dei due prodotti installa un client generico dentro un guest Windows.
Sono possibili quattro forme, e la tabella le separa in base a cosa si collega a cosa e chi porta il carico operativo.
| Role | What connects | Who owns the VPN software |
|---|---|---|
| Client in the Windows VM | This VM dials out into someone else's network | You, plus the software vendor |
| Server in the Windows VM | Inbound clients and sites attach to this VM | You, end to end |
| AWS Site-to-Site VPN | Two networks meet through a customer gateway and an AWS gateway | AWS operates the tunnels; you own the peer and route design |
| AWS Client VPN | User devices attach to an endpoint AWS operates | AWS operates it; you own the access rules |
Leggi la riga, non il nome del prodotto: la stessa istanza Windows può trovarsi in due righe diverse a seconda del software che vi viene eseguito.
Client dentro la VM: la VM si unisce a una rete
Un client in uscita deve far verificare la build di Windows, l'architettura e i requisiti dei driver prima di installare qualsiasi cosa. Il client cambierà rotte e DNS sull'istanza, il che può influire sui servizi già in esecuzione, incluso il percorso che usi per l'amministrazione remota. Annota il nome dell'adattatore e la metrica dell'interfaccia impostata dal client, perché la nuova interfaccia può avere la precedenza su quella esistente. Se l'istanza è gestita tramite un gestore di sessioni invece che tramite SSH o RDP, conferma che quel percorso funzioni ancora dopo la connessione del client.
Decidi quale traffico deve trasportare il client prima di abilitarlo. Un tunnel completo può catturare la sessione di gestione e chiuderti fuori, e un tunnel diviso può lasciare che l'istanza raggiunga la rete privata mentre il resto del traffico prende un'altra uscita. Prova con un secondo percorso di gestione disponibile e annota le rotte installate dal client, così che una modifica successiva sia spiegabile.
Server dentro la VM: altri client si uniscono a esso
Per un server autogestito possiedi il listener, il certificato o il materiale della chiave, il database utenti e le regole di inoltro. Se il server inoltra traffico per altri client, l'istanza diventa un router, e questo richiede l'inoltro a livello di guest più modifiche a rotte e gruppi di sicurezza a livello AWS.
Prova il listener dal guest e di nuovo da un'altra sottorete, poi prova un host verso cui l'istanza inoltra. Un servizio locale sano non dimostra nulla sul percorso inoltrato, quindi annota entrambi i risultati nella nota di modifica.
I gateway gestiti conservano il servizio, non la tua progettazione degli accessi
AWS Site-to-Site VPN documenta i ruoli dei tunnel del gateway cliente e del gateway AWS, e acquistare quella connessione non sostituisce ogni progettazione di accesso remoto. Client VPN documenta un endpoint gestito con persone client, mentre le regole di autorizzazione e le rotte di destinazione restano tue. AWS mantiene in funzione l'endpoint e i suoi certificati; chi può raggiungere quale applicazione resta una regola di autorizzazione che scrivi e mantieni.
Scegli tra i prodotti su cinque assi: quale ruolo gioca ciascuno, quali protocolli accetta, quale origine di identità si aspetta, come viene inoltrato il traffico e come viene fornita la disponibilità. Ignora qualsiasi singolo dato di throughput citato in un thread di forum, perché la capacità pubblicata cambia con il servizio. E non presumere che una coppia di tunnel gestiti cambi il comportamento di un client guest arbitrario.
Scegli il ruolo prima del prodotto
Scrivi una frase che nomini la direzione: questa VM si unisce a una rete, questa VM accetta client, oppure un gateway AWS collega reti definite.
Quella frase decide la lista ristretta dei prodotti, il proprietario del software e le modalità di guasto che eseguirai il debug. Se il requisito è che utenti remoti raggiungano un'applicazione, un client installato nella VM dell'applicazione è la forma sbagliata. Se il requisito è che una VM raggiunga la rete di un partner, un gateway sito-a-sito gestito è più macchinario di quanto il compito richieda. Entrambe le risposte sono legittime; solo una corrisponde alla frase che hai scritto.