Bør du slå på AWS VPN-tunnelloggar på ein aktiv tunnel?

Å slå på tunnelaktivitetsloggar for ein Site-to-Site VPN er ei lita endring som kan felle tunnelen ho måler. AWS åtvarar om at aktivering av logging på ein eksisterande tunnel kan bryte av tunnelen i fleire minutt, så det interessante spørsmålet er ikkje korleis ein snur flagget, men kva tunnel ein snur det på, og når. Tre vilkår avgjer rekkjefølgja: om den andre tunnelen faktisk ber rutene, om du treng tenestehendingar eller BGP-hendingar, og om endringa går gjennom konsollen eller gjennom tunnelval-API-et. Gjer du feil her, endar du med anten eit avbrot eller ei logggruppe full av ingenting.

Tre vilkår avgjer rekkjefølgja

Start med identiteten til det du endrar. Du treng ID-en til VPN-tilkoplinga, regionen og den eksterne IP-adressa til den aktuelle tunnelen, fordi kvar logginnstilling i denne funksjonen er per tunnel og ikkje per tilkopling. Ei endring brukt på feil ekstern adresse er ei endring på ein tunnel som ingen feilsøkte.

Målet er ei CloudWatch-logggruppe i same region, med den oppbevaringa og tilgangspolicyen du faktisk vil ha. AWS tilrår prefikset /aws/vendedlogs/ for desse gruppene fordi det unngår storleiksgrensene for ressurspolicyar som vanlege namn kan støyte på. Eit namn som /aws/vendedlogs/vpn/branch-a-activity er berre illustrativt; det som tel er at gruppa finst, at leveringsrolla kan skrive til ho, og at begge blir styrte av den som eig VPN-konfigurasjonen. Namnet gir ingen løyve, og ei gruppe oppretta utan leveringspolicyen gir still tid i staden for ein feil.

Vilkår éin: ein redundant tunnel som faktisk ber trafikk

Dette er vilkåret team hoppar over. To konfigurerte tunnelar er ikkje prov på at applikasjonen har ein brukbar alternativ veg.

Før du rører éin tunnel, stadfest at den andre ber rutene som betyr noko: sjekk rutetabellen på kundegateway-sida og stadfest at applikasjonen faktisk kan svitsje over. Avbrotsvindauget til AWS er minutt, ikkje sekund, og ein tunnel som berre finst på papiret gjer ei diagnostisk endring til eit avbrot. Viss den redundante vegen ikkje er prova, planlegg endringa med same omhug som kvar annan ruteendring i staden for å handsame logging som passiv. Instrumenter tunnelen du prøver å forklare åtferda til, ikkje den som er enklare å nå.

Vilkår to: aktivitetslogg eller BGP-logg

Denne avgjer kva du faktisk vil kunne lese. Aktivitetsregistreringar dekkjer tenestehendingar som IKE- og IPsec-tilstandsovergangar og DPD-meldingar, som er det du vil ha når tunnelen ikkje kjem opp eller held fram med å fornye nøklar. BGP-registreringar er ein eigen straum med eigne kontrollar, og dei svarar på eit anna spørsmål: om ruter vart utveksla og trekte tilbake som venta.

Å slå på aktivitetsflagget er ikkje ein førespurnad om kvar straum tenesta kan sende ut. Viss mistanken er ruting, slå på begge; viss mistanken er forhandling av fase 1 eller fase 2, er aktivitetsstraumen den som viser det.

Ingen av straumane er ein pakkefangst, og den skilnaden avgjer fleire saker enn han burde. Aktivitets- og BGP-registreringar fortel deg kva tenesta gjorde med tunnelen og sesjonen, ikkje kva applikasjonen din sende gjennom han. Å gripe etter tunnelloggar for å feilsøke ein applikasjonstidsavbrot er ein kategorifeil, og det kostar vanlegvis eit avbrotsvindauge før nokon merkar det. Vel spørsmålet først, deretter straumen som kan svare på det.

Vilkår tre: konsollendring eller tunnelval-API

Viss eit menneske gjer ei eingongsendring, er konsollvegen grei: VPC console, Site-to-Site VPN connections, vel tilkoplinga, Actions, Modify VPN tunnel options, vel den eksterne IP-en, slå på Tunnel activity log, vel gruppa og utdataformatet, lagre innanfor vindauget. Viss VPN-en blir styrt som kode, er det same klikket drift du vil jamne ut seinare.

For automatisering har aktivitetsloggdelen av tunnelvala ei fast form: LogOptions inneheld CloudWatchLogOptions med LogEnabled, LogGroupArn og LogOutputFormat. Den blokka er eit fragment, ikkje ein førespurnad; modify-vpn-tunnel-options treng framleis ID-en til tilkoplinga og den eksterne IP-en til tunnelen, og dei resterande tunnelinnstillingane må bli tekne vare på av den som eig malen. BGP-logging brukar sine eigne nøklar BgpLogEnabled, BgpLogGroupArn og BgpLogOutputFormat i same struktur. Les endringa tilbake med describe-vpn-connections i staden for å stole på at kallet vart brukt.

Kva registreringane kan og ikkje kan fortelje deg

Når den første tunnelen er ferdig og den tiltenkte vegen er tilgjengeleg, gjer den same kontrollerte sekvensen om att for den andre tunnelen viss du også treng loggane hans. Éin tunnel om gongen er heile poenget.

Registreringar kjem i straumar som blir identifiserte av tilkoplinga og den eksterne adressa til tunnelen, så korreler mot den identiteten i staden for å vente at historia dukkar opp retroaktivt. Ingenting før endringa finst, og inga venting fyller gapet. Viss du treng ei grunnlinje, registrer den noverande tilstanden til tunnelen og rutetabellen før endringa, slik at det er noko å samanlikne med.

Hald logggruppa, oppbevaringa, leveringsløyva og tunnelvalblokka i same oversyn som sjølve VPN-en, fordi dei er éin konfigurasjon spreidd over fire stader. AWS-prosedyren for å slå på loggar dokumenterer arbeidsflyten per tunnel og avbrotsvarselet, og han er verdt å lese før endringa i staden for etter. Stadfest deretter i rekkjefølgje: tunnelen kom tilbake, registreringar viser seg i den venta straumen, og registreringane svarar på spørsmålet du opna saka for. Viss det tredje feilar, var problemet valet av straum og ikkje logginga.