Дали треба да овозможите 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 за овозможување дневници го документира работниот тек по тунел и неговото предупредување за прекин, и вреди да се прочита пред промената, а не по неа. Потоа проверете по ред: тунелот се врати, записите се појавуваат во очекуваниот тек и записите одговараат на прашањето поради кое го отворивте тикетот. Ако третото не успее, проблемот беше изборот на тек, а не логирањето.