OpenVPN ir HTTPS 443 prievade: kam priklauso klausytojas?
TCP ir UDP 443 yra atskiri lizdai. Bendrinti vieną TCP klausytoją reikia savininko, o OpenVPN prievado bendrinimas yra siauras susitarimas, ne tarpinio serverio triukas.
Dvi paslaugos gali abi atsakyti 443 prievade niekada nekonkuruodamos, nes klausytojas nustatomas pagal transportą, adresą ir prievadą kartu, o ne vien pagal numerį. Įdėkite žiniatinklio serverį ir OpenVPN į vieną mašiną, ir vienintelis klausimas, į kurį verta atsakyti pirmiausia, yra tai, kokio lizdo kiekvienas procesas prašo branduolio. Užsirašykite tą sąrašą prieš redaguodami konfigūraciją, ir dauguma klaidų „adresas jau naudojamas“ paaiškės pačios. Viskas po sąrašo yra pasirinkimas tarp UDP klausytojo, bendro TCP lizdo arba priekinės dalies, kuri maršrutizuoja pagal protokolą.
Pradėkite nuo lizdo, kurio prašo kiekvienas procesas
Bind pavyksta arba nepavyksta pagal tą trejetą, todėl du daemonai susiduria tik tada, kai sutampa visos trys dalys. Štai kodėl svetainė TCP 443 egzistuoja neribotai šalia OpenVPN klausytojo UDP 443, ir štai kodėl vieno iš jų perkėlimas į antrą vietinį adresą tame pačiame hoste taip pat baigia ginčą. Skaitykite gyvus klausytojus, o ne failus, kurie turėjo juos sukurti, nes pasenęs include ar pamirštas unit failas išgyvena ilgiau nei jūsų prisimenamas pakeitimas.
| 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 |
Paleiskite ss -lntup kaip root ir perskaitykite kiekvieną eilutę, kurioje minima 443, įskaitant IPv6 įrašus. Paprastai pakaitinis v6 klausytojas priima ir v4 srautą, ir taip pamirštas klausytojas laiko prievadą užimtą po to, kai pakeičiate failą, kurį laikėte atsakingu. Jei proceso pavadinimas nustebina, susiaurinkite išvestį su ss -lntup 'sport = :443' prieš ką nors liesdami.
Perjunkite tunelį į UDP, kai tinklas leidžia
UDP klausytojas visiškai apeina susidūrimą ir paprastai yra trumpiausias taisymas, nes joks lizdas nėra bendrinamas ir joks papildomas produktas neįeina į kelią. Tačiau tai ne nemokama. Kai kurie klientų tinklai atmeta UDP 443 nesiųsdami reset, todėl tunelis nustoja kurtis, o ne nepavyksta bind, ir naudotojas praneša, kad VPN neveikia, be jokios klaidos, kurią būtų galima perskaityti. UDP klausytojas taip pat išgyvena žiniatinklio sluoksnio perkrovimą, o tai svarbu mašinoje, kurios svetainė dažnai perdiegiama. Išbandykite iš tinklo, kuriame sėdi naudotojai, nes serverio apvalkalas tik įrodo, kad serveris pasiekia pats save.
Pakeiskite transportą serverio konfigūracijoje ir kliento profilyje kartu. Profilis, kuris vis dar prašo TCP, suksis pakartotinių prisijungimų cikluose prieš tik UDP klausytoją, ir tai atrodo kaip tinklo gedimas, kol nesulyginsite dviejų failų.
Leiskite VPN procesui valdyti TCP 443, o likusią dalį persiųskite
Community OpenVPN TCP serverio režimu skaito pirmuosius įeinančio ryšio baitus ir persiunčia viską, kas nėra jo paties protokolas, į HTTPS užnugarį, ir tam skirta direktyva port-share. Užnugaris yra įprastas žiniatinklio serveris su įjungtu TLS, toje direktyvoje įvardytas hostu ir prievadu, o ne URL.
port-share 10.0.0.5 8080
Mašinoje, kurioje svetainė turi antrą privatų adresą, ta eilutė siunčia ne VPN srautą į 10.0.0.5:8080, todėl HTTPS virtualusis hostas turi būti ten susietas, o ugniasienė turi leisti vietinį šuolį. Žiniatinklio serveris turi pats užbaigti TLS, nes atvykstantys baitai yra pirminis naršyklės rankos paspaudimas ir niekas tarp jų jų neiššifravo. Nukreipkite direktyvą į paprastą HTTP klausytoją ir naršyklė gaus negaliojančio metodo klaidą, kuri skaitoma kaip sulaužyta svetainė, o ne kaip netinkamai įdėtas užnugaris. Direktyva egzistuoja tik TCP serverio režimu, o UDP klausytojas neturi srauto, kurį būtų galima apžiūrėti.
Kadangi VPN procesas priima kiekvieną ryšį, žiniatinklio programa mato persiųstą užklausą ateinant iš vieno iš paties hosto adresų, o ne iš lankytojo. Viskas, kam reikia tikrojo kliento adreso, priklauso nuo PROXY protokolo palaikymo užnugaryje arba nuo priekinės dalies, kuri jį prideda. Užnugario perkėlimas į kitą vietinį adresą negrąžina lankytojo adreso; tai tik pakeičia, kurį iš hosto adresų svetainė įrašo. Įrašykite šį apribojimą diegimo pastabose, kol analitikos ataskaita neiškėlė klausimo.
Atvirkštinis tarpinis serveris yra netinkamas įrankis; ketvirtojo sluoksnio maršrutizatorius ne
HTTP atvirkštinis tarpinis serveris užbaigia TLS, kad galėtų skaityti užklausas, o tai reiškia, kad jis negali praleisti OpenVPN srauto nepaliesto. Ketvirtojo sluoksnio maršrutizatorius, kuris persiunčia pagal SNI arba pirmo paketo apžiūrą, gali stovėti prieš abu, jei nenutraukia sesijos, nuo kurios priklauso VPN. Du įrenginiai atrodo panašiai schemoje ir elgiasi visiškai skirtingai prie lizdo.
Komercinis Access Server turi savo prievado bendrinimo nustatymus, ir jie neatitinka bendruomenės direktyvos vienas prie vieno. Nustatykite produktą ir versiją prieš pritaikydami vadovą, parašytą kitam. Nukopijuotas nustatymas, kurio tyliai nepaisoma, yra blogiau nei jokio nustatymo, nes klausytojų sąrašas po to vis dar atrodo patikimai.
Išbandykite svetainę ir tunelį kaip du atskirus kelius
Įkelkite svetainę ir prijunkite tunelį, tada dar kartą perskaitykite klausytojų sąrašą, kad pamatytumėte, kuris procesas dabar valdo 443. Įkeliamas puslapis nieko neįrodo apie VPN, o prisijungiantis tunelis nieko neįrodo apie svetainę, nors abu naudoja tą patį numerį. Trys žemiau pateiktos komandos tikrina bendrą lizdą, žiniatinklio kelią ir VPN paslaugą ta tvarka.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Palyginkite kliento adresą užnugario prieigos žurnale su tuo VPN žurnale tuo pačiu momentu. Jei svetainė kiekvieną lankytoją įrašo kaip patį hostą, persiuntimas veikia, o adreso apdorojimas ne. Jei abu žurnalai tyli, priekinė dalis niekada neperdavė ryšio. Bet kuriuo atveju klausytojų sąrašas nusprendžia, kas priima lizdą, ir tai yra faktas, kurį reikia patvirtinti prieš keičiant dar vieną failą.
Palikite tą klausytojų žemėlapį prie konfigūracijos, kad kitas žmogus, kuris palies 443, žinotų, kuris procesas priima ir kur nuėjo kitas protokolas. Patvirtinkite nuosavybę po pakeitimo, o ne pasitikėkite tuo, ką pakeitimas turėjo padaryti.