OpenVPN і HTTPS на порце 443: каму належыць слухач?
TCP і UDP 443 — асобныя сокеты. Сумеснае выкарыстанне аднаго TCP-слухача патрабуе ўладальніка, а сумеснае выкарыстанне порта OpenVPN — вузкая дамоўленасць, а не трукавы прыём проксі.
Дзве службы могуць абедзве адказваць на порце 443, ніколі не канкурыруючы, бо слухач вызначаецца сукупнасцю транспарту, адраса і порта, а не адным нумарам. Пастаўце вэб-сервер і OpenVPN на адну машыну — і адзінае пытанне, на якое варта адказаць першым, гэта які сокет кожны працэс просіць у ядра. Запішыце гэты спіс перад тым, як правіць канфігурацыю, і большасць памылак «адрас ужо выкарыстоўваецца» патлумачаць самі сябе. Усё пасля спіса — гэта выбар паміж UDP-слухачом, агульным TCP-сокетам або франтэндам, які маршрутызуе па пратаколе.
Пачніце з сокета, які просіць кожны працэс
Прывязка ўдаецца або не ўдаецца па гэтай тройцы, таму два дэманы сутыкаюцца толькі тады, калі супадаюць усе тры часткі. Менавіта таму сайт на 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, ведаў, які працэс прымае і куды пайшоў іншы пратакол. Пацвердзіце ўладанне пасля змены, а не давярайце таму, што праўка меркавалася зрабіць.