OpenVPN in HTTPS na vratih 443: čigav je poslušalec?
TCP in UDP 443 sta ločeni vtičnici. Za deljenje enega poslušalca TCP je potreben lastnik, deljenje vrat OpenVPN pa je ozka ureditev, ne trik s posrednikom.
Dve storitvi lahko obe odgovarjata na vratih 443, ne da bi se kdaj kosali, ker poslušalec določajo transport, naslov in vrata skupaj, ne samo številka. Postavite spletni strežnik in OpenVPN na en stroj in edino vprašanje, ki si zasluži prvi odgovor, je, katero vtičnico vsak proces zahteva od jedra. Zapišite ta seznam, preden uredite konfiguracijo, in večina napak »naslov je že v uporabi« se pojasni sama. Vse po seznamu je izbira med poslušalcem UDP, skupno vtičnico TCP ali sprednjim delom, ki usmerja po protokolu.
Začnite z vtičnico, ki jo zahteva vsak proces
Bind uspe ali spodleti na tej trojici, zato se dva demona zaletita le, ko se ujemajo vsi trije deli. Zato spletno mesto na TCP 443 neomejeno sobiva s poslušalcem OpenVPN na UDP 443 in zato premik enega od njiju na drugi lokalni naslov na istem gostitelju prav tako konča razpravo. Berite žive poslušalce, ne datotek, ki naj bi jih ustvarile, ker zastarel include ali pozabljena datoteka unit preživi urejanje, ki se ga spomnite.
| 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 |
Zaženite ss -lntup kot root in preberite vsako vrstico, ki omenja 443, vključno z vnosi IPv6. Divji poslušalec v6 običajno sprejema tudi promet v4, in tako pozabljen poslušalec drži vrata zasedena, potem ko spremenite datoteko, ki ste jo imeli za odgovorno. Če vas ime procesa preseneti, zožite izhod z ss -lntup 'sport = :443', preden se česa dotaknete.
Preklopite tunel na UDP, ko omrežje to dovoli
Poslušalec UDP se trku popolnoma izogne in je običajno najkrajša popravka, ker se nobena vtičnica ne deli in noben dodatni izdelek ne stopi na pot. Pa ni brezplačno. Nekatera omrežja strank zavržejo UDP 443, ne da bi poslala reset, zato se tunel neha vzpostavljati, namesto da bi spodletel pri bind, uporabnik pa poroča, da VPN ne deluje, brez napake za branje. Poslušalec UDP preživi tudi ponovni zagon spletne plasti, kar šteje na stroju, katerega mesto se pogosto znova uvaja. Preizkusite iz omrežja, kjer sedijo uporabniki, ker lupina na strežniku dokazuje le, da strežnik doseže samega sebe.
Spremenite transport v konfiguraciji strežnika in v profilu odjemalca hkrati. Profil, ki še vedno zahteva TCP, bo krožil v zankah ponovnega povezovanja proti poslušalcu samo z UDP, in to izgleda kot omrežna okvara, dokler ne primerjate obeh datotek.
Pustite procesu VPN, da ima TCP 443, ostalo pa posredujte
Community OpenVPN v načinu strežnika TCP prebere prve bajte dohodne povezave in posreduje vse, kar ni njegov protokol, v zaledje HTTPS, in temu služi direktiva port-share. Zaledje je običajen spletni strežnik z omogočenim TLS, v tej direktivi imenovan z gostiteljem in vrati, ne z URL.
port-share 10.0.0.5 8080
Na stroju, kjer ima mesto drugi zasebni naslov, ta vrstica pošlje promet, ki ni VPN, na 10.0.0.5:8080, zato mora biti navidezni gostitelj HTTPS vezan tam, požarni zid pa mora dovoliti lokalni skok. Spletni strežnik mora TLS zaključiti sam, ker so prihajajoči bajti izvirni rokovanje brskalnika in nič vmes jih ni dešifriralo. Usmerite direktivo na običajen poslušalec HTTP in brskalnik dobi napako neveljavne metode, ki se bere kot pokvarjeno mesto, ne kot napačno postavljeno zaledje. Direktiva obstaja samo v načinu strežnika TCP, poslušalec UDP pa nima toka za pregled.
Ker proces VPN sprejme vsako povezavo, spletna aplikacija vidi posredovano zahtevo, ki prihaja z enega od lastnih naslovov gostitelja, namesto od obiskovalca. Vse, kar potrebuje pravi naslov odjemalca, je odvisno od podpore protokola PROXY v zaledju ali od sprednjega dela, ki ga doda. Premik zaledja na drug lokalni naslov ne vrne naslova obiskovalca; spremeni le, katerega od naslovov gostitelja mesto zabeleži. Zapišite to omejitev v opombe za uvedbo, preden poročilo analitike sproži vprašanje.
Povratni posrednik je napačno orodje; usmerjevalnik četrtega sloja ni
HTTP povratni posrednik zaključi TLS, da lahko bere zahteve, kar pomeni, da ne more spustiti toka OpenVPN skozi nedotaknjenega. Usmerjevalnik četrtega sloja, ki posreduje po SNI ali po pregledu prvega paketa, lahko stoji pred obema, če ne zaključi seje, od katere je odvisen VPN. Napravi sta na diagramu videti podobni, pri vtičnici pa se obnašata povsem drugače.
Komercialni Access Server prinaša svoje nastavitve deljenja vrat in te ne ustrezajo direktivi skupnosti ena na ena. Preden prilagodite vodnik, napisan za drugega, določite izdelek in različico. Kopirana nastavitev, ki se tiho ignorira, je slabša od nobene nastavitve, ker je seznam poslušalcev nato še vedno videti verodostojen.
Preizkusite spletno mesto in tunel kot dve ločeni poti
Naložite mesto in povežite tunel, nato znova preberite seznam poslušalcev, da vidite, kateri proces ima zdaj 443. Naložena stran ne dokaže ničesar o VPN, povezan tunel pa ne dokaže ničesar o mestu, čeprav oba uporabljata isto številko. Trije spodnji ukazi preverijo skupno vtičnico, spletno pot in storitev VPN v tem vrstnem redu.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Primerjajte naslov odjemalca v dnevniku dostopa zaledja z naslovom v dnevniku VPN za isti trenutek. Če mesto zabeleži vsakega obiskovalca kot gostitelja samega, posredovanje deluje, obravnava naslova pa ne. Če oba dnevnika molčita, sprednji del povezave nikoli ni predal. Kakorkoli, seznam poslušalcev odloči, kdo sprejme vtičnico, in to je dejstvo, ki ga je treba potrditi, preden spremenite še eno datoteko.
Pustite ta zemljevid poslušalcev ob konfiguraciji, da bo naslednja oseba, ki se dotakne 443, vedela, kateri proces sprejema in kam je šel drugi protokol. Po spremembi potrdite lastništvo, namesto da zaupate temu, kar naj bi urejanje naredilo.