Трябва ли да включите регистри на 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 за включване на регистри документира работния процес за всеки тунел и предупреждението за прекъсване и си струва да се прочете преди промяната, а не след нея. След това проверете по ред: тунелът се върна, записите се появяват в очаквания поток и записите отговарят на въпроса, за който отворихте тикета. Ако третото се провали, проблемът е бил в избора на поток, а не в регистрирането.