OpenVPN і HTTPS на порту 443: кому належить слухач?
TCP і UDP 443 — різні сокети. Спільне використання одного TCP-слухача потребує власника, а розділення порту OpenVPN — вузька домовленість, а не трюк із проксі.
Дві служби можуть обидві відповідати на порту 443, ніколи не конкуруючи, бо слухач визначається транспортом, адресою й портом разом, а не самим номером. Поставте вебсервер і OpenVPN на одну машину, і єдине питання, на яке варто відповісти першим, — який сокет кожен процес просить у ядра. Запишіть цей список до редагування конфігурації, і більшість помилок «адреса вже використовується» пояснять себе самі. Усе після списку — це вибір між UDP-слухачем, спільним TCP-сокетом або фронтендом, що маршрутизує за протоколом.
Почніть із сокета, який просить кожен процес
Bind вдається або не вдається за цією трійкою, тому два демони стикаються лише тоді, коли збігаються всі три частини. Саме тому сайт на TCP 443 необмежено співіснує зі слухачем OpenVPN на UDP 443, і тому ж перенесення одного з них на другу локальну адресу того самого хоста теж припиняє суперечку. Читайте живі слухачі, а не файли, які мали їх створити, бо застарілий include або забутий unit-файл переживає правку, яку ви пам'ятаєте.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
Запустіть ss -lntup від root і прочитайте кожен рядок, де згадується 443, включно із записами IPv6. Зазвичай універсальний слухач v6 приймає й трафік v4, і саме так забутий слухач тримає порт зайнятим після того, як ви змінили файл, який вважали відповідальним. Якщо ім'я процесу вас здивує, звузьте вивід за допомогою ss -lntup 'sport = :443', перш ніж щось чіпати.
Перемкніть тунель на UDP, коли мережа це дозволяє
UDP-слухач повністю обходить зіткнення і зазвичай є найкоротшим виправленням, бо жоден сокет не ділиться і жоден додатковий продукт не стає на шлях. Але це не безкоштовно. Деякі клієнтські мережі відкидають UDP 443, не надсилаючи reset, тож тунель перестає встановлюватися замість того, щоб не зуміти bind, і користувач повідомляє, що VPN не працює, без помилки для читання. UDP-слухач також переживає перезапуск веб-шару, що важливо на машині, чий сайт часто перерозгортають. Перевіряйте з мережі, де сидять користувачі, бо оболонка на сервері доводить лише те, що сервер досягає сам себе.
Змінюйте транспорт у конфігурації сервера і в профілі клієнта одночасно. Профіль, який досі просить TCP, крутитиметься в циклах перепідключень проти слухача лише з UDP, і це виглядає як збій мережі, доки ви не порівняєте два файли.
Нехай процес VPN володіє TCP 443, а решту переправляйте
Community OpenVPN у режимі TCP-сервера читає перші байти вхідного з'єднання і переправляє все, що не є його власним протоколом, на HTTPS-бекенд, і для цього слугує директива port-share. Бекенд — звичайний вебсервер з увімкненим TLS, названий у цій директиві хостом і портом, а не URL.
port-share 10.0.0.5 8080
На машині, де сайт має другу приватну адресу, цей рядок надсилає не-VPN трафік на 10.0.0.5:8080, тож віртуальний хост HTTPS має бути прив'язаний там, а брандмауер має дозволяти локальний стрибок. Вебсервер має сам завершувати TLS, бо байти, що надходять, — це початкове рукостискання браузера, і ніщо між ними їх не розшифрувало. Спрямуйте директиву на звичайний HTTP-слухач, і браузер отримає помилку недопустимого методу, яка читається як зламаний сайт, а не як неправильно розміщений бекенд. Директива існує лише в режимі TCP-сервера, а UDP-слухач не має потоку для перевірки.
Оскільки процес VPN приймає кожне з'єднання, вебзастосунок бачить переправлений запит, що надходить з однієї з власних адрес хоста, а не від відвідувача. Усе, що потребує справжньої адреси клієнта, залежить від підтримки протоколу PROXY у бекенді або від фронтенду, який її додає. Перенесення бекенду на іншу локальну адресу не повертає адресу відвідувача; воно лише змінює, яку з адрес хоста сайт записує. Запишіть це обмеження в нотатках про розгортання, перш ніж звіт аналітики підніме питання.
Зворотний проксі — неправильний інструмент; маршрутизатор четвертого рівня — ні
HTTP-зворотний проксі завершує TLS, щоб читати запити, а отже, не може пропустити потік OpenVPN недоторканим. Маршрутизатор четвертого рівня, який переправляє за SNI або за оглядом першого пакета, може стояти перед обома, за умови що він не завершує сесію, від якої залежить VPN. Два пристрої виглядають однаково на схемі й поводяться зовсім по-різному на сокеті.
Комерційний Access Server постачається з власними налаштуваннями розділення порту, і вони не відповідають директиві спільноти один до одного. Визначте продукт і версію, перш ніж адаптувати посібник, написаний для іншого. Скопійоване налаштування, яке мовчки ігнорують, гірше за відсутність налаштування, бо список слухачів після цього все ще виглядає правдоподібно.
Перевіряйте сайт і тунель як два окремі шляхи
Завантажте сайт і підключіть тунель, потім знову прочитайте список слухачів, щоб побачити, який процес тепер володіє 443. Сторінка, що завантажилася, нічого не доводить про VPN, а тунель, що підключився, нічого не доводить про сайт, хоча обидва використовують той самий номер. Три команди нижче перевіряють спільний сокет, веб-шлях і службу VPN саме в цьому порядку.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Порівняйте адресу клієнта в журналі доступу бекенду з адресою в журналі VPN для того самого моменту. Якщо сайт записує кожного відвідувача як сам хост, переправлення працює, а обробка адреси — ні. Якщо обидва журнали мовчать, фронтенд так і не передав з'єднання. У будь-якому разі список слухачів вирішує, хто приймає сокет, і саме це треба підтвердити, перш ніж змінювати ще один файл.
Залиште цю карту слухачів поруч із конфігурацією, щоб наступна людина, яка торкнеться 443, знала, який процес приймає і куди пішов інший протокол. Підтвердьте володіння після зміни, а не покладайтеся на те, що правка мала зробити.