AWS Site-to-Site VPN: външни, вътрешни адреси и LAN префикс

Повечето грешки в AWS Site-to-Site VPN са грешки в адресите и се правят, преди да е мръднал какъвто и да е пакет. Външните адреси на тунела стигат до партньорите по IPsec, вътрешните адреси образуват маршрутизиращата връзка между тях, а защитените префикси са това, за което служи тази връзка. Копирайте една роля в друга и тунелът се вдига, докато нищо не се маршрутизира. Ето последователността прочети-провери-конфигурирай, която използвам на клиентски шлюз с BGP, като стойностите са взети от изтеглената конфигурация на устройството, а не от паметта.

Три роли на адресите, един тунел

Външните адреси са публични и принадлежат на партньорите по IPsec: по един на тунел от страна на AWS и достижимата идентичност на клиентския шлюз от ваша страна, съобразена с каквато и NAT схема да имате. Вътрешните адреси са частни и принадлежат на логическата връзка, която AWS документира като /30, взета от 169.254.0.0/16. Защитените префикси са VPC, локалните или транзитните мрежи, които маршрутизирате и обявявате през тази връзка.

Задаването на LAN префикс като адрес на интерфейса на тунела е класическата форма на тази грешка. Интерфейсът изглежда конфигуриран, LAN не се обявява, а отсрещната страна няма маршрут към него. Тунелът може дори да мине собствения си вътрешен ping, докато всяко име на приложение изтича. Справочникът с опции на тунела изброява ограниченията за вътрешния CIDR, включително диапазона, от който трябва да идва.

Четете стойностите от изтеглената конфигурация

Изтеглете конфигурацията за конкретния модел устройство от връзката и след това третирайте таблицата с адреси като източник на истина. Конзолата показва същите стойности за всеки тунел: външен IP, вътрешен CIDR и адресът на BGP партньора от страна на AWS. Двата тунела са отделни обекти с отделни външни крайни точки и отделни вътрешни /30, макар и двата да носят същите защитени мрежи.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

Ако изтегленият файл и живата конзола се разминават, файлът е остарял. Изтеглете отново, вместо да редактирате адреси на ръка, защото несъответствието между вътрешната двойка и конфигурирания съсед на партньора е тих отказ на BGP.

Изградете връзката с правилния адрес върху нея

На Linux шлюз тунелът е интерфейс VTI или XFRM и вътрешният /30 отива на този интерфейс. Два тунела означават два интерфейса и два BGP съседа, по един на крайна точка на AWS. Конвенцията, която AWS отпечатва в изтеглената конфигурация на устройството, поставя виртуалния частен шлюз на първия адрес на всеки вътрешен /30, а вашия клиентски шлюз на втория, така че вие вземате по-високия адрес и установявате партньорство с по-ниския. Тук нищо не изисква LAN адрес.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

Ако файлът за вашия модел устройство отпечатва обратната двойка, използвайте неговите числа и спазвайте правилото: адресът на интерфейса е ваш, адресът на партньора принадлежи на AWS. Обръщането на това дава тунел, който никога не достига Established, защото съседът, който сте конфигурирали, е адресът, който вашият собствен интерфейс вече държи.

Дръжте марката и VTI ключа съгласувани с това, което демонът IKE използва, за да обвърже дъщерна SA с интерфейса, иначе трафикът пристига на тунела без интерфейс, на който да кацне. Проверявайте MTU спрямо пътя и спрямо собствените настройки на демона IKE, вместо да копирате число от друг сайт.

Проверете BGP, преди да проверявате маршрутите

Вдигането на IPsec доказва, че партньорите са се съгласили за асоциация за сигурност, и нищо друго. Сесията BGP е отделна договорка през вътрешната връзка, затова четете състоянието на съседа и броячите на префикси, после ги сравнете с това, което сте възнамерявали да обявите.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Състояние Established с нула получени префикси е проблем с политика или обявяване, а не проблем с тунела. Повторете цялата проверка на втория тунел; работещият първи тунел ви казва, че адресите са правдоподобни, а не че вторият тунел изобщо е конфигуриран.

Проследете маршрутизиран пакет и спрете

След като сесията носи префиксите, тествайте маршрута в двете посоки от шлюза: адрес на източника, следващ хоп и политиката за сигурност, която разрешава трафика. Сесия BGP може да е вдигната, докато конкретният префикс, който приложението ви иска, е филтриран, обобщен или насочен към грешния интерфейс.

Reachability Analyzer е инструментът от страна на AWS, който приема източник, дестинация и път и съобщава кой компонент в поддържана конфигурация го е блокирал. Използвайте го, за да тествате пътя от VPC до адреса на клиентския си шлюз, а не от хост на приложение. Той анализира конфигурация и не изпраща пакет през локална защитна стена, затова дръжте присъдата му отделно от собствените си броячи на интерфейса и снимки на пакети.

Запишете външната двойка, вътрешния /30 и обявените префикси за всеки тунел в една таблица. Именно тази таблица прави следващата промяна прегледима.