Bör du aktivera AWS VPN-tunnelloggar på en aktiv tunnel?

Att slå på tunnelaktivitetsloggar för en Site-to-Site VPN är en liten ändring som kan fälla tunneln den mäter. AWS varnar för att aktivering av loggning på en befintlig tunnel kan avbryta den i flera minuter, så den intressanta frågan är inte hur man vänder flaggan utan på vilken tunnel man vänder den och när. Tre villkor avgör ordningen: om den andra tunneln verkligen bär rutterna, om du behöver tjänstehändelser eller BGP-händelser, och om ändringen går via konsolen eller via tunnelalternativens API. Gör fel och du slutar antingen med ett avbrott eller med en logggrupp full av ingenting.

Tre villkor avgör ordningen

Börja med identiteten på det du ändrar. Du behöver VPN-anslutningens ID, regionen och den aktuella tunnelns externa IP-adress, eftersom varje logginställning i den här funktionen gäller per tunnel och inte per anslutning. En ändring som tillämpas på fel extern adress är en ändring på en tunnel som ingen felsökte.

Målet är en CloudWatch-loggrupp i samma region, med den lagring och åtkomstpolicy du faktiskt vill ha. AWS rekommenderar prefixet /aws/vendedlogs/ för dessa grupper eftersom det undviker storleksgränserna för resurspolicyer som vanliga namn kan stöta på. Ett namn som /aws/vendedlogs/vpn/branch-a-activity är bara illustrativt; det som spelar roll är att gruppen finns, att leveransrollen kan skriva till den och att båda hanteras av den som äger VPN-konfigurationen. Namnet ger inga behörigheter, och en grupp som skapats utan leveranspolicyn ger tystnad i stället för ett fel.

Villkor ett: en redundant tunnel som verkligen bär trafik

Detta är villkoret som team hoppar över. Två konfigurerade tunnlar är inget bevis för att applikationen har en användbar alternativ väg.

Innan du rör en tunnel, bekräfta att den andra bär de rutter som spelar roll: kontrollera routingtabellen på kundgateway-sidan och bekräfta att applikationen verkligen kan växla över. AWS avbrottsfönster är minuter, inte sekunder, och en tunnel som bara finns på papper gör en diagnostisk ändring till ett avbrott. Om den redundanta vägen inte är bevisad, planera ändringen med samma omsorg som varje annan routingändring i stället för att behandla loggning som passiv. Instrumentera den tunnel vars beteende du försöker förklara, inte den som är lättare att nå.

Villkor två: aktivitetslogg eller BGP-logg

Denna avgör vad du faktiskt kommer att kunna läsa. Aktivitetsregistreringar täcker tjänstehändelser som IKE- och IPsec-tillståndsövergångar och DPD-meddelanden, vilket är vad du vill ha när tunneln inte kommer upp eller fortsätter att förnya nycklar. BGP-registreringar är en separat ström med egna kontroller, och de svarar på en annan fråga: om rutter byttes ut och drogs tillbaka som förväntat.

Att aktivera aktivitetsflaggan är inte en begäran om varje ström som tjänsten kan sända ut. Om misstanken är routing, aktivera båda; om misstanken är förhandling av fas 1 eller fas 2, är aktivitetsströmmen den som visar det.

Ingen av strömmarna är en paketfångst, och den skillnaden avgör fler ärenden än den borde. Aktivitets- och BGP-registreringar berättar vad tjänsten gjorde med tunneln och sessionen, inte vad din applikation skickade genom den. Att gripa efter tunnelloggar för att felsöka en applikationstimeout är ett kategorifel, och det kostar vanligtvis ett avbrottsfönster innan någon märker det. Välj frågan först, därefter strömmen som kan svara på den.

Villkor tre: konsoländring eller tunnelalternativens API

Om en människa gör en engångsändring är konsolvägen okej: VPC console, Site-to-Site VPN connections, välj anslutningen, Actions, Modify VPN tunnel options, välj den externa IP-adressen, aktivera Tunnel activity log, välj gruppen och utdataformatet, spara inom fönstret. Om VPN:en hanteras som kod är samma klick drift som du stämmer av senare.

För automatisering har aktivitetsloggdelen av tunnelalternativen en fast form: LogOptions innehåller CloudWatchLogOptions med LogEnabled, LogGroupArn och LogOutputFormat. Det blocket är ett fragment, inte en begäran; modify-vpn-tunnel-options behöver fortfarande anslutningens ID och tunnelns externa IP, och de återstående tunnelinställningarna måste bevaras av den som äger mallen. BGP-loggning använder sina egna nycklar BgpLogEnabled, BgpLogGroupArn och BgpLogOutputFormat i samma struktur. Läs tillbaka ändringen med describe-vpn-connections i stället för att lita på att anropet tillämpades.

Vad registreringarna kan och inte kan berätta

När den första tunneln är klar och den avsedda vägen är tillgänglig, upprepa samma kontrollerade sekvens för den andra tunneln om du också behöver dess loggar. En tunnel i taget är hela poängen.

Registreringar kommer i strömmar som identifieras av anslutningen och tunnelns externa adress, så korrelera mot den identiteten i stället för att förvänta dig att historiken dyker upp retroaktivt. Ingenting före ändringen existerar, och ingen väntan fyller luckan. Om du behöver en baslinje, registrera tunnelns nuvarande tillstånd och routingtabellen före ändringen så att det finns något att jämföra med.

Håll logggruppen, dess lagring, dess leveransbehörigheter och tunnelalternativblocket i samma inventering som själva VPN:en, eftersom de är en konfiguration utspridd på fyra ställen. AWS procedur för att aktivera loggar dokumenterar arbetsflödet per tunnel och dess avbrottsvarning, och den är värd att läsa före ändringen i stället för efter. Verifiera sedan i ordning: tunneln kom tillbaka, registreringar dyker upp i den förväntade strömmen, och registreringarna svarar på frågan du öppnade ärendet för. Om det tredje misslyckas var problemet valet av ström och inte loggningen.