Da strongSwan a AWS Site-to-Site: perché la Child SA non seleziona nulla

Un tunnel IKE può essere attivo mentre l’associazione figlia esclude le tue subnet. Confronta prima i CIDR locale e remoto di AWS con leftsubnet e rightsubnet.

La console indica up, strongSwan segnala un’associazione IKE stabilita e i pacchetti continuano a non arrivare. La cosa successiva da confrontare non è la chiave precondivisa, ma la coppia di prefissi che ciascun lato ritiene protetta dal tunnel. Segui i controlli qui sotto in ordine, perché i primi due decidono se il tunnel può anche solo trasportare il tuo traffico.

Traduci i nomi di AWS nei termini di strongSwan

AWS descrive la connessione dal lato cliente: l’indirizzo del gateway del cliente e il CIDR locale sono tuoi, e il CIDR remoto appartiene al VPC. strongSwan chiama i due estremi left e right, con il tuo prefisso in leftsubnet e quello del VPC in rightsubnet. Invertire una coppia produce un tunnel che negozia e seleziona il traffico sbagliato.

Scarica la configurazione che AWS genera per la connessione e trattala come riferimento per quella specifica connessione, compresi gli indirizzi del tunnel e i prefissi. Lasciando entrambi i campi CIDR vuoti alla creazione, il servizio usa il valore predefinito 0.0.0.0/0 su ciascun lato. Un router configurato con un prefisso stretto non corrisponderà mai, quindi compila i campi o allarga deliberatamente il selettore.

Una discrepanza qui sembra un errore di routing e non lo è.

Fissa l’indirizzo che AWS vede davvero

Un router dietro NAT può originare IKE da un’interfaccia che il lato remoto non ha mai conosciuto. L’indirizzo del gateway registrato in AWS deve essere quello che AWS osserva sulla rete, e il router va fissato allo stesso indirizzo locale invece di seguire la sua rotta predefinita.

conn %default
    local_addrs = 203.0.113.10

In strongSwan local_addrs seleziona l’indirizzo di origine per IKE, e le vecchie configurazioni OpenSwan scrivono la stessa idea come left. Puntalo sull’interfaccia che ha l’indirizzo pubblico, poi verifica sul dispositivo NAT stesso che UDP 500 e 4500 raggiungano quell’host, perché una regola rimasta da un router precedente li scarta in silenzio. Una coppia di selettori corretta con l’indirizzo di origine sbagliato fallisce comunque, e il registro darà la colpa alla proposta. Quell’inganno è il motivo per cui l’indirizzo di origine merita un controllo a sé.

Conferma la regola di inoltro invece di darla per scontata, perché una regola che era corretta per il router precedente spesso rimane.

Tratta la fase 1 e la fase 2 separatamente

AWS espone le opzioni IKE ed ESP come elenchi separati. Una suite IKE che entrambi i lati accettano non dice nulla sulla proposta ESP, perché i due elenchi sono indipendenti. Leggile entrambe dalla configurazione generata e confrontale una alla volta.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

La sintassi non viaggia tra implementazioni. Una coppia che funziona in OpenSwan, per esempio phase2alg=aes_gcm con ike=aes256-sha1;modp1024, va tradotta nella forma esp= e ike= di strongSwan, e i nomi degli algoritmi differiscono. Poiché GCM autentica mentre cifra, non ha bisogno di una trasformazione di integrità separata, a differenza di una suite CBC abbinata a SHA. Una riga di fase 2 incollata da un demone a un altro senza traduzione produce un rifiuto che si legge come una discrepanza di selettori.

Controlla l’associazione figlia, non l’indicatore del tunnel

Se la connessione si carica ma non compare alcuna associazione figlia, sono state rifiutate la proposta o i selettori. Se compare una figlia e i suoi selettori escludono i tuoi prefissi, i pacchetti vengono filtrati prima di raggiungere il tunnel. L’indicatore della console copre solo il livello IKE, quindi non può dirti quale delle due cose è successa.

ipsec statusall

Cerca l’associazione di sicurezza figlia e leggi i selettori di traffico stampati accanto, poi confrontali con i prefissi della configurazione generata.

Prova da un host dentro il prefisso locale a un host dentro il prefisso del VPC, e controlla il percorso di ritorno oltre a qualsiasi gruppo di sicurezza o ACL di rete sul lato AWS. Selettori corretti non proteggono un pacchetto dall’essere scartato più tardi.

Quando continua a fallire dopo che i selettori coincidono

Conferma che la rotta su entrambi i lati punta al tunnel, poi conferma che il dispositivo NAT non riscrive il traffico in un modo che la policy non si aspetta. Un tunnel basato su policy confronta gli indirizzi dei pacchetti, quindi una traduzione applicata dopo la decisione di policy cambia l’esito.

Registra un pacchetto in ingresso e uno in uscita su ciascun lato prima di cambiare un’altra proposta.

Annota i selettori, le proposte di fase 1 e fase 2 e l’indirizzo di origine nel ticket. Quei quattro valori spiegano la maggior parte dei guasti site-to-site senza una chiamata.

Articoli correlati