OpenVPN en HTTPS op poort 443: wie besit die luisteraar?
TCP en UDP 443 is aparte sokkels. Om een TCP-luisteraar te deel verg 'n eienaar, en OpenVPN se poortdeling is 'n nou reëling, nie 'n proxy-truuk nie.
Twee dienste kan albei op poort 443 antwoord sonder om ooit te kompeteer, want 'n luisteraar word op transport, adres en poort saam gesleutel, nie net op die nommer nie. Sit 'n webbediener en OpenVPN op een boks, en die enigste vraag wat eerste werd is om te antwoord, is watter sokkel elke proses by die kernel aanvra. Skryf daardie lys neer voordat jy 'n konfigurasie wysig, en die meeste adres-in-gebruik-foute verduidelik hulself. Alles ná die lys is 'n keuse tussen 'n UDP-luisteraar, 'n gedeelde TCP-sokkel of 'n voorpunt wat volgens protokol roeteer.
Begin met die sokkel wat elke proses aanvra
'n Bind slaag of misluk op daardie drietal, so twee daemons bots net wanneer al drie dele saamval. Dit is waarom 'n webwerf op TCP 443 onbepaald saam met 'n OpenVPN-luisteraar op UDP 443 bestaan, en waarom om een van hulle na 'n tweede plaaslike adres op dieselfde gasheer te skuif ook die argument beëindig. Lees die lewendige luisteraars eerder as die lêers wat hulle veronderstel was om te skep, want 'n verouderde insluiting of 'n vergete eenheidslêer oorleef die wysiging wat jy onthou jy gemaak het.
| 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 |
Voer ss -lntup as root uit en lees elke ry wat 443 noem, IPv6-inskrywings ingesluit. 'n Wildcard-luisteraar vir v6 aanvaar gewoonlik ook v4-verkeer, en dit is hoe 'n luisteraar wat jy vergeet het die poort beset hou nadat jy die lêer verander het wat jy geglo het verantwoordelik is. As 'n prosesnaam jou verras, vernou die uitvoer met ss -lntup 'sport = :443' voordat jy enigiets aanraak.
Skakel die tonnel na UDP wanneer die netwerk dit toelaat
'n UDP-luisteraar omseil die botsing heeltemal en is gewoonlik die kortste herstel, want geen sokkel word gedeel nie en geen ekstra produk sluit by die pad aan nie. Dit is nie gratis nie. Sommige kliëntnetwerke laat UDP 443 val sonder om 'n reset te stuur, so die tonnel hou op om te vestig in plaas daarvan om te misluk om te bind, en die gebruiker rapporteer die VPN as af met geen fout om te lees nie. 'n UDP-luisteraar oorleef ook 'n herbegin van die web-laag, wat tel op 'n boks waar die werf dikwels herontplooi word. Toets vanaf die netwerk waar die gebruikers sit, want 'n dop op die bediener bewys net dat die bediener homself kan bereik.
Verander die transport in die bedienerkonfigurasie en in die kliëntprofiel saam. 'n Profiel wat nog TCP vra, sal deur herverbindings loop teen 'n slegs-UDP-luisteraar, en dit lyk soos 'n netwerkfout totdat jy die twee lêers vergelyk.
Laat die VPN-proses TCP 443 besit en stuur die res aan
Gemeenskaps-OpenVPN in TCP-bedienermodus lees die eerste grepe van 'n inkomende verbinding en stuur enigiets wat nie sy eie protokol is nie na 'n HTTPS-agterkant, en dit is waarvoor die port-share-riglyn is. Die agterkant is 'n gewone webbediener met TLS geaktiveer, genoem deur gasheer en poort in daardie riglyn eerder as deur 'n URL.
port-share 10.0.0.5 8080
In 'n boks waar die werf 'n tweede private adres hou, stuur daardie reël nie-VPN-verkeer na 10.0.0.5:8080, so die HTTPS virtuele gasheer moet daar gebind wees en die firewall moet die plaaslike sprong toelaat. Die webbediener moet TLS self termineer, want die grepe wat aankom is die blaaier se oorspronklike handshake en niks tussenin het hulle ontsyfer nie. Rig die riglyn op 'n gewone HTTP-luisteraar en die blaaier kry 'n ongeldige-metode-fout, wat soos 'n gebreekte werf lees eerder as 'n verkeerd geplaasde agterkant. Die riglyn bestaan net in TCP-bedienermodus, en 'n UDP-luisteraar het geen stroom om te ondersoek nie.
Omdat die VPN-proses elke verbinding aanvaar, sien die webtoepassing die doorgestuurde versoek wat van een van die gasheer se eie adresse aankom in plaas van van die besoeker. Enigiets wat die werklike kliëntadres nodig het, hang af van PROXY-protokolondersteuning in die agterkant of van 'n voorpunt wat dit byvoeg. Om die agterkant na 'n ander plaaslike adres te skuif, bring nie die besoeker se adres terug nie; dit verander net watter van die gasheer se adresse die werf aanteken. Sit daardie beperking in die ontplooiingsnotas voordat 'n analiseverslag die vraag opper.
'n Omgekeerde proxy is die verkeerde gereedskap; 'n laag-vier-roeteerder is nie
'n HTTP-omgekeerde-proxy termineer TLS sodat dit versoeke kan lees, wat beteken dit kan nie 'n OpenVPN-stroom onaangeraak deurlaat nie. 'n Laag-vier-roeteerder wat volgens SNI of eerste-pakket-inspeksie stuur, kan albei voor sit, mits dit nie die sessie beëindig waarvan die VPN afhanklik is nie. Die twee toestelle lyk eenders in 'n diagram en gedra hulle heeltemal anders by die sokkel.
Kommersiële Access Server lewer sy eie poortdelingsinstellings, en dié pas nie een-tot-een op die gemeenskapsriglyn nie. Identifiseer die produk en weergawe voordat jy 'n gids aanpas wat vir die ander een geskryf is. 'n Gekopieerde instelling wat stilweg geïgnoreer word, is slegter as geen instelling nie, want die luisteraarlys lyk daarna nog steeds geloofwaardig.
Toets die webwerf en die tonnel as twee afsonderlike paaie
Laai die werf en verbind die tonnel, lees dan weer die luisteraarlys om te sien watter proses 443 nou besit. 'n Bladsy wat laai bewys niks oor die VPN nie, en 'n tonnel wat verbind bewys niks oor die werf nie, al gebruik albei dieselfde nommer. Die drie opdragte hieronder kontroleer die gedeelde sokkel, die webpad en die VPN-diens in daardie volgorde.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Vergelyk die kliëntadres in die agterkant se toegangslog met dié in die VPN-log vir dieselfde oomblik. As die werf elke besoeker as die gasheer self aanteken, werk die deurstuur en werk die adreshantering nie. As albei logs stil bly, het die voorpunt nooit die verbinding oorgehandig nie. Hoe dit ook al sy, die luisteraarlys beslis wie die sokkel aanvaar, en dit is die feit om te bevestig voordat jy nog 'n lêer verander.
Los daardie luisteraarkaart langs die konfigurasie sodat die volgende persoon wat 443 aanraak weet watter proses aanvaar en waarheen die ander protokol gegaan het. Bevestig eienaarskap ná die verandering eerder as om te vertrou wat die wysiging bedoel het om te doen.