Повний тунель у strongSwan потребує 0.0.0.0/0 з обох боків

Повному тунелю потрібен 0.0.0.0/0 як remote_ts клієнта і як local_ts шлюзу, плюс пересилання, NAT і зворотний маршрут. Перевірте всі чотири.

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

Спершу перевірте селектор клієнта

Клієнт описує те, що хоче захистити на дальньому боці, як remote_ts, і все, що він надсилає, походить з його власної призначеної адреси. Для інтернет-трафіку це значення має охоплювати адреси, яких користувач справді досягне, що на практиці означає весь простір IPv4. Клієнт, який досі перелічує одну підмережу, просить розділений тунель, хоч би як називався профіль в інтерфейсі. Бік джерела зазвичай dynamic, оскільки адреса призначається під час підключення. Фіксоване джерело, записане там, ламається, щойно змінюється пул адрес.

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

Цей фрагмент не є повним файлом підключення, і він припускає, що автентифікація, ідентичності та пул віртуальних адрес уже налаштовані. Селектор джерела клієнта й адреса, яку призначає сервер, усе ще мають збігатися, інакше child SA підніметься з обсягом, якого не очікувала жодна сторона. Завантажте його за допомогою swanctl --load-all і прочитайте вивід, перш ніж вважати, що все вдалося. Файл, який розбирається, усе одно може бути відхилений через селектор, що не перетинається з пропозицією іншої сторони.

Перевірте селектор шлюзу на його власному боці

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

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

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

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

Перевірте узгоджений child SA, а не файл

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

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

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

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

Перевірте пересилання та зворотний маршрут

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

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

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

Перевірте, чого тунель досі не охоплює

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

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

Підтвердьте ланцюг цими двома командами та узгодженими селекторами зі списку вище. Якщо traceroute показує локальний маршрутизатор першим переходом, трафік не використовує тунель, хоч би що стверджували селектори. Доступ до інтернету повний лише тоді, коли вибраний трафік допущено, переслано й повернено через спроєктований шлюз. Знайти 0.0.0.0/0 у профілі — це початок цього ланцюга, а не його доказ.

Схожі статті