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

Три роли адресов путаются на одном AWS VPN: внешние партнёры, внутреннее звено /30 и защищённые префиксы 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 и анонсируемые префиксы для каждого туннеля в одну таблицу. Именно эта таблица делает следующее изменение обозримым.

Похожие статьи