Хост досягає IPsec-партнера, контейнер Docker — ні

Ви пінгуєте віддалений хост з машини Linux, і він відповідає, отже тунель працює. Контейнер поруч усе ще виходить у тайм-аут, і природний наступний крок — перезапустити Docker. Контейнер у мостовій мережі зазвичай починається з іншої адреси джерела і входить у хост через пересилання, а не через власний вихідний шлях застосунку на хості, тому успішний тест виміряв інший пакет. Для тунелю strongSwan на основі політик звичайного маршруту до віддаленої підмережі недостатньо, коли пересланий пакет не відповідає встановленій політиці IPsec.

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

Почніть з однієї цілі та двох джерел

Спершу виберіть відому службу за IP, щоб не налагоджувати одночасно DNS. Запишіть три факти: мостовий префікс контейнера, адресу джерела успішного запиту з хоста та узгоджені локальні й віддалені селектори трафіку для тунелю. Ці три числа пояснюють майже кожен випадок цього симптому.

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

Прочитайте політики, перш ніж торкатися Docker

Перевірки хоста лише для читання охоплюють рішення маршрутизації, базу політик і правила, що вибирають між ними:

ip rule show
ip route show table all
ip xfrm policy

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

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

Перевірте фільтрування й переклад по черзі

Мостовий файрвол Linux у Docker може блокувати пересилання незалежно від IPsec. З бекендом iptables огляньте шлях FORWARD і рішення DOCKER-USER, пам'ятаючи, що правило, додане після раннього вердикту, може ніколи не виконатися. Бекенд nftables інтегрується інакше, тому не створюйте ланцюг DOCKER-USER лише тому, що приклад iptables так його назвав; перевірте, який бекенд ваш демон справді використовує.

Потім перевірте переклад джерела. Широке правило MASQUERADE може перетворити пакет, який раніше відповідав селектору IPsec, на такий, що вже не відповідає, і збій виглядає точно як проблема маршрутизації. посібник з пересилання strongSwan документує виняток NAT, потрібний перед таким перекладом для трафіку, що вже відповідає політиці.

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

Потім вирішіть: маршрутизовано чи перекладено

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

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

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

Перевіряйте новим з'єднанням, а не перезапуском

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

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