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

Å slå på tunnelaktivitetslogger for en Site-to-Site VPN er en liten endring som kan felle tunnelen den måler. AWS advarer om at aktivering av logging på en eksisterende tunnel kan avbryte den i flere minutter, så det interessante spørsmålet er ikke hvordan man vender flagget, men hvilken tunnel man vender det på, og når. Tre betingelser avgjør rekkefølgen: om den andre tunnelen faktisk bærer rutene, om du trenger tjenestehendelser eller BGP-hendelser, og om endringen går gjennom konsollen eller gjennom tunnelvalg-API-et. Tar du feil av disse, ender du med enten et avbrudd eller en logggruppe full av ingenting.

Tre betingelser avgjør rekkefølgen

Start med identiteten til det du endrer. Du trenger VPN-tilkoblingens ID, regionen og den aktuelle tunnelens eksterne IP-adresse, fordi hver logginnstilling i denne funksjonen er per tunnel og ikke per tilkobling. En endring brukt på feil ekstern adresse er en endring på en tunnel som ingen feilsøkte.

Målet er en CloudWatch-logggruppe i samme region, med den oppbevaringen og tilgangspolicyen du faktisk vil ha. AWS anbefaler prefikset /aws/vendedlogs/ for disse gruppene fordi det unngår størrelsesgrensene for ressurspolicyer som vanlige navn kan støte på. Et navn som /aws/vendedlogs/vpn/branch-a-activity er bare illustrativt; det som betyr noe er at gruppen finnes, at leveringsrollen kan skrive til den, og at begge administreres av den som eier VPN-konfigurasjonen. Navnet gir ingen tillatelser, og en gruppe opprettet uten leveringspolicyen gir stillhet i stedet for en feil.

Betingelse én: en redundant tunnel som faktisk bærer trafikk

Dette er betingelsen team hopper over. To konfigurerte tunneler er ikke bevis for at applikasjonen har en brukbar alternativ vei.

Før du rører én tunnel, bekreft at den andre bærer rutene som betyr noe: sjekk rutingtabellen på kundegateway-siden og bekreft at applikasjonen faktisk kan svitsje over. AWS-ens avbruddsvindu er minutter, ikke sekunder, og en tunnel som bare finnes på papiret gjør en diagnostisk endring til et avbrudd. Hvis den redundante veien ikke er bevist, planlegg endringen med samme omhu som enhver annen rutingendring i stedet for å behandle logging som passivt. Instrumenter tunnelen du prøver å forklare oppførselen til, ikke den som er enklere å nå.

Betingelse to: aktivitetslogg eller BGP-logg

Denne avgjør hva du faktisk vil kunne lese. Aktivitetsregistreringer dekker tjenestehendelser som IKE- og IPsec-tilstandsoverganger og DPD-meldinger, som er det du vil ha når tunnelen ikke kommer opp eller fortsetter å fornye nøkler. BGP-registreringer er en egen strøm med egne kontroller, og de svarer på et annet spørsmål: om ruter ble utvekslet og trukket tilbake som forventet.

Å aktivere aktivitetsflagget er ikke en forespørsel om hver strøm tjenesten kan sende ut. Hvis mistanken er ruting, aktiver begge; hvis mistanken er forhandling av fase 1 eller fase 2, er aktivitetsstrømmen den som viser det.

Ingen av strømmene er en pakkefangst, og den forskjellen avgjør flere saker enn den burde. Aktivitets- og BGP-registreringer forteller deg hva tjenesten gjorde med tunnelen og sesjonen, ikke hva applikasjonen din sendte gjennom den. Å gripe etter tunnellogger for å feilsøke en applikasjonstidsavbrudd er en kategorifeil, og det koster vanligvis et avbruddsvindu før noen merker det. Velg spørsmålet først, deretter strømmen som kan svare på det.

Betingelse tre: konsollendring eller tunnelvalg-API

Hvis et menneske gjør en engangsendring, er konsollveien grei: VPC console, Site-to-Site VPN connections, velg tilkoblingen, Actions, Modify VPN tunnel options, velg den eksterne IP-en, aktiver Tunnel activity log, velg gruppen og utdataformatet, lagre innenfor vinduet. Hvis VPN-en administreres som kode, er det samme klikket drift du vil avstemme senere.

For automatisering har aktivitetsloggdelen av tunnelvalgene en fast form: LogOptions inneholder CloudWatchLogOptions med LogEnabled, LogGroupArn og LogOutputFormat. Den blokken er et fragment, ikke en forespørsel; modify-vpn-tunnel-options trenger fortsatt tilkoblingens ID og tunnelens eksterne IP, og de resterende tunnelinnstillingene må bevares av den som eier malen. BGP-logging bruker sine egne nøkler BgpLogEnabled, BgpLogGroupArn og BgpLogOutputFormat i samme struktur. Les endringen tilbake med describe-vpn-connections i stedet for å stole på at kallet ble brukt.

Hva registreringene kan og ikke kan fortelle deg

Når den første tunnelen er ferdig og den tiltenkte veien er tilgjengelig, gjenta den samme kontrollerte sekvensen for den andre tunnelen hvis du også trenger loggene dens. Én tunnel av gangen er hele poenget.

Registreringer kommer i strømmer identifisert av tilkoblingen og tunnelens eksterne adresse, så korreler mot den identiteten i stedet for å forvente at historikken dukker opp retroaktivt. Ingenting før endringen finnes, og ingen ventetid fyller gapet. Hvis du trenger en grunnlinje, registrer tunnelens nåværende tilstand og rutingtabellen før endringen, slik at det er noe å sammenligne med.

Hold logggruppen, oppbevaringen, leveringstillatelsene og tunnelvalgblokken i samme oversikt som selve VPN-en, fordi de er én konfigurasjon spredt over fire steder. AWS-prosedyren for å aktivere logger dokumenterer arbeidsflyten per tunnel og avbruddsvarselet, og den er verdt å lese før endringen i stedet for etter. Bekreft deretter i rekkefølge: tunnelen kom tilbake, registreringer vises i den forventede strømmen, og registreringene svarer på spørsmålet du åpnet saken for. Hvis det tredje feiler, var problemet valget av strøm og ikke loggingen.