OpenVPN és HTTPS a 443-as porton: kié a figyelő?
A TCP és az UDP 443 külön socket. Egy TCP-figyelő megosztásához tulajdonos kell, az OpenVPN portmegosztása pedig szűk megállapodás, nem proxytrükk.
Két szolgáltatás is válaszolhat a 443-as porton anélkül, hogy valaha versengene, mert a figyelőt a szállítás, a cím és a port együtt határozza meg, nem a szám önmagában. Tegyen egy webszervert és OpenVPN-t egy gépre, és az egyetlen kérdés, amely elsőként választ érdemel, az, hogy melyik socketet kéri az egyes folyamatok a kerneltől. Írja fel ezt a listát, mielőtt konfigurációt szerkeszt, és a legtöbb „a cím már használatban van” hiba magától megmagyarázza magát. A lista utáni minden választás egy UDP-figyelő, egy megosztott TCP-socket vagy egy protokoll szerint irányító frontend között.
Kezdje azzal a sockettel, amelyet az egyes folyamatok kérnek
A bind ezen a hármon sikerül vagy bukik, ezért két daemon csak akkor ütközik, ha mindhárom rész egybeesik. Ezért él együtt egy webhely a TCP 443-on korlátlanul egy OpenVPN-figyelővel az UDP 443-on, és ezért zárja le a vitát az is, ha valamelyiket ugyanazon a hoszton egy második helyi címre mozgatja. Olvassa az élő figyelőket, ne azokat a fájlokat, amelyeknek létre kellett volna hozniuk őket, mert egy elavult include vagy egy elfelejtett unit-fájl túlél mindent, amire emlékszik, hogy megtett.
| 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 |
Futtassa a ss -lntup parancsot rootként, és olvasson el minden sort, amely 443-at említ, az IPv6-bejegyzésekkel együtt. Egy v6-os wildcard figyelő általában a v4-es forgalmat is fogadja, és így tartja foglalva a portot egy elfelejtett figyelő azután, hogy megváltoztatta a felelősnek hitt fájlt. Ha egy folyamatnév meglepi, szűkítse a kimenetet a ss -lntup 'sport = :443' paranccsal, mielőtt bármihez hozzányúl.
Váltsa a tunnelt UDP-re, amikor a hálózat engedi
Az UDP-figyelő teljesen megkerüli az ütközést, és általában a legrövidebb javítás, mert nem osztozik socketen, és nem lép be plusz termék az útvonalba. De ez nem ingyen van. Egyes ügyfélhálózatok reset nélkül dobják el az UDP 443-at, így a tunnel a bind hibája helyett abbahagyja a felépülést, és a felhasználó hibaüzenet nélkül jelenti, hogy a VPN nem működik. Az UDP-figyelő egy webes réteg újraindulását is túléli, ami számít egy olyan gépen, amelynek oldalát gyakran újratelepítik. Teszteljen abból a hálózatból, ahol a felhasználók ülnek, mert a szerveren futó shell csak azt bizonyítja, hogy a szerver eléri önmagát.
Módosítsa a szállítást a szerverkonfigurációban és az ügyfélprofilban egyszerre. Egy profil, amely még TCP-t kér, újracsatlakozási ciklusokban forog egy csak UDP-s figyelővel szemben, és ez hálózati hibának látszik, amíg össze nem hasonlítja a két fájlt.
Hagyja, hogy a VPN-folyamat birtokolja a TCP 443-at, a többit pedig továbbítsa
A Community OpenVPN TCP-szerver módban beolvassa egy bejövő kapcsolat első bájtjait, és mindent, ami nem a saját protokollja, továbbít egy HTTPS-backendnek, erre való a port-share direktíva. A backend egy közönséges webszerver engedélyezett TLS-sel, amelyet ebben a direktívában hoszt és port nevez meg, nem URL.
port-share 10.0.0.5 8080
Egy olyan gépen, ahol az oldalnak második privát címe van, ez a sor a nem VPN-forgalmat a 10.0.0.5:8080 címre küldi, ezért a HTTPS virtuális hosztot ott kell kötni, és a tűzfalnak engedélyeznie kell a helyi ugrást. A webszervernek magának kell lezárnia a TLS-t, mert a beérkező bájtok a böngésző eredeti kézfogása, és semmi sem fejtette vissza őket közben. Irányítsa a direktívát egy egyszerű HTTP-figyelőre, és a böngésző érvénytelen metódus hibát kap, amely törött oldalként olvasható, nem rossz helyre tett backendként. A direktíva csak TCP-szerver módban létezik, és az UDP-figyelőnek nincs vizsgálható folyama.
Mivel a VPN-folyamat minden kapcsolatot elfogad, a webalkalmazás a továbbított kérést a hoszt saját címei közül látja érkezni, nem a látogatótól. Minden, aminek a valódi ügyfélcím kell, a backend PROXY-protokoll támogatásától vagy egy azt hozzáadó frontendtől függ. A backend más helyi címre mozgatása nem hozza vissza a látogató címét; csak azt változtatja meg, hogy a hoszt melyik címét rögzíti az oldal. Írja le ezt a korlátot az üzembe helyezési jegyzetekben, mielőtt egy elemzési jelentés felveti a kérdést.
A fordított proxy rossz eszköz; a negyedik rétegbeli router nem az
Az HTTP fordított proxy lezárja a TLS-t, hogy olvasni tudja a kéréseket, ami azt jelenti, hogy nem tud érintetlenül átengedni egy OpenVPN-folyamot. Egy negyedik rétegbeli router, amely SNI vagy az első csomag vizsgálata szerint továbbít, mindkettő elé állhat, feltéve, hogy nem zárja le azt a munkamenetet, amelytől a VPN függ. A két eszköz a diagramon hasonlónak látszik, a socketnél teljesen másképp viselkedik.
A kereskedelmi Access Server saját portmegosztási beállításokat hoz, és azok nem képeződnek le egy az egyben a közösségi direktívára. Azonosítsa a terméket és a verziót, mielőtt a másikhoz írt útmutatót adaptálja. A csendesen figyelmen kívül hagyott másolt beállítás rosszabb a semmilyen beállításnál, mert a figyelőlista utána is hihetőnek tűnik.
Tesztelje a webhelyet és a tunnelt két külön útvonalként
Töltse be az oldalt és csatlakoztassa a tunnelt, majd olvassa el újra a figyelőlistát, hogy lássa, melyik folyamat birtokolja most a 443-at. Egy betöltődő oldal semmit sem bizonyít a VPN-ről, és egy csatlakozó tunnel semmit sem bizonyít az oldalról, pedig mindkettő ugyanazt a számot használja. Az alábbi három parancs a megosztott socketet, a webes útvonalat és a VPN-szolgáltatást ellenőrzi ebben a sorrendben.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Hasonlítsa össze a backend hozzáférési naplójában lévő ügyfélcímet a VPN-naplóban lévővel ugyanabban a pillanatban. Ha az oldal minden látogatót magaként a hosztként rögzít, a továbbítás működik, a címkezelés nem. Ha mindkét napló hallgat, a frontend soha nem adta át a kapcsolatot. Akárhogy is, a figyelőlista dönti el, ki fogadja el a socketet, és ezt a tényt kell megerősíteni, mielőtt újabb fájlt módosít.
Hagyja ezt a figyelőtérképet a konfiguráció mellett, hogy a következő ember, aki a 443-hoz nyúl, tudja, melyik folyamat fogadja el, és hová ment a másik protokoll. A változtatás után erősítse meg a tulajdonjogot, ahelyett hogy bízna abban, mit kellett volna tennie a szerkesztésnek.