AWS Client VPN o Site-to-Site: verificate chi apre la connessione

Quattro verifiche lo decidono, e nessuna di esse è il nome del protocollo. Chi apre la connessione, che cosa autentica AWS, come la connessione si aggancia alla vostra rete e quali routing e policy la accompagnano. Rispondete in ordine e la scelta del prodotto di solito si fa da sola; rispondete dopo aver già comprato una progettazione e difenderete un tunnel che risolve la metà sbagliata del problema. Nessuna delle quattro vi chiede di scegliere un cifrario, ed è per questo che una progettazione che parte dal protocollo è di solito il segno che i requisiti non sono mai stati scritti.

Eseguite ogni verifica sul punto di terminazione, sul client e sulla famiglia di indirizzi che intendete realmente usare, non sulla categoria. I prodotti VPN gestiti differiscono dai blocchi OpenVPN e IPsec a cui assomigliano.

Primo, chi apre la connessione

Se ciò che necessita accesso è un portatile, un telefono o la postazione di un solo amministratore, la connessione parte da un dispositivo remoto e la progettazione è accesso client remoto. Se ciò che necessita accesso è una sede piena di macchine dietro un solo router, la connessione parte da quel router e la progettazione è gateway-a-gateway. È la verifica che risolve la maggior parte dei casi, ed è quella che si salta quando una presentazione commerciale ha già inquadrato la conversazione attorno ai cifrari.

Fermatevi qui se non sapete nominare il componente che inizia. Una progettazione che cerca di servire entrambi i casi con un solo tunnel finisce di solito con una sessione client che si spaccia per un gateway.

Secondo, che cosa autentica AWS

Con Client VPN, AWS autentica l'identità client o utente configurata: certificati, una directory o un'identità federata, secondo l'impostazione. Con Site-to-Site VPN, AWS autentica l'identità del peer del gateway. Questa differenza non è estetica. Un modello scala aggiungendo utenti e revocando le loro credenziali; l'altro scala fidandosi di tutto ciò che sta dietro un solo gateway.

L'autenticazione del gateway non autentica ogni dipendente né ogni applicazione che sta dietro, quindi mantenete le identità applicative e l'accesso a livello di risorsa anche quando il tunnel stesso è considerato affidabile. Una sede il cui router possiede un'identità peer valida non deve leggersi automaticamente come se ogni scrivania di quell'edificio fosse autorizzata.

Terzo, come si aggancia la connessione

Client VPN si aggancia tramite associazioni di sottorete VPC o un collegamento diretto a Transit Gateway supportato. Site-to-Site VPN si aggancia a una destinazione AWS VPN, di solito un gateway privato virtuale o un Transit Gateway. La guida all'architettura di Client VPN documenta l'opzione Transit Gateway, e la sua esistenza non trasforma una sessione di portatile in un gateway di sede né rimuove l'autenticazione e l'autorizzazione del client descritte sopra.

Verificate il collegamento che il vostro account e la vostra regione supportano davvero prima di progettare rotte attorno ad esso, poi verificate di chi è quel collegamento. Un'opzione che esiste nella documentazione ma si trova su una rete che non potete configurare non è un'opzione.

Quarto, quali routing e policy la accompagnano

Client VPN porta la gestione delle connessioni client e regole di autorizzazione per le reti di destinazione che consentite. Un utente connesso ha comunque bisogno della rotta prevista verso il punto di terminazione, di una regola di autorizzazione che la consenta e dell'accesso che la risorsa stessa richiede. Site-to-Site VPN instrada tra reti rappresentate da un gateway cliente, usando rotte statiche supportate o BGP secondo la progettazione, così le singole macchine dietro il router della sede non hanno ciascuna bisogno di un accesso client.

Non inferite comportamenti non supportati dalla categoria in nessuna direzione. Le VPN ad accesso remoto non sono universalmente incapaci di trasportare traffico di ritorno o di supportare disposizioni con gateway, e IPsec non viene bloccato automaticamente dal NAT — AWS documenta il traversal NAT e i requisiti del gateway cliente, e la configurazione del gateway supportata è il vero vincolo. Verificate le restrizioni del vostro punto di terminazione prima di richiedere connessioni iniziate verso i client o di inoltrare una LAN dietro una sessione. La stessa cautela vale per le famiglie di indirizzi: un punto di terminazione che funziona su IPv4 non implica un percorso IPv6, quindi confermate la famiglia che il vostro client o gateway negozierà realmente.

Site-to-Site VPN vi dà due tunnel per connessione, e quella ridondanza è un compito di progettazione più che una funzione che potete dare per scontata. L'esercizio del gateway cliente, il failover delle rotte e la copertura dei test vanno tutti pianificati; confrontare una sessione di portatile con un server VPN astratto non dimostra nulla su nessuno dei due.

Dove i due progetti si incontrano

I servizi non si escludono e la forma produttiva comune usa entrambi: dipendenti su Client VPN, reti di sede su Site-to-Site, con rotte esplicite e policy di accesso tra le destinazioni che devono parlarsi. La tabella è un riepilogo delle quattro verifiche, non un sostituto del loro svolgimento.

Una cosa che nessuno dei due prodotti sostituisce: TLS verso un'applicazione il cui requisito di cifratura va oltre il punto di terminazione VPN. Se il vostro perimetro di conformità finisce all'applicazione, il tunnel è trasporto e il certificato resta il controllo.

Scrivete le quattro risposte prima della revisione di progettazione, una riga ciascuna. Quando due non concordano — per esempio una progettazione client autenticata per utente con un requisito di routing delle dimensioni di una sede — quella discordanza è il risultato, ed è più economico vederla adesso che durante il passaggio.