strongSwan vips: як попросити у IKEv2 віртуальну адресу

vips запитує внутрішню адресу IKEv2; шлюз вирішує, що видати. Налаштуйте запит, завантажте його, а потім перевірте, що саме призначив відповідач.

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

Що запитує vips і чого він не може обіцяти

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

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

Фрагмент swanctl і де він міститься

Параметр міститься всередині блоку з'єднання, не в окремому файлі й не в профілі операційної системи. Цей ізольований фрагмент показує форму:

connections {
  net {
    local_addrs = 192.0.2.10
    remote_addrs = 203.0.113.5
    vips = 10.77.0.31
    children {
      net { local_ts = dynamic remote_ts = 10.77.0.0/24 }
    }
  }
}

Завантажте його файлом, якому належить з'єднання, потім запустіть з'єднання й прочитайте результат. Фрагмент, вставлений не в той розділ, дає помилку розбору або, що гірше, з'єднання, яке завантажується без запиту, який ви, як вам здавалося, зробили. Виконайте три команди по порядку й збережіть вивід.

swanctl --load-all --file /etc/swanctl/swanctl.conf
swanctl --initiate --child net
swanctl --list-sas

local_ts вибирає трафік, а не створює адресу

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

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

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

Перевірте, що саме призначив відповідач

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

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

Тримайте статичну схему окремо

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

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

Схожі статті