Чому ваше проброс портів VPN у Docker ніколи не доходить до OpenVPN

Ваш контейнер може слухати UDP 1195, поки хост публікує 1194, і це правильно, поки так каже зіставлення. Числа утворюють таблицю перекладу: клієнт набирає порт хоста, Docker переписує призначення на порт контейнера, а OpenVPN відповідає на порту, який називає його власна конфігурація. Розбіжність у будь-якій із цих ланок дає тиху відмову, схожу на міжмережевий екран. Сертифікати й шифри розташовані нижче й не можуть це виправити.

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

Три числа, одне з'єднання

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

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

Що насправді каже короткий синтаксис

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

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

ports:
  - 1194:1195/udp

Де пакет може зупинитися

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

Далі слухач: конфігурація OpenVPN називає порт і протокол, а клієнт, що приходить на інший порт усередині контейнера, нічого не досягає. Перевірка служби UDP через TCP нічого не доводить на жодному з цих етапів, тому використовуйте той транспорт, який використовуватиме клієнт.

Адреси прив'язки визначають доступність

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

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

Читайте поточний стан

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

Три різні стани, три різні команди, і лише остання стосується OpenVPN.

Коли зіставлення правильне

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

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