Bør du aktivere AWS VPN-tunnellogs på en aktiv tunnel?

At slå aktivitetslogs til for en Site-to-Site VPN er en lille ændring, som kan vælte den tunnel, den måler. AWS advarer om, at aktivering af logning på en eksisterende tunnel kan afbryde den i flere minutter, så det interessante spørgsmål er ikke, hvordan man vender flaget, men hvilken tunnel man vender det på, og hvornår. Tre betingelser afgør rækkefølgen: om den anden tunnel faktisk bærer ruterne, om du har brug for tjenestehændelser eller BGP-hændelser, og om ændringen går gennem konsollen eller gennem tunnelindstillingernes API. Tager du fejl af dem, ender du med enten et udfald eller en loggruppe fuld af ingenting.

Tre betingelser afgør rækkefølgen

Start med identiteten på det, du ændrer. Du skal bruge VPN-forbindelsens ID, regionen og den pågældende tunnels eksterne IP-adresse, fordi hver logindstilling i denne funktion er pr. tunnel og ikke pr. forbindelse. En ændring anvendt på den forkerte eksterne adresse er en ændring på en tunnel, som ingen fejlsøgte.

Destinationen er en CloudWatch-loggruppe i samme region med den opbevaring og adgangspolitik, du faktisk ønsker. AWS anbefaler præfikset /aws/vendedlogs/ til disse grupper, fordi det undgår de størrelsesgrænser for ressourcepolitikker, som almindelige navne kan ramme. Et navn som /aws/vendedlogs/vpn/branch-a-activity er kun illustrativt; det afgørende er, at gruppen findes, at leveringsrollen kan skrive til den, og at begge administreres af den, der ejer VPN-konfigurationen. Navnet giver ikke tilladelser, og en gruppe oprettet uden leveringspolitikken giver tavshed i stedet for en fejl.

Betingelse et: en redundant tunnel, der faktisk bærer trafik

Det er den betingelse, som teams springer over. To konfigurerede tunneler er ikke bevis for, at applikationen har en brugbar alternativ vej.

Før du rører ved en tunnel, skal du bekræfte, at den anden bærer de ruter, der betyder noget: kontroller routingtabellen på kundegateway-siden og bekræft, at applikationen faktisk kan skifte over. AWS' afbrydelsesvindue er minutter, ikke sekunder, og en tunnel, der kun findes på papiret, gør en diagnostisk ændring til et udfald. Hvis den redundante vej ikke er bevist, skal du planlægge ændringen med samme omhu som enhver anden routingændring i stedet for at behandle logning som passivt. Instrumentér den tunnel, hvis adfærd du prøver at forklare, ikke den, der er nemmere at nå.

Betingelse to: aktivitetslog eller BGP-log

Denne afgør, hvad du faktisk vil kunne læse. Aktivitetsregistreringer dækker tjenestehændelser som IKE- og IPsec-tilstandsovergange og DPD-beskeder, hvilket er det, du vil have, når tunnelen ikke kommer op eller bliver ved med at forny nøgler. BGP-registreringer er en separat strøm med egne kontroller, og de besvarer et andet spørgsmål: om ruter blev udvekslet og tilbagekaldt som forventet.

At aktivere aktivitetsflaget er ikke en anmodning om hver strøm, som tjenesten kan udsende. Hvis mistanken er routing, skal du aktivere begge; hvis mistanken er fase 1- eller fase 2-forhandling, er aktivitetsstrømmen den, der viser det.

Ingen af strømmene er en pakkefangst, og denne forskel afgør flere sager, end den burde. Aktivitets- og BGP-registreringer fortæller dig, hvad tjenesten gjorde med tunnelen og sessionen, ikke hvad din applikation sendte gennem den. At gribe efter tunnellogs for at fejlsøge en applikationstimeout er en kategorifejl, og det koster normalt et afbrydelsesvindue, før nogen opdager det. Vælg spørgsmålet først, derefter den strøm, der kan besvare det.

Betingelse tre: konsolændring eller tunnelindstillingernes API

Hvis et menneske laver en engangsændring, er konsolvejen fin: VPC console, Site-to-Site VPN connections, vælg forbindelsen, Actions, Modify VPN tunnel options, vælg den eksterne IP, aktivér Tunnel activity log, vælg gruppen og outputformatet, gem inden for vinduet. Hvis VPN'en styres som kode, er det samme klik drift, som du afstemmer senere.

Til automatisering har aktivitetslog-delen af tunnelindstillingerne en fast form: LogOptions indeholder CloudWatchLogOptions med LogEnabled, LogGroupArn og LogOutputFormat. Den blok er et fragment, ikke en anmodning; modify-vpn-tunnel-options har stadig brug for forbindelsens ID og tunnelens eksterne IP, og de resterende tunnelindstillinger skal bevares af den, der ejer skabelonen. BGP-logning bruger sine egne nøgler BgpLogEnabled, BgpLogGroupArn og BgpLogOutputFormat i samme struktur. Læs ændringen tilbage med describe-vpn-connections i stedet for at stole på, at kaldet blev anvendt.

Hvad registreringerne kan og ikke kan fortælle dig

Når den første tunnel er færdig, og den tilsigtede vej er tilgængelig, skal du gentage den samme kontrollerede sekvens for den anden tunnel, hvis du også har brug for dens logs. En tunnel ad gangen er hele pointen.

Registreringer ankommer i strømme identificeret af forbindelsen og tunnelens eksterne adresse, så korrelér mod den identitet i stedet for at forvente, at historikken dukker op bagudrettet. Intet før ændringen eksisterer, og ingen mængde venten udfylder hullet. Hvis du har brug for en baseline, skal du registrere tunnelens aktuelle tilstand og routingtabellen før ændringen, så der er noget at sammenligne med.

Hold loggruppen, dens opbevaring, dens leveringstilladelser og tunnelindstillingsblokken i samme fortegnelse som selve VPN'en, fordi de er én konfiguration spredt over fire steder. AWS' procedure for at aktivere logs dokumenterer arbejdsgangen pr. tunnel og dens afbrydelsesadvarsel, og den er værd at læse før ændringen i stedet for efter. Bekræft derefter i rækkefølge: tunnelen kom tilbage, registreringer vises i den forventede strøm, og registreringerne besvarer det spørgsmål, du åbnede sagen for. Hvis det tredje fejler, var problemet valget af strøm og ikke logningen.