OpenVPN eta HTTPS 443 portuan: nor da entzulearen jabe?
TCP eta UDP 443 socket bereiziak dira. TCP entzule bakarra partekatzeak jabe bat eskatzen du, eta OpenVPNen portu-partekatzea akordio estua da, ez proxy trikimailua.
Bi zerbitzuk 443 portuan erantzun dezakete inoiz lehiatu gabe, entzule bat garraioaren, helbidearen eta portuaren arabera zehazten baita batera, ez zenbakiaren arabera soilik. Jarri web zerbitzari bat eta OpenVPN makina berean, eta lehenengo erantzun beharreko galdera bakarra da zein socket eskatzen dion prozesu bakoitzak nukleoari. Idatzi zerrenda hori konfigurazioa editatu aurretik, eta «helbidea erabileran dago» erroreen gehiengoa berez azaltzen da. Zerrendaren ondorengo guztia UDP entzule baten, TCP socket partekatu baten edo protokoloaren arabera bideratzen duen aurreko baten arteko aukera da.
Hasi prozesu bakoitzak eskatzen duen socketarekin
Bind batek hirukote horren arabera lortzen du arrakasta edo porrot egiten du, beraz bi daemonek hiru zatiak bat datozenean bakarrik talka egiten dute. Horregatik bizi da webgune bat TCP 443-n mugagabe OpenVPN entzule batekin UDP 443-n, eta horregatik amaitzen du eztabaidak haietako bat host bereko bigarren helbide lokal batera mugitzeak ere. Irakurri bizirik dauden entzuleak haiek sortu behar zituzten fitxategien ordez, include zaharkitu batek edo ahaztutako unit fitxategi batek gogoratzen duzun edizioa baino gehiago irauten baitu.
| 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 |
Exekutatu ss -lntup root gisa eta irakurri 443 aipatzen duen lerro bakoitza, IPv6 sarrerak barne. v6 entzule komodin batek normalean v4 trafikoa ere onartzen du, eta horrela ahaztu zenuen entzule batek portua okupatuta mantentzen du erantzule zela uste zenuen fitxategia aldatu ondoren. Prozesu baten izenak harritzen bazaitu, murriztu irteera ss -lntup 'sport = :443' erabiliz ezer ukitu aurretik.
Aldatu tunela UDP-ra sareak ahalbidetzen duenean
UDP entzule batek talka guztiz saihesten du eta normalean konponketa laburrena da, socket bat ere ez baita partekatzen eta produkturik gehigarririk ez baita bidean sartzen. Baina ez da doakoa. Bezero sare batzuek UDP 443 botatzen dute reset bat bidali gabe, beraz tunelak ezartzen jarritzeari uzten dio bind-en huts egitearen ordez, eta erabiltzaileak VPN-a jaitsita dagoela jakinarazten du irakurtzeko errorerik gabe. UDP entzule batek web geruzaren berrabiaraztea ere gainditzen du, eta hori garrantzitsua da maiz berriz zabaltzen den gune bat duen makina batean. Probatu erabiltzaileak dauden sarean, zerbitzariko shell batek zerbitzaria bere buruarengana iristen dela frogatzen baitu soilik.
Aldatu garraioa zerbitzariaren konfigurazioan eta bezeroaren profilean batera. TCP eskatzen jarraitzen duen profil bat berrikonexio begiztan sartuko da UDP soilik duen entzule baten aurka, eta hori sare matxura baten itxura du bi fitxategiak alderatu arte.
Utzi VPN prozesuari TCP 443 edukitzen eta birbidali gainerakoa
Community OpenVPN TCP zerbitzari moduan sarrerako konexio baten lehen byteak irakurtzen ditu eta bere protokoloa ez den guztia HTTPS backend batera birbidaltzen du, eta horretarako dago port-share direktiba. Backend TLS gaituta duen web zerbitzari arrunta da, direktiba horretan host eta portu bidez izendatua, ez URL bidez.
port-share 10.0.0.5 8080
Guneak bigarren helbide pribatu bat duen makina batean, lerro horrek VPN ez den trafikoa 10.0.0.5:8080-ra bidaltzen du, beraz HTTPS host birtuala han lotuta egon behar da eta suebakiak jauzi lokala baimendu behar du. Web zerbitzariak berak amaitu behar du TLS, iristen diren byteak nabigatzailearen jatorrizko handshake-a baitira eta inork ez baitu bitartean deszifratu. Zuzendu direktiba HTTP entzule arrunt batera eta nabigatzaileak metodo baliogabearen errorea jasoko du, gune hautsia bezala irakurtzen dena backend gaizki kokatua bezala baino. Direktiba TCP zerbitzari moduan soilik existitzen da, eta UDP entzuleak ez du aztertzeko fluxurik.
VPN prozesuak konexio bakoitza onartzen duenez, web aplikazioak birbidalitako eskaera hostaren beraren helbide batetik iristen ikusten du bisitariarengandik beharrean. Benetako bezero helbidea behar duen edozein gauza backend-eko PROXY protokoloaren laguntzaren edo hura gehitzen duen aurreko baten mende dago. Backend beste helbide lokal batera mugitzeak ez du bisitariaren helbidea itzultzen; guneak hostaren zein helbide erregistratzen duen soilik aldatzen du. Idatzi muga hori zabalkunde oharretan analitika txosten batek galdera planteatzen duen aurretik.
Proxy alderantzizkoa tresna okerra da; laugarren geruzako bideratzailea ez
HTTP proxy alderantzizko batek TLS amaitzen du eskaerak irakurtzeko, eta horrek esan nahi du ezin duela OpenVPN fluxu bat ukitu gabe pasatzen utzi. SNI edo lehen paketearen ikuskapenaren arabera birbidaltzen duen laugarren geruzako bideratzaile batek bien aurrean egon daiteke, VPN-ak behar duen saioa amaitzen ez badu. Bi gailuek berdin dirudite diagrama batean eta erabat desberdin jokatzen dute socket-ean.
Access Server komertzialak bere portu-partekatze ezarpenak dakartza, eta horiek ez datoz bat-eginda komunitatearen direktibarekin. Identifikatu produktua eta bertsioa bestearentzat idatzitako gida bat egokitu aurretik. Isilpean baztertzen den ezarpen kopiatu bat ezarpenik ez izatea baino okerragoa da, entzuleen zerrendak sinesgarri dirudi oraindik eta.
Probatu webgunea eta tunela bi bide bereizi gisa
Kargatu gunea eta konektatu tunela, gero irakurri berriro entzuleen zerrenda 443 orain zein prozesuren jabe den ikusteko. Kargatzen den orrialde batek ez du ezer frogatzen VPN-ari buruz, eta konektatzen den tunel batek ez du ezer frogatzen guneari buruz, biak zenbaki bera erabiltzen badute ere. Beheko hiru komandoek socket partekatua, web bidea eta VPN zerbitzua egiaztatzen dituzte hurrenkera horretan.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Alderatu bezeroaren helbidea backend-eko sarbide erregistroan VPN erregistrokoarekin une berean. Guneak bisitari bakoitza host bera bezala erregistratzen badu, birbidaltzea funtzionatzen du eta helbidearen tratamenduak ez. Bi erregistroak isilik badaude, aurrekoak ez zuen inoiz konexioa eman. Edonola ere, entzuleen zerrendak erabakitzen du nor den socket-a onartzen duena, eta hori da beste fitxategi bat aldatu aurretik baieztatu beharreko egitatea.
Utzi entzuleen mapa hori konfigurazioaren ondoan, 443 ukitzen duen hurrengo pertsonak jakin dezan zein prozesuk onartzen duen eta beste protokoloa norantz joan den. Baieztatu jabetza aldaketaren ondoren, edizioak egin nahi zuena fidatu beharrean.