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 і анонсовані префікси для кожного тунелю в одну таблицю. Саме ця таблиця робить наступну зміну придатною для перегляду.

Схожі статті