Від strongSwan до AWS Site-to-Site: чому Child SA нічого не вибирає

Тунель IKE може бути піднятий, але дочірня асоціація виключає ваші підмережі. Спершу порівняйте локальний і віддалений CIDR у AWS з leftsubnet і rightsubnet.

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

Перекладіть назви AWS у терміни strongSwan

AWS описує з’єднання з боку клієнта: адреса клієнтського шлюзу й локальний CIDR належать вам, а віддалений CIDR належить VPC. strongSwan називає два кінці left і right, ваш префікс у leftsubnet, а префікс VPC — у rightsubnet. Перестановка однієї пари дає тунель, який узгоджує й вибирає неправильний трафік.

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

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

Зафіксуйте адресу, яку AWS справді бачить

Маршрутизатор за NAT може надсилати IKE з інтерфейсу, про який інша сторона ніколи не знала. Адреса шлюзу, записана в AWS, має бути тією, яку AWS спостерігає в мережі, а маршрутизатор треба прив’язати до тієї самої локальної адреси замість дотримання маршруту за замовчуванням.

conn %default
    local_addrs = 203.0.113.10

У strongSwan local_addrs вибирає адресу джерела для IKE, а старіші конфігурації OpenSwan записують ту саму ідею як left. Спрямуйте його на інтерфейс із публічною адресою, потім перевірте на самому пристрої NAT, що UDP 500 і 4500 доходять до цього хоста, бо правило, яке лишилося від попереднього маршрутизатора, мовчки їх відкидає. Правильна пара селекторів із неправильною адресою джерела все одно не працює, і журнал звинуватить пропозицію. Саме ця плутанина є причиною, чому адреса джерела заслуговує окремої перевірки.

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

Розглядайте фазу 1 і фазу 2 окремо

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

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

Синтаксис не переноситься між реалізаціями. Пару, що працює в OpenSwan, наприклад phase2alg=aes_gcm з ike=aes256-sha1;modp1024, треба перекласти у форму esp= і ike= strongSwan, і назви алгоритмів різняться. Оскільки GCM автентифікує під час шифрування, йому не потрібна окрема трансформація цілісності, на відміну від набору CBC у парі з SHA. Рядок фази 2, вставлений з одного демона в інший без перекладу, дає відмову, яка читається як розбіжність селекторів.

Перевіряйте дочірню асоціацію, а не індикатор тунелю

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

ipsec statusall

Знайдіть дочірню асоціацію безпеки й прочитайте надруковані поряд селектори трафіку, потім порівняйте їх із префіксами зі створеної конфігурації.

Перевірте з хоста в локальному префіксі до хоста в префіксі VPC і перегляньте зворотний шлях, а також будь-яку групу безпеки чи мережевий ACL на боці AWS. Правильні селектори не захищають пакет від пізнішого відкидання.

Коли після збігу селекторів усе ще не працює

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

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

Запишіть селектори, пропозиції фази 1 і фази 2 та адресу джерела у заявку. Ці чотири значення пояснюють більшість збоїв site-to-site без дзвінка.

Схожі статті