OpenVPN за stunnel: пересилайте обгортку, а не порт 1194

Поставте TLS-обгортку перед OpenVPN, і розгортання отримає другий слухач, з яких лише один має коли-небудь дивитися в інтернет. Коли тунель працює з тієї самої машини й не працює ззовні, переадресація зазвичай спрямована на неправильний із двох. Збігатися має ланцюг: публічне правило доходить до обгортки, а власне backend-з'єднання обгортки доходить до справжнього VPN-сокета. Чотири стрибки несуть цей ланцюг, і будь-який із них може завершити розслідування достроково.

Два сокети, два власники, один із них публічний

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

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

Куди насправді потрапляє переадресація

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

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

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Адреса прив'язки, що вас відхиляє

Рядок accept, прив'язаний до 127.0.0.1, відповідає лише самому хосту, тож переадресація, що надходить на адресу LAN, не може підключитися, і клієнт бачить відмову, яка звучить як проблема пакетного фільтра. Подивіться на сокет, перш ніж торкатися міжмережевого екрана, бо сокет — дешевша відповідь. Або прив'яжіть обгортку до інтерфейсу, на який націлена переадресація, або залиште її на loopback і зробіть так, щоб переадресація досягала loopback через щось справді робоче. Це два проєкти, і кожному потрібне своє правило.

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

ss -lntp '( sport = :8443 )'

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

Успіх, записаний без стрибка, який він покривав, не є доказом щодо інших стрибків. Запишіть, яку адресу використав тест і який процес відповів. Потім повторіть ззовні мережі, а не з телефона в тій самій мережі Wi-Fi, бо поведінка шпильки різниться між маршрутизаторами, і з'єднання, яке ніколи не покидало LAN, може задовольнити клієнта без жодної участі переадресації. Лише та друга спроба тренує шлях, яким іде сторонній.

Коли спроба не вдається, простежте одне з'єднання обома журналами: прийняті та підключені рядки обгортки, потім власний журнал сеансу демона VPN. Перша межа, яка нічого не записує, — це місце наступної зміни. Щойно OpenVPN починає порівнювати параметри партнера, судіть ці повідомлення за правилами тієї реалізації. Попередження про невідповідність link-mtu не є автоматично фатальним, закріплення link-mtu на 1500 не доводить, що фрагментація припинилася, а узгодження шифру належить внутрішній конфігурації OpenVPN, а не переадресації маршрутизатора.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

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

Дві ідентичності, два порядки відмови

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

посібник stunnel точно визначає accept, connect і режим клієнта, і ці розділи відповідають на питання про сокет швидше, ніж здогадки. Коли ви все ще не можете сказати, який рівень відповів, прочитайте сертифікат, який представляє публічний порт, командою нижче. Сертифікат обгортки у виводі означає, що переадресація дійшла до обгортки, а тиша або помилка протоколу означає, що не дійшла. Ця єдина різниця економить більше часу, ніж будь-яка інша перевірка тут.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer