Moet u AWS VPN-tunnellogs inschakelen op een actieve tunnel?

Het aanzetten van tunnelactiviteitslogs voor een Site-to-Site VPN is een kleine wijziging die de tunnel die het meet kan laten vallen. AWS waarschuwt dat het inschakelen van logging op een bestaande tunnel deze enkele minuten kan onderbreken, dus de interessante vraag is niet hoe u de vlag omzet, maar op welke tunnel u dat doet en wanneer. Drie voorwaarden bepalen de volgorde: of de andere tunnel de routes echt draagt, of u servicegebeurtenissen of BGP-gebeurtenissen nodig hebt, en of de wijziging via de console of via de tunnelopties-API loopt. Doe dit verkeerd en u eindigt met een storing of met een loggroep vol niets.

Drie voorwaarden bepalen de volgorde

Begin bij de identiteit van wat u wijzigt. U hebt de VPN-verbindings-ID, de regio en het externe IP-adres van de specifieke tunnel nodig, want elke loginstelling in deze functie is per tunnel en niet per verbinding. Een wijziging op het verkeerde externe adres is een wijziging aan een tunnel die niemand aan het debuggen was.

De bestemming is een CloudWatch-loggroep in dezelfde regio, met de retentie en het toegangsbeleid dat u echt wilt. AWS raadt het voorvoegsel /aws/vendedlogs/ aan voor deze groepen, omdat het de groottelimieten van resourcebeleid vermijdt waar gewone namen op kunnen stuiten. Een naam als /aws/vendedlogs/vpn/branch-a-activity is alleen illustratief; wat telt is dat de groep bestaat, dat de leveringsrol erin kan schrijven en dat beide worden beheerd door wie de VPN-configuratie bezit. De naam verleent geen rechten, en een groep die zonder het leveringsbeleid is gemaakt, levert stilte op in plaats van een fout.

Voorwaarde één: een redundante tunnel die echt verkeer draagt

Dit is de voorwaarde die teams overslaan. Twee geconfigureerde tunnels zijn geen bewijs dat de applicatie een bruikbaar alternatief pad heeft.

Voordat u één tunnel aanraakt, bevestigt u dat de andere de routes draagt die ertoe doen: controleer de routingtabel aan de kant van de klantgateway en bevestig dat de applicatie echt kan omschakelen. Het onderbrekingsvenster van AWS is minuten, niet seconden, en een tunnel die alleen op papier bestaat maakt van een diagnostische wijziging een storing. Als het redundante pad niet bewezen is, plant u de wijziging met dezelfde zorg als elke andere routingwijziging in plaats van logging als passief te behandelen. Instrumenteer de tunnel waarvan u het gedrag probeert te verklaren, niet degene die makkelijker te bereiken is.

Voorwaarde twee: activiteitslog of BGP-log

Deze bepaalt wat u werkelijk kunt lezen. Activiteitsrecords dekken servicegebeurtenissen zoals IKE- en IPsec-statusovergangen en DPD-berichten, wat u wilt als de tunnel niet omhoog komt of steeds sleutels vernieuwt. BGP-records zijn een aparte stroom met eigen bediening, en ze beantwoorden een andere vraag: of routes werden uitgewisseld en ingetrokken zoals verwacht.

Het activiteitskenmerk inschakelen is geen verzoek voor elke stroom die de service kan uitzenden. Als het vermoeden routing is, schakelt u beide in; als het vermoeden de onderhandeling over fase 1 of fase 2 is, is de activiteitsstroom degene die het laat zien.

Geen van beide stromen is een packet capture, en dat onderscheid beslecht meer tickets dan het zou moeten. Activiteits- en BGP-records vertellen u wat de service met de tunnel en de sessie heeft gedaan, niet wat uw applicatie erdoorheen heeft gestuurd. Terugvallen op tunnellogs om een applicatietime-out te debuggen is een categoriefout, en het kost meestal een onderbrekingsvenster voordat iemand het merkt. Kies eerst de vraag, dan de stroom die haar kan beantwoorden.

Voorwaarde drie: wijziging via de console of de tunnelopties-API

Als een mens een eenmalige wijziging doorvoert, is het consolepad prima: VPC console, Site-to-Site VPN connections, selecteer de verbinding, Actions, Modify VPN tunnel options, kies het externe IP, schakel Tunnel activity log in, kies de groep en het uitvoerformaat, sla op binnen het venster. Wordt de VPN als code beheerd, dan is dezelfde klik drift die u later verzoent.

Voor automatisering heeft het activiteitslogdeel van de tunnelopties een vaste vorm: LogOptions bevat CloudWatchLogOptions met LogEnabled, LogGroupArn en LogOutputFormat. Dat blok is een fragment, geen verzoek; modify-vpn-tunnel-options heeft nog steeds de verbindings-ID en het externe IP van de tunnel nodig, en de overige tunnelinstellingen moeten worden bewaard door wie de sjabloon bezit. BGP-logging gebruikt zijn eigen sleutels BgpLogEnabled, BgpLogGroupArn en BgpLogOutputFormat in dezelfde structuur. Lees de wijziging terug met describe-vpn-connections in plaats van erop te vertrouwen dat de aanroep is toegepast.

Wat de records wel en niet kunnen vertellen

Zodra de eerste tunnel klaar is en het beoogde pad beschikbaar is, herhaalt u dezelfde gecontroleerde reeks voor de tweede tunnel als u ook de logs daarvan nodig hebt. Eén tunnel tegelijk is het hele punt.

Records komen binnen in stromen die worden geïdentificeerd door de verbinding en het externe adres van de tunnel, dus correleer met die identiteit in plaats van te verwachten dat geschiedenis met terugwerkende kracht verschijnt. Niets vóór de wijziging bestaat, en geen enkele wachttijd vult het gat. Als u een basislijn nodig hebt, legt u de huidige tunnelstatus en de routingtabel vast vóór de wijziging, zodat er iets te vergelijken is.

Houd de loggroep, de retentie, de leveringsrechten en het tunneloptiesblok in dezelfde inventaris als de VPN zelf, want ze zijn één configuratie verspreid over vier plaatsen. De AWS-procedure voor het inschakelen van logs documenteert de werkwijze per tunnel en de onderbrekingswaarschuwing, en het is de moeite waard die vóór de wijziging te lezen in plaats van erna. Verifieer daarna in volgorde: de tunnel is terug, records verschijnen in de verwachte stroom, en de records beantwoorden de vraag waarvoor u het ticket opende. Als het derde faalt, was de keuze van de stroom het probleem en niet de logging.