Moet jy AWS VPN-tonnel-logs op 'n lewendige tonnel aktiveer?

Die aanskakel van tonnel-aktiwiteitslogs vir 'n Site-to-Site VPN is 'n klein verandering wat die tonnel wat dit meet, kan laat val. AWS waarsku dat die aktivering van logs op 'n bestaande tonnel dit vir etlike minute kan onderbreek, so die interessante vraag is nie hoe om die vlag om te skakel nie, maar op watter tonnel om dit om te skakel en wanneer. Drie voorwaardes bepaal die volgorde: of die ander tonnel werklik die roetes dra, of jy diensgebeurtenisse of BGP-gebeurtenisse nodig het, en of die verandering deur die konsole of deur die tonnel-opsie-API gaan. Kry dit verkeerd en jy sit óf met 'n onderbreking óf met 'n loggroep vol niks.

Drie voorwaardes bepaal die volgorde

Begin by die identiteit van die ding wat jy verander. Jy het die VPN-verbinding-ID, die streek en die buite-IP-adres van die spesifieke tonnel nodig, want elke loginstelling in hierdie funksie is per tonnel eerder as per verbinding. 'n Verandering wat op die verkeerde buite-adres toegepas word, is 'n verandering aan 'n tonnel wat niemand ontfout het nie.

Die bestemming is 'n CloudWatch-loggroep in dieselfde streek, met die retensie en toegangsbeleid wat jy werklik wil hê. AWS beveel die /aws/vendedlogs/-voorvoegsel vir hierdie groepe aan, want dit vermy die groottebeperkings van hulpbronbeleide wat gewone name kan tref. 'n Naam soos /aws/vendedlogs/vpn/branch-a-activity is net illustratief; wat saak maak, is dat die groep bestaan, dat die afleweringsrol daarin kan skryf, en dat albei bestuur word deur wie die VPN-konfigurasie besit. Die naam verleen nie toestemmings nie, en 'n groep wat sonder die afleweringsbeleid geskep is, lewer stilte eerder as 'n fout.

Voorwaarde een: 'n oortollige tonnel wat werklik verkeer dra

Dit is die voorwaarde wat spanne oorslaan. Twee gekonfigureerde tonnels is nie 'n bewys dat die toepassing 'n bruikbare alternatiewe pad het nie.

Voordat jy een tonnel aanraak, bevestig dat die ander een die roetes dra wat saak maak: kyk na die roetetabel aan die klantpoort-kant en bevestig dat die toepassing werklik kan oorskakel. AWS se onderbrekingsvenster is minute, nie sekondes nie, en 'n tonnel wat net op papier bestaan, verander 'n diagnostiese verandering in 'n onderbreking. As die oortollige pad onbewys is, beplan die verandering met dieselfde sorg as enige ander roeteverandering in plaas daarvan om logs as passief te beskou. Instrumenteer die tonnel wie se gedrag jy probeer verduidelik, nie die een wat makliker bereikbaar is nie.

Voorwaarde twee: aktiwiteitslog of BGP-log

Hierdie een bepaal wat jy werklik sal kan lees. Aktiwiteitsrekords dek diensgebeurtenisse soos IKE- en IPsec-toestandsoorgange en DPD-boodskappe, wat jy wil hê wanneer die tonnel nie opkom nie of aanhou her-sleutel. BGP-rekords is 'n aparte stroom met sy eie kontroles, en hulle beantwoord 'n ander vraag: of roetes uitgeruil en onttrek is soos verwag.

Die aktivering van die aktiwiteitsvlag is nie 'n versoek vir elke stroom wat die diens kan uitstuur nie. As die vermoede roetering is, aktiveer albei; as die vermoede fase 1 of fase 2-onderhandeling is, is die aktiwiteitsstroom die een wat dit sal wys.

Nie een van die twee strome is 'n pakkie-opname nie, en daardie onderskeid beslis meer kaartjies as wat dit behoort. Aktiwiteits- en BGP-rekords vertel jou wat die diens met die tonnel en die sessie gedoen het, nie wat jou toepassing daardeur gestuur het nie. Om na tonnel-logs te gryp om 'n toepassing se tydsverloop te ontfout, is 'n kategorie-fout, en dit kos gewoonlik 'n onderbrekingsvenster voordat iemand dit agterkom. Kies eers die vraag, dan die stroom wat dit kan beantwoord.

Voorwaarde drie: konsole-verandering of tonnel-opsie-API

As 'n mens 'n eenmalige verandering maak, is die konsole-pad reg: VPC console, Site-to-Site VPN connections, kies die connection, Actions, Modify VPN tunnel options, kies die outside IP, aktiveer Tunnel activity log, kies die groep en die uitvoerformaat, stoor binne die venster. As die VPN as kode bestuur word, is dieselfde klik afwyking wat jy later sal versoen.

Vir outomatisering het die aktiwiteitslog-gedeelte van die tonnel-opsies 'n vaste vorm: LogOptions wat CloudWatchLogOptions bevat met LogEnabled, LogGroupArn en LogOutputFormat. Daardie blok is 'n fragment, nie 'n versoek nie; modify-vpn-tunnel-options het steeds die verbinding-ID en die tonnel se buite-IP nodig, en die oorblywende tonnel-instellings moet deur wie die sjabloon besit, bewaar word. BGP-logging gebruik sy eie BgpLogEnabled, BgpLogGroupArn en BgpLogOutputFormat sleutels in dieselfde struktuur. Lees die verandering terug met describe-vpn-connections in plaas daarvan om te vertrou dat die oproep toegepas is.

Wat die rekords jou kan en nie kan vertel nie

Sodra die eerste tonnel klaar is en die beoogde pad beskikbaar is, herhaal dieselfde beheerde reeks vir die tweede tonnel as jy ook sy logs nodig het. Een tonnel op 'n slag is die hele punt.

Rekords kom in strome aan wat deur die verbinding en die tonnel se buite-adres geïdentifiseer word, so korreleer teen daardie identiteit eerder as om te verwag dat geskiedenis terugwerkend sal verskyn. Niks voor die verandering bestaan nie, en geen mate van wag vul die gaping nie. As jy 'n basislyn nodig het, neem die huidige tonnel-toestand en roetetabel voor die verandering op sodat daar iets is om teen te vergelyk.

Hou die loggroep, sy retensie, sy afleweringsregte en die tonnel-opsieblok in dieselfde inventaris as die VPN self, want hulle is een konfigurasie wat oor vier plekke versprei is. Die AWS enable-logs procedure dokumenteer die per-tonnel werkstroom en sy onderbrekingswaarskuwing, en dit is die moeite werd om dit voor die verandering te lees eerder as daarna. Verifieer dan in volgorde: die tonnel het teruggekom, rekords verskyn in die verwagte stroom, en die rekords beantwoord die vraag waarvoor jy die kaartjie oopgemaak het. As die derde een misluk, was die probleem die keuse van stroom eerder as die logboeke.