Dovresti attivare i log del tunnel AWS VPN su un tunnel attivo?
Attivare i log delle attività del tunnel può interrompere un tunnel attivo per alcuni minuti. Decidi quale tunnel, quale tipo di log e quale finestra prima di cambiare qualcosa.
Attivare i log delle attività del tunnel per una VPN site-to-site è una piccola modifica che può far cadere il tunnel che sta misurando. AWS avverte che abilitare la registrazione su un tunnel esistente può interromperlo per diversi minuti, quindi la domanda interessante non è come girare il flag ma su quale tunnel girarlo e quando. Tre condizioni decidono l’ordine: se l’altro tunnel trasporta davvero le rotte, se servono eventi di servizio o eventi BGP, e se la modifica passa dalla console o dall’API delle opzioni del tunnel. Sbaglia queste e ti ritroverai con un’interruzione o con un gruppo di log pieno di nulla.
Tre condizioni decidono l’ordine
Parti dall’identità di ciò che stai cambiando. Servono l’ID di connessione VPN, la regione e l’indirizzo IP esterno del tunnel specifico, perché ogni impostazione di log di questa funzionalità è per tunnel e non per connessione. Una modifica applicata all’indirizzo esterno sbagliato è una modifica a un tunnel che nessuno stava eseguendo il debug.
La destinazione è un gruppo di log CloudWatch nella stessa regione, con la conservazione e la policy di accesso che vuoi davvero. AWS consiglia il prefisso /aws/vendedlogs/ per questi gruppi perché evita i limiti di dimensione della policy delle risorse che i nomi semplici possono incontrare. Un nome come /aws/vendedlogs/vpn/branch-a-activity è solo illustrativo; ciò che conta è che il gruppo esista, che il ruolo di consegna possa scriverci e che entrambi siano gestiti da chi possiede la configurazione della VPN. Il nome non concede autorizzazioni, e un gruppo creato senza la policy di consegna produce silenzio anziché un errore.
Condizione uno: un tunnel ridondante che trasporta davvero traffico
Questa è la condizione che i team saltano. Due tunnel configurati non sono la prova che l’applicazione abbia un percorso alternativo utilizzabile.
Prima di toccare un tunnel, conferma che l’altro trasporti le rotte che contano: controlla la tabella di routing lato gateway del cliente e conferma che l’applicazione possa davvero commutare. La finestra di interruzione di AWS è di minuti, non di secondi, e un tunnel che esiste solo sulla carta trasforma una modifica diagnostica in un’interruzione. Se il percorso ridondante non è dimostrato, pianifica la modifica con la stessa cura di qualsiasi altra modifica di routing invece di trattare la registrazione come passiva. Strumenta il tunnel di cui stai cercando di spiegare il comportamento, non quello più facile da raggiungere.
Condizione due: log delle attività o log BGP
Questa decide cosa potrai davvero leggere. I record delle attività coprono eventi di servizio come le transizioni di stato IKE e IPsec e i messaggi DPD, che è ciò che vuoi quando il tunnel non sale o continua a rinnovare le chiavi. I record BGP sono un flusso separato con i propri controlli, e rispondono a una domanda diversa: se le rotte sono state scambiate e ritirate come previsto.
Abilitare il flag delle attività non è una richiesta per ogni flusso che il servizio può emettere. Se il sospetto è il routing, abilita entrambi; se il sospetto è la negoziazione della fase 1 o della fase 2, è il flusso delle attività a mostrarlo.
Nessuno dei due flussi è una cattura di pacchetti, e questa distinzione risolve più ticket di quanto dovrebbe. I record delle attività e BGP ti dicono cosa ha fatto il servizio con il tunnel e la sessione, non cosa ha inviato la tua applicazione attraverso di essi. Ricorrere ai log del tunnel per eseguire il debug di un timeout dell’applicazione è un errore di categoria, e di solito costa una finestra di interruzione prima che qualcuno se ne accorga. Scegli prima la domanda, poi il flusso che può rispondervi.
Condizione tre: modifica da console o API delle opzioni del tunnel
Se una persona fa una modifica una tantum, il percorso da console va bene: VPC console, Site-to-Site VPN connections, seleziona la connessione, Actions, Modify VPN tunnel options, scegli l’IP esterno, abilita Tunnel activity log, scegli il gruppo e il formato di output, salva dentro la finestra. Se la VPN è gestita come codice, lo stesso clic è una deriva che riconcilierai più tardi.
Per l’automazione, la parte dei log delle attività delle opzioni del tunnel ha una forma fissa: LogOptions che contiene CloudWatchLogOptions con LogEnabled, LogGroupArn e LogOutputFormat. Quel blocco è un frammento, non una richiesta; modify-vpn-tunnel-options ha ancora bisogno dell’ID di connessione e dell’IP esterno del tunnel, e le restanti impostazioni del tunnel devono essere preservate da chi possiede il modello. La registrazione BGP usa le proprie chiavi BgpLogEnabled, BgpLogGroupArn e BgpLogOutputFormat nella stessa struttura. Rileggi la modifica con describe-vpn-connections invece di fidarti che la chiamata sia stata applicata.
Cosa possono e cosa non possono dirti i record
Quando il primo tunnel è fatto e il percorso previsto è disponibile, ripeti la stessa sequenza controllata per il secondo tunnel se ti servono anche i suoi log. Un tunnel alla volta è tutto il senso.
I record arrivano in flussi identificati dalla connessione e dall’indirizzo esterno del tunnel, quindi correlali con quell’identità invece di aspettarti che la cronologia compaia retroattivamente. Nulla prima della modifica esiste, e nessuna attesa riempie il vuoto. Se ti serve una linea di base, cattura lo stato attuale del tunnel e la tabella di routing prima della modifica in modo che ci sia qualcosa con cui confrontare.
Tieni il gruppo di log, la sua conservazione, le sue autorizzazioni di consegna e il blocco delle opzioni del tunnel nello stesso inventario della VPN stessa, perché sono un’unica configurazione distribuita su quattro punti. La procedura AWS per abilitare i log documenta il flusso di lavoro per tunnel e il suo avviso di interruzione, e vale la pena leggerla prima della modifica e non dopo. Poi verifica in ordine: il tunnel è tornato, i record compaiono nel flusso atteso e i record rispondono alla domanda per cui hai aperto il ticket. Se il terzo fallisce, il problema era la scelta del flusso e non la registrazione.