OpenVPN dhe HTTPS në portën 443: i kujt është dëgjuesi?
TCP dhe UDP 443 janë soketa të veçanta. Ndarja e një dëgjuesi TCP kërkon një pronar, dhe ndarja e portës së OpenVPN është një marrëveshje e ngushtë, jo një truk me proxy.
Dy shërbime mund të përgjigjen të dyja në portën 443 pa u konkurruar kurrë, sepse një dëgjues përcaktohet nga transporti, adresa dhe porta së bashku, jo vetëm nga numri. Vendosni një server web dhe OpenVPN në një makinë, dhe pyetja e vetme që meriton përgjigje së pari është cili soket kërkon secili proces nga bërthama. Shkruajeni atë listë përpara se të redaktoni një konfigurim, dhe shumica e gabimeve «adresa është tashmë në përdorim» shpjegohen vetë. Gjithçka pas listës është një zgjedhje midis një dëgjuesi UDP, një soketi TCP të ndarë ose një ballë që rrugëton sipas protokollit.
Filloni me soketin që kërkon secili proces
Një bind ka sukses ose dështon sipas atij treshe, kështu që dy demonë përplasen vetëm kur përkojnë të tre pjesët. Prandaj një faqe web në TCP 443 bashkëjeton pa kufi me një dëgjues OpenVPN në UDP 443, dhe prandaj zhvendosja e njërit prej tyre në një adresë të dytë lokale në të njëjtin host i jep fund edhe debatit. Lexoni dëgjuesit e gjallë, jo skedarët që duhej t'i krijonin, sepse një include i vjetëruar ose një skedar unit i harruar mbijeton redaktimin që ju kujtohet të keni bërë.
| 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 |
Ekzekutoni ss -lntup si root dhe lexoni çdo rresht që përmend 443, përfshirë zërat IPv6. Një dëgjues v6 me gjithçka zakonisht pranon edhe trafikun v4, dhe kështu një dëgjues që e keni harruar e mban portën të zënë pasi ndryshoni skedarin që mendonit se ishte përgjegjës. Nëse një emër procesi ju befason, ngushtoni daljen me ss -lntup 'sport = :443' përpara se të prekni gjithçka.
Kalojeni tunelin në UDP kur rrjeta e lejon
Një dëgjues UDP e shmang përplasjen plotësisht dhe zakonisht është rregullimi më i shkurtër, pasi nuk ndahet asnjë soket dhe asnjë produkt shtesë nuk hyn në rrugë. Por nuk është falas. Disa rrjeta klientësh e hedhin UDP 443 pa dërguar reset, kështu që tuneli ndalon së vendosuri në vend që të dështojë në bind, dhe përdoruesi raporton se VPN-ja është jashtë funksionit pa asnjë gabim për të lexuar. Një dëgjues UDP mbijeton edhe një rindezje të shtresës web, gjë që ka rëndësi në një makinë, faqja e së cilës vendoset shpesh përsëri. Testojeni nga rrjeta ku ndodhen përdoruesit, sepse një shell në server vërteton vetëm se serveri arrin vetveten.
Ndryshoni transportin në konfigurimin e serverit dhe në profilin e klientit njëkohësisht. Një profil që kërkon ende TCP do të rrotullohet në cikle rilidhjeje kundër një dëgjuesi vetëm UDP, dhe kjo duket si defekt rrjeti derisa të krahasoni dy skedarët.
Lëreni procesin VPN të zotërojë TCP 443 dhe përcillni pjesën tjetër
Community OpenVPN në modalitetin server TCP lexon bajtët e parë të një lidhjeje hyrëse dhe përcjell gjithçka që nuk është protokolli i vet te një backend HTTPS, dhe për këtë shërben direktiva port-share. Backend-i është një server web i zakonshëm me TLS të aktivizuar, i emërtuar sipas hostit dhe portës në atë direktivë, jo sipas një URL.
port-share 10.0.0.5 8080
Në një makinë ku faqja mban një adresë të dytë private, ai rresht e dërgon trafikun që nuk është VPN te 10.0.0.5:8080, prandaj hosti virtual HTTPS duhet të jetë i lidhur atje dhe muri i zjarrit duhet të lejojë kërcimin lokal. Serveri web duhet ta përfundojë vetë TLS-in, sepse bajtët që mbërrijnë janë shtrëngimi origjinal i dorës së shfletuesit dhe asgjë në mes nuk i ka dekriptuar. Drejtojeni direktivën te një dëgjues i thjeshtë HTTP dhe shfletuesi merr një gabim metode të pavlefshme, i cili lexohet si faqe e thyer dhe jo si backend i vendosur gabimisht. Direktiva ekziston vetëm në modalitetin server TCP, dhe një dëgjues UDP nuk ka asnjë rrjedhë për të inspektuar.
Meqenëse procesi VPN pranon çdo lidhje, aplikacioni web e sheh kërkesën e përcjellë duke ardhur nga një nga adresat e vetë hostit në vend të vizitorit. Gjithçka që ka nevojë për adresën e vërtetë të klientit varet nga mbështetja e protokollit PROXY në backend ose nga një ballë që e shton atë. Zhvendosja e backend-it në një adresë tjetër lokale nuk e kthen adresën e vizitorit; ndryshon vetëm cilën nga adresat e hostit regjistron faqja. Shënoni atë kufizim në shënimet e vendosjes përpara se një raport analitik ta ngrejë pyetjen.
Një proxy i kundërt është mjeti i gabuar; një rrugëtues i shtresës së katërt jo
Një proxy i kundërt HTTP e përfundon TLS-in që të mund të lexojë kërkesat, që do të thotë se nuk mund të lërë një rrjedhë OpenVPN të kalojë e paprekur. Një rrugëtues i shtresës së katërt që përcjell sipas SNI ose sipas inspektimit të paketës së parë mund të qëndrojë përpara të dyjave, me kusht që të mos e përfundojë sesionin nga i cili varet VPN-ja. Dy pajisjet duken njësoj në një diagram dhe sillen krejt ndryshe në soket.
Access Server komercial vjen me cilësimet e veta të ndarjes së portës, dhe ato nuk korrespondojnë një me një me direktivën e komunitetit. Identifikoni produktin dhe versionin përpara se të përshtatni një udhëzues të shkruar për tjetrin. Një cilësim i kopjuar që injorohet në heshtje është më keq se asnjë cilësim, sepse lista e dëgjuesve pas kësaj ende duket e besueshme.
Testoni faqen web dhe tunelin si dy rrugë të ndara
Ngarkoni faqen dhe lidhni tunelin, pastaj lexoni përsëri listën e dëgjuesve për të parë cili proces zotëron 443 tani. Një faqe që ngarkohet nuk vërteton asgjë për VPN-në, dhe një tunel që lidhet nuk vërteton asgjë për faqen, edhe pse të dy përdorin të njëjtin numër. Tre komandat më poshtë kontrollojnë soketin e ndarë, rrugën web dhe shërbimin VPN në atë rend.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Krahasoni adresën e klientit në regjistrin e hyrjes së backend-it me atë në regjistrin e VPN-së për të njëjtin moment. Nëse faqja regjistron çdo vizitor si vetë hostin, përcjellja funksionon dhe trajtimi i adresës jo. Nëse të dy regjistrat heshtin, balla nuk e ka dorëzuar kurrë lidhjen. Sidoqoftë, lista e dëgjuesve vendos kush e pranon soketin, dhe ky është fakti që duhet konfirmuar përpara se të ndryshoni një skedar tjetër.
Lëreni atë hartë të dëgjuesve pranë konfigurimit, që personi tjetër që prek 443 të dijë cili proces pranon dhe ku shkoi protokolli tjetër. Konfirmoni pronësinë pas ndryshimit në vend që të mbështeteni në atë që redaktimi duhej të bënte.