BGP обявления от VGW срещу таблицата с маршрути на VPC: какво какво променя

Липсващ префикс в таблицата с маршрути на подмрежа в VPC и липсващ префикс на рутера на клиента са две различни повреди и само една от тях се отстранява в таблиците с маршрути на AWS. Виртуалният частен шлюз обявява CIDR блоковете, свързани с неговия VPC; таблицата с маршрути на подмрежата решава накъде работният товар изпраща отговора. Да се третира второто като начин да се промени първото е най-честият грешен завой в тази диагностика. Изпълнете проверките по-долу по ред и дръжте двете посоки разделени.

Назованете прикачването, преди да четете която и да е таблица

VPN Site-to-Site завършва или на виртуален частен шлюз, или на транзитен шлюз, а идентификаторите на ресурсите определят кой модел на маршрутизация се прилага. Прочетете ги първо: aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 --query 'VpnConnections[].{Tunnels:VgwTelemetry,Gateway:GatewayId,Transit:TransitGatewayId}'. Отговорът ви казва дали следващата таблица за проверка е таблица с маршрути на VPC, или таблица с маршрути на транзитен шлюз.

Ако VPN е прикачен към транзитен шлюз, спрете да третирате таблицата с маршрути на VPC като контролна равнина. Там таблицата на VPC сочи към прикачването на шлюза, а асоциирането и разпространението се случват в таблицата с маршрути на транзитния шлюз. Смесването на двете гледни точки дава уверени изводи за грешния обект.

Посоката от AWS към офиса е обявление

За прикачване към VGW шлюзът обявява CIDR блоковете, свързани с неговия VPC, на шлюза на клиента по BGP. Добавянето на отделен маршрут за подмрежа или насочването на маршрут към партньорски VPC или към устройство не добавя друг свързан CIDR и не се появява в това обявление. Ако в офиса липсва префикс, сравнете списъка с получени маршрути с асоциациите на VPC, преди да редактирате каквато и да е таблица с маршрути.

Простото правило има изключения, затова го дръжте в обхват. Конфигурация VPN CloudHub може да пре-обявява префикси на обекти между шлюзовете на клиенти, а транзитният шлюз следва собствени правила за разпространение. Твърдението, че VGW обявява само своя VPC, е полезно подразбиране, а не закон, който покрива всяка топология, която ще срещнете.

Посоката от офиса към AWS е разпространение плюс избор

В обратната посока VGW научава префикса на офиса, но това само по себе си не мести работен товар. Таблицата с маршрути на подмрежата трябва или да има включено разпространение за прикачването, или да носи статичен маршрут към същата дестинация. Когато за един префикс съществуват и двете, статичният маршрут печели, а съвпадението по най-дълъг префикс се изпълнява преди всяко от тях.

Четете произхода, вместо да го предполагате: aws ec2 describe-route-tables --route-table-ids rtb-0123456789abcdef0 --query 'RouteTables[].Routes'. Запис с произход EnableVgwRoutePropagation е дошъл от BGP; запис с произход CreateRoute е въведен от човек и ще продължава да печели, докато някой не го изтрие.

Runbook, който държи двете посоки разделени

Запишете четири факта от страна на AWS, преди да промените нещо: типа на прикачването, свързаните CIDR блокове на VPC, произхода на маршрута в подмрежата за въпросния префикс и състоянието на тунела и BGP. Същото извикване describe връща VgwTelemetry с брой приети маршрути за всеки тунел, което ви казва дали AWS изобщо е приел някакви маршрути. След това сравнете това с онова, което клиентското устройство действително е инсталирало. Префикс, който присъства в BGP, но липсва в таблицата за препращане, е проблем с локален импорт или най-добър път, а не проблем с таблицата с маршрути на AWS.

Ако таблицата на подмрежата изобщо няма префикса, включете разпространение или добавете статичен маршрут, след което прочетете отново същата заявка след интервала на разпространение, вместо да приемате, че промяната е незабавна. Ако префиксът съществува, а трафикът все още се проваля, оставете контролната равнина на мира и преминете към пътя на данните.

Какво да не променяте, докато сте там

Не превключвайте разпространението на несвързани таблици с маршрути, за да поправите един липсващ префикс, и не добавяйте маршрут по подразбиране, за да прикриете един липсващ CIDR. И двете промени разширяват обхвата на въздействие и правят следващата диагностика по-трудна. Ограничете редакцията само до таблицата, която обслужва въпросната подмрежа на работния товар.

Пътят на данните е отделен от всичко това. Групите за сигурност са със състояние, мрежовите ACL не са, а защитна стена на хоста или асиметричен обратен път могат да отхвърлят трафик, който маршрутизацията е доставила правилно. Обявеният агрегат също не разрешава всяка услуга в него, затова ограничете достъпа на границата на политиката, вместо да разчитате дали даден адрес случайно се появява в BGP обявление.

Запазете състоянието преди и след всяка заявка към таблица с маршрути в записа за промени. Ако промяната влоши нещата, възстановете предишните маршрути и потвърдете със същата заявка, защото връщане назад, което не можете да проверите, е само предположение.