OpenVPN en HTTPS op poarte 443: wa is eigner fan de lústerder?
TCP en UDP 443 binne aparte sockets. Ien TCP-lústerder diele freget in eigner, en poartdieling fan OpenVPN is in nauwe regeling, gjin proxy-truc.
Twa tsjinsten kinne beide antwurdzje op poarte 443 sûnder ea te konkurrearjen, om’t in lústerder bepaald wurdt troch transport, adres en poarte tegearre, net troch it nûmer allinnich. Set in webserver en OpenVPN op ien masine, en de iennichste fraach dy’t earst in antwurd fertsjinnet is hokker socket elk proses fan ’e kernel freget. Skriuw dy list op foardat jo in konfiguraasje bewurkje, en de measte flaters «adres al yn gebrûk» ferklearje harsels. Alles nei de list is in kar tusken in UDP-lústerder, in dielde TCP-socket of in frontend dy’t op protokol rûtelet.
Begjin by de socket dy’t elk proses freget
In bind slagget of mislearret op dat trijetal, dus twa daemons botsingje allinnich as alle trije dielen gearfalle. Dêrom bestiet in webside op TCP 443 ûnbeheind njonken in OpenVPN-lústerder op UDP 443, en dêrom einiget it ek de diskusje om ien fan harren nei in twadde lokaal adres op deselde host te ferpleatsen. Lês de libbene lústerders ynstee fan ’e bestannen dy’t se meitsje moasten, om’t in ferâldere include of in fergetten unit-bestân de bewurking oerlibbet dy’t jo jo ûnthâlde.
| 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 |
Rin ss -lntup as root en lês elke rigel dy’t 443 neamt, IPv6-ynfieringen ynbegrepen. In wildcard-lústerder foar v6 akseptearret meastentiids ek v4-ferkear, en sa hâldt in lústerder dy’t jo fergetten binne de poarte beset neidat jo it bestân feroare hawwe dat jo ferantwurdlik tochten. As in prosesnamme jo ferrast, behein dan de útfier mei ss -lntup 'sport = :443' foardat jo eat oanreitsje.
Skeakelje de tunnel nei UDP as it netwurk it talit
In UDP-lústerder mijelet de botsing folslein en is meastentiids de koartste reparaasje, om’t gjin socket dield wurdt en gjin ekstra produkt by it paad komt. Mar it is net fergees. Guon klantnetwurken litte UDP 443 falle sûnder in reset te stjoeren, sadat de tunnel ophâldt mei it opbouwen ynstee fan te mislearjen op bind, en de brûker rapportearret de VPN as del sûnder in flater om te lêzen. In UDP-lústerder oerlibbet ek in werstart fan ’e weblaach, wat telt op in masine waans side faak opnij útrôle wurdt. Test fan it netwurk dêr’t de brûkers sitte, om’t in shell op ’e server allinnich bewiist dat de server himsels berikke kin.
Feroarje it transport yn ’e serverkonfiguraasje en yn it klantprofyl tagelyk. In profyl dat noch TCP freget, sil yn werferbining-lussen rinne tsjin in lústerder mei allinnich UDP, en dat liket op in netwurkstoarflaach oant jo de twa bestannen ferlykje.
Lit it VPN-proses TCP 443 besitte en stjoer de rest troch
Community OpenVPN yn TCP-servermodus lêst de earste bytes fan in ynkommende ferbining en stjoert alles dat net syn eigen protokol is troch nei in HTTPS-backend, en dêrfoar is de rjochtline port-share. De backend is in gewoane webserver mei TLS ynskeakele, neamd troch host en poarte yn dy rjochtline ynstee fan troch in URL.
port-share 10.0.0.5 8080
Op in masine dêr’t de side in twadde privee-adres hâldt, stjoert dy rigel net-VPN-ferkear nei 10.0.0.5:8080, dus de HTTPS-firtuele host moat dêr bûn wêze en de firewall moat de lokale hop talitte. De webserver moat TLS sels beëinigje, om’t de oankommende bytes de oarspronklike handshake fan ’e browser binne en neat tuskenyn se ûntsifere hat. Rjochtsje de rjochtline op in gewoane HTTP-lústerder en de browser krijt in ûnjildige-metoade-flater, dy’t lêzen wurdt as in brutsen side ynstee fan in ferkeard pleatste backend. De rjochtline bestiet allinnich yn TCP-servermodus, en in UDP-lústerder hat gjin stream om te ûndersykjen.
Om’t it VPN-proses elke ferbining akseptearret, sjocht de webapplikaasje it trochstjoerde fersyk oankommen fan ien fan ’e host syn eigen adressen ynstee fan fan ’e besiker. Alles dat it echte klantadres nedich hat, hinget ôf fan PROXY-protokolstipe yn ’e backend of fan in frontend dy’t it tafoeget. It ferpleatsen fan ’e backend nei in oar lokaal adres bringt it adres fan ’e besiker net werom; it feroaret allinnich hokker fan ’e hostadressen de side fêstleit. Skriuw dy beheining yn ’e ymplemintaasje-notysjes foardat in analytika-rapport de fraach ophellet.
In omkearde proxy is it ferkearde ark; in laach-fjouwer-rûter net
In HTTP-omkearde-proxy beëiniget TLS om fersiken lêze te kinnen, wat betsjut dat er in OpenVPN-stream net ûnoantaast trochlitte kin. In laach-fjouwer-rûter dy’t trochstjoert op SNI of op ynspeksje fan it earste pakket kin foar beide stean, mits er de sesje dy’t de VPN nedich hat net beëiniget. De twa apparaten lykje op in diagram op inoar en hâlde har by de socket folslein oars.
Kommersjele Access Server leveret syn eigen ynstellingen foar poartdieling, en dy komme net ien-op-ien oerien mei de rjochtline fan ’e mienskip. Identifisearje it produkt en de ferzje foardat jo in hânlieding oanpasse dy’t foar de oare skreaun is. In kopiearre ynstelling dy’t stilwei negearre wurdt, is slimmer as gjin ynstelling, om’t de lústerderlist dernei noch altyd leaudber útsjocht.
Test de webside en de tunnel as twa aparte paden
Laad de side en ferbyn de tunnel, lês dan wer de lústerderlist om te sjen hokker proses no 443 besit. In side dy’t laadt bewiist neat oer de VPN, en in tunnel dy’t ferbynt bewiist neat oer de side, ek al brûke beide itselde nûmer. De trije kommando’s hjirûnder kontrolearje de dielde socket, it webpaad en de VPN-tsjinst yn dy folchoarder.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Ferlykje it klantadres yn it tagongslog fan ’e backend mei dat yn it VPN-log foar itselde momint. As de side elke besiker as de host sels registrearret, wurket it trochstjoeren en it adresbehear net. As beide logs stil binne, hat de frontend de ferbining nea oerdroegen. Hoe dan ek, de lústerderlist beslút wa’t de socket akseptearret, en dat is it feit dat befêstige wurde moat foardat jo noch in bestân feroarje.
Lit dy lústerderkaart by de konfiguraasje lizze, sadat de folgjende persoan dy’t 443 oanreitset wit hokker proses akseptearret en wêr’t it oare protokol hinne gie. Befêstigje it eignerskip nei de feroaring ynstee fan te fertrouwen op wat de bewurking bedoelde te dwaan.