Пули VPN з подвійним стеком: адресація обох родин у strongSwan

Внутрішні пули IPv4 і IPv6, захищені префікси та родина зовнішнього тунелю — це три окремі рішення. Сплануйте кожне, перш ніж називати це подвійним стеком.

Шлюз може видати мандрівному користувачеві і IPv4-, і IPv6-віртуальну адресу, тоді як зовнішній тунель усе ще йде поверх IPv4. Це незалежні рішення, і саме розгляд їх як одного — те місце, де плани подвійного стеку зазвичай розсипаються. Внутрішні родини клієнта, захищені префікси, до яких він може дістатися, і транспорт, що несе інкапсуляцію, — це три окремі вибори.

Більшість плутанини виникає через те, що слово «подвійний стек» застосовують до проєкту, який є подвійним стеком лише в одному місці. Служба може бути подвійним стеком усередині, одинарним стеком на своїй зовнішній адресі й усе одно чудово працювати для клієнтів. Чого вона не може — працювати випадково.

Дві родини всередині, один шлях зовні

Зовнішнє з’єднання — це IKE поверх UDP, і йому потрібна одна доступна родина адрес звідти, де перебуває клієнт. Внутрішній адресі IPv6 не потрібен провайдер із підтримкою IPv6, бо внутрішній пакет — це корисне навантаження всередині зовнішнього. Багато робочих розгортань переносять префікси IPv6 через канал, що підтримує лише IPv4.

Що зовнішній шлях справді обмежує, то це доступність і проходження NAT. Якщо шлюз оголошує лише адресу IPv4, клієнт у мережі лише з IPv6 взагалі не зможе підключитися, які б пули ви не налаштували. Обирайте зовнішню родину за своєю клієнтською базою, а не за внутрішнім планом адрес.

Дайте клієнтові адресу в кожній родині

Запит обох родин — це один рядок на боці клієнта, за умови, що шлюзові є що видавати. Іменовані пули тримають джерела окремо від сервісних мереж, і саме ця властивість робить правила міжмережевого екрана читабельними й через пів року.

pools {
  pool4 { addrs = 10.90.0.0/24 }
  pool6 { addrs = fd42:90::/64 }
}
connections {
  private-access {
    version = 2
    pools = pool4, pool6
    local  { auth = pubkey  certs = gateway.pem  id = vpn.example.com }
    remote { auth = pubkey  cacerts = ca.pem  vips = 0.0.0.0, :: }
    children {
      private { local_ts = 10.60.0.0/16, fd42:60::/48  remote_ts = dynamic }
    }
  }
}

Значення vips запитує по одній адресі з кожної родини, а список пулів вирішує, звідки беруться ці адреси. Документація strongSwan про віртуальні IP-адреси охоплює множинні запити й розподіл за пулами, включно з тим, що клієнт, який просить конкретну адресу, лише висловлює перевагу, яку відповідальна сторона може скасувати. Не створюйте правило доступу, яке припускає, що клієнт завжди отримує те саме значення.

Згенеруйте власний унікальний локальний префікс замість копіювання прикладу. Дві організації, які обидві fd42::/16 впровадять його, виявлять конфлікт під час першого взаємного з’єднання, і діагностувати це неприємно.

Селектори описують призначення, а не джерела

Локальні селектори трафіку дочірньої SA кажуть, які захищені мережі стоять за шлюзом, а віддалені селектори описують, що клієнт може використовувати як джерело. Адреса віртуального пулу належить до боку джерела цієї політики; ставити її до списку призначень — поширене хибне прочитання конфігурації.

Обидві родини потребують зворотних маршрутів і дозволеного пересилання на шлюзі. Додавання префікса до селектора без маршруту назад до пулу створює тунель, який встановлюється, пропускає один напрямок трафіку й мовчки відкидає відповідь. Селектор — це політика, а не маршрутизація.

Тримайте пули й сервісні префікси в окремих блоках плану адрес. Коли вони перетинаються, маршрут, який має дістатися захищеного хоста, може збігтися з адресою пулу й зникнути в тунелі.

DNS і шлях відповіді вирішують, чи виглядає це завершеним

Відповіді розв’язувача не залежать від транспорту, який використовується для його досягнення. Ім’я може повернути запис A, запис AAAA або обидва, а клієнт обирає за власними правилами переваги. Якщо внутрішня служба публікує запис AAAA, але ніщо не маршрутизує цей префікс, клієнти в мережах подвійного стеку спершу спробують шлях IPv6 і залишаться там, доки він не зазнає невдачі. Ніщо в конфігурації тунелю при цьому не виглядає неправильним.

Тож для кожного імені вирішіть, які родини мають бути придатними до використання, а потім перевірте, що відповідний префікс є в селекторі та має зворотний маршрут. Це рішення для кожної служби окремо. Публікація обох типів записів без розбору — це спосіб, у який робоча служба лише з IPv4 починає вичерпувати час очікування для половини своїх користувачів.

Перевірте обидві родини, перш ніж назвати це готовим

Конфігурація, яка завантажується, — не конфігурація, яка працює. Прочитайте стан, який повідомляє демон, підтвердьте розподіл за пулами, а потім подивіться на маршрути, які клієнт справді встановив.

swanctl --list-sas
swanctl --list-pools
ip -6 addr show scope global
ip -6 route get fd42:60::10

Перші дві команди показують встановлені дочірні SA і те, у яких пулах ще є вільні адреси, тож план, що працює для першого клієнта й зривається на десятому, стає видимим. Останні дві показують, чи отримав клієнт глобальну адресу IPv6 із пулу і куди насправді піде трафік до захищеного префікса. Порівнюйте видану адресу з пулом, який ви налаштували, а не з адресою, на яку сподівалися. Якщо відповідальна сторона обрала інше значення за своєю політикою, маршрути й правила міжмережевого екрана все одно мають відповідати її вибору.

Потім перевірте по одному захищеному хосту на кожну родину й ім’я, що розв’язується в обидві. Тест однієї родини нічого не каже про ту половину плану, яку ви не задіяли, і саме там зазвичай перебуває відсутній маршрут.

Схожі статті