strongSwan su EC2: fai in modo che la VPC instradi il carico di lavoro

Il tunnel è attivo, l'istanza gateway riesce a fare ping alla rete remota e l'istanza applicativa accanto non raggiunge nulla. Niente è rotto. Il test riuscito partiva dall'host VPN e non ha mai chiesto se quell'host potesse trasportare un indirizzo sorgente diverso attraverso la stessa relazione IPsec. Questa guida colma quel divario in quattro passaggi, nell'ordine che tiene visibile ogni errore.

Scrivete prima i quattro indirizzi

Ogni passaggio seguente vi fa riferimento, quindi compilateli per il vostro account prima di toccare una tabella di routing.

VPC:             10.60.0.0/16
Gateway subnet:  10.60.1.0/24, gateway ENI address 10.60.1.10
Workload subnet: 10.60.2.0/24, application address 10.60.2.20
Remote network:  10.90.0.0/24

L'esempio presuppone una connessione IPsec basata su criteri approvata e funzionante, e un flusso che preserva la sorgente. Non è un client di accesso remoto con NAT che prende in prestito un indirizzo assegnato, e questa differenza decide se i selettori devono cambiare.

Passaggio 1: date una rotta alla sottorete del carico

La tabella di routing realmente associata alla sottorete del carico ha bisogno di un percorso verso il prefisso remoto che punti all'interfaccia di rete del gateway. Una rotta ospite installata dentro l'istanza non è una voce in quella tabella di routing AWS e nessuna configurazione di strongSwan, per quanto estesa, ne creerà una.

Le indicazioni AWS sul routing tramite appliance descrivono i target di interfaccia di rete e il requisito di verifica sorgente/destinazione dell'istanza che inoltra. Limitate questa modifica di verifica al ruolo di gateway e lasciate in pace le istanze applicative ordinarie.

Non sostituite la rotta locale della VPC né ogni voce esistente per fare spazio a una rete approvata. Ispezionate ciò che è associato e attivo, non ciò che una pagina della console mostra per una tabella di routing che nessuno usa. Due tabelle che sembrano uguali possono avere associazioni diverse. Quella che conta è quella a cui è collegata la sottorete del carico.

Passaggio 2: abilitate l'inoltro sull'ospite

sysctl -w net.ipv4.ip_forward=1
# persist in /etc/sysctl.d/ and re-apply after reboot

Il kernel deve inoltrare e il firewall dell'host deve consentire il transito. Aggiungete le regole di inoltro previste per i prefissi del carico e remoti invece di accettare tutto, e confermate che la sottorete del gateway mantenga una rotta di trasporto utilizzabile per il proprio traffico.

I gruppi di sicurezza sono il punto in cui questo passaggio di solito si blocca. Un dispositivo intermedio non eredita il comportamento di riferimento dei gruppi di sicurezza della comunicazione diretta tra istanze, quindi una regola copiata da un esempio di Client VPN gestito potrebbe non corrispondere mai. Controllate il gruppo di sicurezza e l'ACL della sottorete sul percorso reale, in entrambe le direzioni.

Passaggio 3: ampliate i selettori alle sorgenti reali

Un criterio che copre solo 10.60.1.10/32 sul lato AWS spiega un successo originato dal gateway senza coprire 10.60.2.20. Una rotta verso la destinazione remota non amplia un selettore di traffico, e questa è la seconda metà della stessa sorpresa.

swanctl --list-sas
# read the installed CHILD-SA local and remote traffic selectors

Se il progetto concordato protegge l'intera VPC, entrambi i peer devono accettare 10.60.0.0/16 e 10.90.0.0/24. Se protegge un solo carico, usate deliberatamente quel prefisso più stretto. In ogni caso, ispezionate il criterio CHILD-SA installato, perché una configurazione che avete modificato e un peer che l'ha ristretta diversamente non sono lo stesso accordo.

Il sito remoto deve anche instradare le risposte per le sorgenti VPC preservate di ritorno attraverso il gateway IPsec previsto. Mantenete l'esenzione NAT supportata per il traffico protetto dove esistono altre regole di NAT sorgente; tradurre un carico non approvato in un indirizzo host consentito è un contratto di identità diverso, non una scorciatoia verso l'accesso che volevate.

Passaggio 4: verificate, poi ripristinate se necessario

Provate dal carico stesso con una nuova operazione applicativa consentita, poi ripetete con una destinazione che dovrebbe essere esclusa. Annotate l'indirizzo sorgente che il servizio remoto vede e il percorso di ritorno che usa. Un ping al gateway o uno stato IKE verde non è quel test.

Se il carico continua a fallire mentre il gateway funziona, ripercorrete i passaggi in ordine: selettore, poi inoltro e gruppi di sicurezza, poi la tabella di routing associata. Ognuno ha un sintomo distinto, e tirare a indovinare salta quello che è davvero sbagliato.

Il ripristino inverte lo stesso ordine. Rimuovete per ultima la rotta della sottorete del carico, dopo aver ripristinato i selettori precedenti, per non lasciare una sottorete che punta a un gateway che non protegge più le sue sorgenti. L'auto-hosting può servire più dell'host gateway quando questi contratti valgono, e la VPN Site-to-Site gestita da AWS è un modello operativo diverso in cui strongSwan può trovarsi invece dal lato del gateway cliente.