OpenVPN ja HTTPS pordil 443: kellele kuulub kuulaja?
TCP ja UDP 443 on eraldi soklid. Ühe TCP-kuulaja jagamine nõuab omanikku ja OpenVPN-i pordijagamine on kitsas kokkulepe, mitte puhverserveri trikk.
Kaks teenust võivad mõlemad vastata pordil 443 ilma kunagi võistlemata, sest kuulaja määratakse transpordi, aadressi ja pordi järgi koos, mitte üksnes numbri järgi. Pane veebiserver ja OpenVPN ühte masinasse ning ainus küsimus, millele tasub esimesena vastata, on see, millist soklit iga protsess tuumalt küsib. Kirjuta see nimekiri üles enne konfiguratsiooni muutmist ja enamik vigu «aadress on juba kasutusel» selgitavad end ise. Kõik pärast nimekirja on valik UDP-kuulaja, jagatud TCP-sokli või protokolli järgi suunava esiosa vahel.
Alusta soklist, mida iga protsess küsib
Bind õnnestub või ebaõnnestub selle kolmiku järgi, seega põrkuvad kaks deemonit ainult siis, kui kõik kolm osa kattuvad. Sellepärast eksisteerib veebileht TCP 443 peal lõputult koos OpenVPN-i kuulajaga UDP 443 peal, ja sellepärast lõpetab ka ühe neist teisele kohalikule aadressile samas hostis viimine vaidluse. Loe elavaid kuulajaid, mitte faile, mis pidid need looma, sest aegunud include või unustatud unit-fail elab üle muudatuse, mille tegid meeles pidada.
| 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 |
Käivita ss -lntup rootina ja loe iga rida, mis mainib 443, sealhulgas IPv6-kirjed. Metamärgiga v6 kuulaja võtab tavaliselt vastu ka v4-liiklust, ja nii hoiab unustatud kuulaja porti hõivatuna pärast seda, kui muudad faili, mida pidasid vastutavaks. Kui protsessi nimi üllatab, kitsenda väljundit käsuga ss -lntup 'sport = :443' enne millegi puutumist.
Lülita tunnel UDP-le, kui võrk seda lubab
UDP-kuulaja väldib kokkupõrke täielikult ja on tavaliselt lühim parandus, sest ühtki soklit ei jagata ja ükski lisatoode ei liitu teekonnaga. Kuid see pole tasuta. Mõned kliendivõrgud loobuvad UDP 443-st ilma resetit saatmata, nii et tunnel lakkab end püstitamast selle asemel, et bind-i juures ebaõnnestuda, ja kasutaja teatab, et VPN on maas, ilma et tal oleks viga lugeda. UDP-kuulaja elab üle ka veebikihi taaskäivituse, mis loeb masinas, mille saiti tihti uuesti juurutatakse. Testi võrgust, kus kasutajad istuvad, sest serveri shell tõestab ainult seda, et server jõuab iseendani.
Muuda transporti serveri konfiguratsioonis ja kliendiprofiilis korraga. Profiil, mis ikka küsib TCP-d, käib läbi ühenduse taastamise tsüklite ainult UDP-kuulaja vastu ja see näeb välja nagu võrgu tõrge, kuni võrdled kahte faili.
Lase VPN-protsessil omada TCP 443 ja edasta ülejäänu
Community OpenVPN TCP-serveri režiimis loeb sissetuleva ühenduse esimesed baidid ja edastab kõik, mis pole tema oma protokoll, HTTPS-taustale, milleks direktiiv port-share mõeldud on. Taust on tavaline veebiserver, millel on TLS lubatud, ja see on selles direktiivis nimetatud hosti ja pordiga, mitte URL-iga.
port-share 10.0.0.5 8080
Masinas, kus saidil on teine privaatne aadress, saadab see rida mitte-VPN-liikluse aadressile 10.0.0.5:8080, seega peab HTTPS-i virtuaalhost olema sinna seotud ja tulemüür peab kohaliku hüppe lubama. Veebiserver peab TLS-i ise lõpetama, sest saabuvad baidid on brauseri algne handshake ja miski vahepeal ei ole neid dekrüpteerinud. Suuna direktiiv tavalisele HTTP-kuulajale ja brauser saab kehtetu meetodi vea, mida loetakse katkise saidina, mitte valesti paigutatud taustana. Direktiiv on olemas ainult TCP-serveri režiimis ja UDP-kuulajal pole ühtegi voogu, mida uurida.
Kuna VPN-protsess võtab vastu iga ühenduse, näeb veebirakendus edastatud päringu saabuvat ühelt hosti enda aadressilt, mitte külastajalt. Kõik, mis vajab tõelist kliendi aadressi, sõltub PROXY-protokolli toest taustas või esiosast, mis selle lisab. Tausta teisele kohalikule aadressile viimine ei too külastaja aadressi tagasi; see muudab ainult seda, millise hosti aadressi sait salvestab. Kirjuta see piirang juurutamise märkmetesse enne, kui analüüsiaruanne küsimuse tõstatab.
Pöördproksi on vale tööriist; neljanda kihi ruuter mitte
HTTP pöördproksi lõpetab TLS-i, et päringuid lugeda, mis tähendab, et ta ei saa OpenVPN-i voogu puutumatult läbi lasta. Neljanda kihi ruuter, mis edastab SNI või esimese paketi uurimise järgi, võib seista mõlema ees, tingimusel et ei lõpeta sessiooni, millest VPN sõltub. Kaks seadet näevad diagrammil sarnased välja ja käituvad sokli juures täiesti erinevalt.
Kommertsiaalne Access Server toob kaasa oma pordijagamise seaded ja need ei vasta üks-ühele community direktiivile. Enne teise jaoks kirjutatud juhendi kohandamist tuvasta toode ja versioon. Kopeeritud seade, mida vaikselt eiratakse, on hullem kui seade puudumine, sest kuulajate nimekiri näeb pärast seda ikka usutav välja.
Testi veebilehte ja tunnelit kahe eraldi teekonnana
Laadi sait ja ühenda tunnel, seejärel loe kuulajate nimekiri uuesti, et näha, milline protsess nüüd 443 omab. Leht, mis laadib, ei tõesta VPN-i kohta midagi, ja tunnel, mis ühendub, ei tõesta saidi kohta midagi, kuigi mõlemad kasutavad sama numbrit. Kolm allolevat käsku kontrollivad jagatud soklit, veebiteekonda ja VPN-teenust selles järjekorras.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Võrdle kliendi aadressi tausta juurdepääsulogis sellega VPN-logis sama hetke kohta. Kui sait salvestab iga külastaja hosti endana, töötab edastamine ja aadressi käsitlemine ei tööta. Kui mõlemad logid vaikivad, ei andnud esiosa ühendust kunagi üle. Igal juhul otsustab kuulajate nimekiri, kes sokli vastu võtab, ja see on fakt, mida tuleb kinnitada enne veel ühe faili muutmist.
Jäta see kuulajate kaart konfiguratsiooni kõrvale, et järgmine inimene, kes 443 puudutab, teaks, milline protsess vastu võtab ja kuhu teine protokoll läks. Kinnita omand pärast muudatust, selle asemel et usaldada seda, mida muudatus pidi tegema.