Да ли треба омогућити записе тунела AWS VPN на активном тунелу?

Укључивање записа активности тунела за Site-to-Site VPN мала је промена која може оборити тунел који мери. AWS упозорава да омогућавање евидентирања на постојећем тунелу може прекинути тунел на неколико минута, па занимљиво питање није како пребацити заставицу, него на ком тунелу је пребацити и када. Три услова одређују редослед: носи ли други тунел заиста руте, требају ли вам сервисни догађаји или BGP догађаји, и иде ли промена кроз конзолу или кроз API опција тунела. Погрешите ли, завршићете или с прекидом или с групом записа пуном ничега.

Три услова одређују редослед

Почните од идентитета ствари коју мењате. Требају вам ID VPN везе, регион и спољна IP адреса конкретног тунела, јер је свако подешавање записа у овој функцији по тунелу, а не по вези. Промена примењена на погрешну спољну адресу промена је тунела који нико није отклањао.

Одредиште је група записа CloudWatch у истом региону, са политиком задржавања и приступа коју заиста желите. AWS препоручује префикс /aws/vendedlogs/ за те групе јер избегава ограничења величине политике ресурса на која могу наићи обична имена. Име попут /aws/vendedlogs/vpn/branch-a-activity само је илустрација; важно је да група постоји, да у њу може писати улога за доставу и да обоје води онај ко поседује конфигурацију VPN-а. Име не даје дозволе, а група створена без политике доставе производи тишину, а не грешку.

Први услов: резервни тунел који заиста носи саобраћај

То је услов који тимови прескачу. Два конфигурисана тунела нису доказ да апликација има употребљив алтернативни пут.

Пре него што додирнете један тунел, потврдите да други носи важне руте: проверите табелу рутирања на страни корисничког пролаза и потврдите да апликација заиста може да се пребаци. Прозор прекида AWS-а траје минутима, не секундама, а тунел који постоји само на папиру претвара дијагностичку промену у прекид. Ако резервни пут није доказан, испланирајте промену са истом пажњом као и сваку другу промену рутирања, уместо да евидентирање третирате као пасивно. Инструментирајте тунел чије понашање покушавате да објасните, а не онај до којег је лакше доћи.

Други услов: запис активности или BGP запис

Овај услов одлучује шта ћете заиста моћи да прочитате. Записи активности покривају сервисне догађаје попут прелаза стања IKE и IPsec и DPD порука, што желите када се тунел не подиже или стално обнавља кључеве. BGP записи су засебан ток са својим контролама и одговарају на друго питање: да ли су руте разменене и повучене како се очекивало.

Укључивање заставице активности није захтев за сваки ток који сервис може да емитује. Ако је сумња у рутирању, укључите обоје; ако је сумња у преговоре фазе 1 или фазе 2, ток активности је онај који ће то показати.

Ниједан ток није хватање пакета и та разлика решава више тикета него што би требало. Записи активности и BGP говоре шта је сервис урадио са тунелом и сесијом, а не шта је ваша апликација послала кроз њих. Посезање за записима тунела да бисте отклонили апликацијски тајмаут је грешка категорије и обично кошта један прозор прекида пре него што ико примети. Прво одаберите питање, затим ток који на њега може да одговори.

Трећи услов: промена кроз конзолу или API опција тунела

Ако човек ради једнократну промену, пут кроз конзолу је у реду: VPC console, Site-to-Site VPN connections, одаберите везу, Actions, Modify VPN tunnel options, одаберите спољни IP, укључите Tunnel activity log, одаберите групу и излазни формат, сачувајте унутар прозора. Ако се VPN управља као код, исти клик је дрифт који ћете касније усагласити.

За аутоматизацију, део опција тунела који се тиче записа активности има фиксни облик: LogOptions садржи CloudWatchLogOptions са LogEnabled, LogGroupArn и LogOutputFormat. Тај блок је фрагмент, не захтев; modify-vpn-tunnel-options и даље треба ID везе и спољни IP тунела, а преостала подешавања тунела мора да сачува онај ко поседује шаблон. BGP евидентирање користи своје кључеве BgpLogEnabled, BgpLogGroupArn и BgpLogOutputFormat у истој структури. Прочитајте промену назад помоћу describe-vpn-connections уместо да верујете да се позив применио.

Шта вам записи могу, а шта не могу рећи

Кад је први тунел готов и жељени пут доступан, поновите исти контролисани след за други тунел ако вам требају и његови записи. Један тунел одједном је цела поента.

Записи долазе у токовима које идентификују веза и спољна адреса тунела, па корелирајте са тим идентитетом уместо да очекујете да ће се историја појавити ретроактивно. Ништа пре промене не постоји и никакво чекање не попуњава празнину. Ако вам треба основна линија, забележите тренутно стање тунела и табелу рутирања пре промене да бисте имали са чим да упоредите.

Држите групу записа, њено задржавање, њене дозволе за доставу и блок опција тунела у истом инвентару као и сам VPN, јер је то једна конфигурација распоређена на четири места. AWS поступак за укључивање записа документује ток рада по тунелу и његово упозорење о прекиду, и вреди га прочитати пре промене, а не после. Затим проверите редом: тунел се вратио, записи се појављују у очекиваном току и записи одговарају на питање због којег сте отворили тикет. Ако треће не успе, проблем је био избор тока, а не евидентирање.