Come far avviare ad AWS un tunnel Site-to-Site VPN
L'azione di avvio e l'azione di timeout DPD rispondono a domande diverse. Impostate quella che fa iniziare AWS, poi verificate l'indirizzo del peer e la rotta dell'applicazione.
Per impostazione predefinita, una VPN Site-to-Site di AWS attende che il customer gateway avvii la negoziazione. Quel valore predefinito è un'impostazione, non una legge, e l'impostazione si chiama Startup action. Prima di ricorrervi, separate due domande che vengono continuamente confuse: chi stabilisce il tunnel e se i pacchetti che vi interessano hanno una rotta che lo attraversa. Solo la prima vive nelle opzioni del tunnel.
Separate l'azione di avvio dall'azione di timeout DPD
Due opzioni per tunnel governano due eventi diversi, e impostarne una non dice nulla sull'altra.
| Event | Option | Useful values |
|---|---|---|
| A new or modified VPN connection needs a tunnel | Startup action | add waits for the peer; start asks AWS to initiate |
| Dead peer detection times out | DPD timeout action | clear ends the session, restart reinitiates, none does nothing |
Se AWS deve alzare un tunnel nuovo o modificato, scegliete start. Se AWS deve anche riavviare la negoziazione dopo un timeout DPD, configurate restart per quell'evento separatamente. Nessuna delle due opzioni è una politica di tentativi dell'applicazione, e nessuna è un intervallo di ricambio chiavi: DPD controlla se il peer è vivo, mentre il ricambio chiavi sostituisce le security associations su un tunnel attivo.
Un'applicazione che va in timeout mentre il tunnel riporta ancora up ha un problema di percorso dati. Accorciare il timer DPD non lo risolverà e può aggiungere trambusto che dovrete spiegare più avanti.
Verificate che AWS abbia dove inviare la negoziazione
L'avvio dal lato AWS funziona solo con IKEv2, e AWS ha bisogno dell'indirizzo pubblico del customer gateway per sapere dove inviare la proposta. Il caso che fa male è una risorsa customer gateway autenticata con certificato creata senza indirizzo: la documentazione AWS descrive la creazione di una nuova risorsa customer gateway con l'indirizzo e poi la modifica della connessione VPN perché la punti.
Un certificato dimostra chi è il peer. Non dice ad AWS dove si trova il peer, e sono due requisiti diversi. Per questo il rimedio è una nuova risorsa customer gateway e non un nuovo certificato. Sostituire il certificato lascia AWS con la stessa destinazione mancante.
Se il customer gateway si trova dietro NAT, AWS ha bisogno anche di un responder identity configurato, IDr, così che l'identità del peer corrisponda a ciò che il dispositivo si aspetta. Confermate quel valore e il percorso del firewall che ammette il traffico IKE prima di dare la colpa all'opzione appena modificata. Scegliere start non può far accettare una proposta a un peer irraggiungibile o identificato male.
Applicate la modifica a un solo tunnel e aspettatevi un'interruzione
Una connessione VPN ha due tunnel con opzioni indipendenti, quindi confermate quale state modificando dall'indirizzo esterno. AWS consente di modificare un tunnel alla volta, e la connettività sul tunnel scelto può essere interrotta per diversi minuti.
- Selezionate la connessione Site-to-Site VPN e aprite Modify VPN tunnel options.
- Scegliete il tunnel in base all'indirizzo IP esterno e confermate la versione IKE e la risorsa customer gateway.
- Impostate le azioni di avvio e DPD che volete davvero, poi salvate in una finestra che controllate.
- Confermate che il tunnel modificato si stabilisca e controllate l'altro tunnel e l'instradamento prima della modifica successiva.
Un comportamento merita attenzione prima della manutenzione. Con l'avvio AWS attivo non c'è timeout: AWS continua a provare finché il tunnel non sale, e riavvia quando il customer gateway invia un messaggio delete-SA. Se abbattete il peer di proposito, AWS continuerà a bussare, e i log del peer lo mostreranno.
Verificate il percorso dell'applicazione, non solo lo stato del tunnel
Un tunnel che riporta up non è la stessa cosa di una richiesta che funziona. Una funzione Lambda collegata a una VPC ha ancora bisogno di una rotta subnet verso il prefisso del cliente, di regole security group e network ACL che permettano il traffico, di risoluzione dei nomi che restituisca l'indirizzo giusto e di un percorso di ritorno lato cliente.
Provate una volta con una richiesta reale dal contesto dell'applicazione, poi leggete i flow logs se fallisce. Il traffico keepalive è un'opzione legittima quando l'avvio AWS è spento e un tunnel inattivo ha bisogno di pacchetti per restare su, ma dovrebbe essere una decisione di monitoraggio che potete nominare, non un ciclo ping inspiegato avvitato su una funzione.
Scegliete prima chi stabilisce il tunnel, poi diagnosticate il guasto rimanente al suo livello. La documentazione AWS sull'avvio copre i requisiti di indirizzo, identità e tentativi con più dettaglio di quanto facciano i suggerimenti della console.