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, така че тунелът спира да се установява, вместо да не успее да се свърже, и потребителят съобщава, че 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 идва със свои настройки за споделяне на порт и те не съответстват едно към едно на директивата на community версията. Идентифицирайте продукта и версията, преди да адаптирате ръководство, написано за другия. Копирана настройка, която се игнорира безшумно, е по-лоша от липса на настройка, защото списъкът на слушателите след това все още изглежда правдоподобен.
Тествайте сайта и тунела като два отделни пътя
Заредете сайта и свържете тунела, после прочетете списъка на слушателите отново, за да видите кой процес притежава 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, кой процес приема и къде е отишъл другият протокол. Потвърдете собствеността след промяната, вместо да вярвате на това, което редакцията е трябвало да направи.