Moatte jo AWS VPN-tunellogboeken oansette op in libbene tunnel?

It oansette fan tunnel-aktiviteitslogboeken foar in Site-to-Site VPN is in lytse feroaring dy't de tunnel dy't it mjit, delslaan kin. AWS warskôget dat it oansette fan logboekjen op in besteande tunnel dy minuten lang ûnderbrekke kin, dus de nijsgjirrige fraach is net hoe jo de flagge omkeare, mar op hokker tunnel jo dat dogge en wannear. Trije betingsten bepale de folchoarder: oft de oare tunnel de rûtes wier draacht, oft jo tsjinstbarren of BGP-barren nedich binne, en oft de feroaring fia de konsole of fia de tunnelopsje-API giet. Krij jo dat mis, dan einigje jo mei in ûnderbrekking of mei in loggroep fol neat.

Trije betingsten bepale de folchoarder

Begjin by de identiteit fan wat jo feroarje. Jo hawwe de VPN-ferbining-ID, de regio en it bûten-IP-adres fan de spesifike tunnel nedich, want elke logynstelling yn dizze funksje is per tunnel ynstee fan per ferbining. In feroaring op it ferkearde bûtenadres is in feroaring oan in tunnel dy't nimmen oan it debuggen wie.

It bestimmingsplak is in CloudWatch-loggroep yn deselde regio, mei de bewarring en tagongspolityk dy't jo echt wolle. AWS advisearret it foarheaksel /aws/vendedlogs/ foar dizze groepen, omdat it de gruttebeheiningen fan boarnepolityk foarkomt dêr't gewoane nammen tsjin oanrinne kinne. In namme lykas /aws/vendedlogs/vpn/branch-a-activity is allinnich yllustratyf; wat telt is dat de groep bestiet, dat de leveringsrol deryn skriuwe kin en dat beide beheard wurde troch wa't de VPN-konfiguraasje besit. De namme jout gjin tastimmingen, en in groep makke sûnder it leveringsbelied produsearret stilte ynstee fan in flater.

Betingst ien: in redundante tunnel dy't wier ferkear draacht

Dit is de betingst dy't teams oerslaan. Twa konfigurearre tunnels binne gjin bewiis dat de applikaasje in brûkbere alternative rûte hat.

Foardat jo ien tunnel oanreitsje, befêstigje dat de oare de rûtes draacht dy't fan belang binne: kontrolearje de rûteringstabel oan de kant fan de klantpoarte en befêstigje dat de applikaasje wier oerskeakelje kin. It ûnderbrekkingsfinster fan AWS is minuten, gjin sekonden, en in tunnel dy't allinnich op papier bestiet makket fan in diagnostyske feroaring in ûnderbrekking. As de redundante rûte net bewiisd is, plan dan de feroaring mei deselde soarch as elke oare rûteringsferoaring ynstee fan logboekjen as passyf te behanneljen. Ynstrumint hjirby de tunnel waans gedrach jo besykje te ferklearjen, net dy't it maklikst te berikken is.

Betingst twa: aktiviteitslog of BGP-log

Dizze bepale wat jo eins lêze kinne. Aktiviteitsregistraasjes beslaan tsjinstbarren lykas IKE- en IPsec-steatoergongen en DPD-berjochten, dat is wat jo wolle as de tunnel net omheech komt of hieltyd kaai fernijt. BGP-registraasjes binne in aparte stream mei eigen kontrôles, en se beantwurdzje in oare fraach: oft rûtes útwiksele en weromlutsen binne sa't ferwachte.

It oansette fan de aktiviteitsflagge is gjin oanfraach foar elke stream dy't de tsjinst útstjoere kin. As it fermoeden rûtering is, set dan beide oan; as it fermoeden de ûnderhanneling fan faze 1 of faze 2 is, dan is de aktiviteitsstream dy't it sjen lit.

Gjin fan beide streams is in pakketopname, en dat ûnderskied beslist mear kaartsjes as it heart. Aktiviteits- en BGP-registraasjes fertelle jo wat de tsjinst mei de tunnel en de sesje dien hat, net wat jo applikaasje dertroch stjoerd hat. Nei tunnelboeken grypte om in applikaasje-timeout te debuggen is in kategoryflater, en it kostet meast in ûnderbrekkingsfinster foardat immen it merkt. Kies earst de fraach, dan de stream dy't it beantwurdzje kin.

Betingst trije: konsolesferoaring of tunnelopsje-API

As in minske in ienmalige feroaring docht, is it konsolespoar goed: VPC console, Site-to-Site VPN connections, kies de ferbining, Actions, Modify VPN tunnel options, kies it bûten-IP, set Tunnel activity log oan, kies de groep en it útfiermformaat, bewarje binnen it finster. As de VPN as koade beheard wurdt, is deselde klik drift dy't jo letter ferienje.

Foar automatisearring hat it aktiviteitslog-diel fan 'e tunnelopsjes in fêste foarm: LogOptions befettet CloudWatchLogOptions mei LogEnabled, LogGroupArn en LogOutputFormat. Dat blok is in fragmint, gjin oanfraach; modify-vpn-tunnel-options hat noch de ferbining-ID en it bûten-IP fan de tunnel nedich, en de oare tunnelynstellingen moatte bewarre wurde troch wa't it sjabloan besit. BGP-logboekjen brûkt syn eigen kaaien BgpLogEnabled, BgpLogGroupArn en BgpLogOutputFormat yn deselde struktuer. Lês de feroaring werom mei describe-vpn-connections ynstee fan te fertrouwen dat de oprop tapast is.

Wat de registraasjes jo wol en net fertelle kinne

As de earste tunnel dien is en it bedoelde paad beskikber is, werhelje dan deselde kontrolearre sekwinsje foar de twadde tunnel as jo syn logboeken ek nedich hawwe. Ien tunnel tagelyk is it hiele punt.

Registraasjes komme yn streams dy't identifisearre wurde troch de ferbining en it bûtenadres fan de tunnel, dus korrelaasje mei dy identiteit ynstee fan te ferwachtsjen dat skiednis efterôf ferskynt. Neat foar de feroaring bestiet, en gjin wachtsjen follet it gat. As jo in basisline nedich hawwe, fêstlizzen dan de hjoeddeistige tunnelstân en de rûteringstabel foar de feroaring, sadat der wat is om mei te fergelykjen.

Hâld de loggroep, syn bewarring, syn leveringstastimmingen en it tunnelopsjeblok yn deselde ynventaris as de VPN sels, want it is ien konfiguraasje ferspraat oer fjouwer plakken. De AWS-proseduere foar it oansetten fan logboeken dokumintearret de per-tunnel wurkstream en syn ûnderbrekkingswarskôging, en it is de muoite wurdich om dy foar de feroaring te lêzen ynstee fan dêrnei. Ferifiearje dan yn folchoarder: de tunnel kaam werom, registraasjes ferskine yn 'e ferwachte stream, en de registraasjes beantwurdzje de fraach wêrom't jo it kaartsje iepene hawwe. As de tredde mislearret, wie it probleem de kar fan stream en net it logboekjen.