OpenVPN HTTP-proxyn keresztül: először a CONNECT-választ olvassa el

Irányítson egy VPN-klienst egy vállalati HTTP-proxyra, és az első hasznos tény az, hogy a proxy nem a VPN protokollját beszéli. Egy közönséges TCP-kapcsolatot nyit a megadott címre, majd félreáll, így az ügyfél és a kiszolgáló a saját cseréjét ezen a folyamon keresztül bonyolítja. Mindennek, amire az ügyfélnek szüksége van, a szállítási típustól a kiszolgáló figyelőjéig, ehhez az elrendezéshez kell illeszkednie. Két eltérés magyarázza a legtöbb hibát: a CONNECT-proxyra irányuló UDP-profil és a VPN-hibának vélt proxyválasz.

Mit szállít a proxy, és mit nem

A proxy csak egy szállítási lépés. Nem válik a böngészője proxyjává, nem gyorsítótárazza az alagúton keresztül meglátogatott oldalakat, és nem látja a belső forgalmat, hacsak valaki nem állított be szándékosan vizsgálatot. Az általa nyitott alagút számára tervezésénél fogva átláthatatlan.

Ez azt is jelenti, hogy a proxy nem tud megjavítani egy kiszolgálót, amelynek nincs megfelelő figyelője. A cél elérésére vonatkozó engedély és a célon figyelő szolgáltatás két külön tény, és csak az első tartozik a proxy rendszergazdájához.

A hordozónak mindkét végén TCP-nek kell lennie

A hagyományos CONNECT-proxy csak bájtfolyamot továbbít , ezért az ügyfélnek folyam-szállítást kell használnia. Egy ügyféltöredék erre az esetre így néz ki:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

A kiszolgáló oldalának valódi TCP-figyelőre van szüksége a remote sorban megnevezett porton. Ha egy profilban a proto udp helyére proto tcp-client kerül, olyan ügyfél jön létre, amely folyamot vár; a folyamot a másik oldalon nem hozza létre. Ha ugyanaz a kiszolgáló ezen a porton UDP-n is válaszol, az egy másik figyelő, nem ugyanazon második módja.

Ahol külön TCP-példány létezik, annak alagúteszköze, címtartománya és útvonalválasztása saját erőforrások. Egy működő konfiguráció másolása és a szállítási szó módosítása ezeket az erőforrásokat az eredeti példányra mutatva hagyja, ami olyan kapcsolatot eredményez, amely hitelesít, majd semmit nem irányít.

A proxy válaszát a VPN eredménye előtt olvassa el

Az ügyfél első cseréje egy kérésor, amely megnevezi a célgazdagépet és a portot. Az erre a sorra adott válasz megmondja, létezik-e egyáltalán bájtfolyam, és még bármely tanúsítvány vagy hitelesítő adat ellenőrzése előtt megérkezik:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

A CONNECT-re adott 200-as osztályú válasz azt jelenti, hogy a folyam létezik. Nem mond semmit arról, hogy az átjáró tanúsítványa megbízható-e, a megosztott kulcs egyezik-e, vagy a felhasználói fiók érvényes-e. Ezek az ellenőrzések később, a folyamon belül történnek, és az ügyfél saját üzeneteivel hiúsulnak meg, nem HTTP-állapotsorral. Az ügyféllogban az első OpenVPN eseményt keresse a proxy kézfogása után, nem az utolsó sort az ablak bezárása előtt.

A proxy hitelesítő adatai és a VPN hitelesítő adatai gyakran különböző identitások, különböző csapatok kezében. A 407 nem rossz jelszó a VPN-fiókon, és az elutasított tanúsítvány nem proxyengedély-probléma.

Mit nem tár fel a CONNECT

Egy kifejezett CONNECT-alagút nem lehallgatás. A proxy bájtokat továbbít, és nem fejezi be a VPN TLS-munkamenetét, ezért az ügyfél kiszolgálótanúsítvány-ellenőrzése továbbra is értelmes, és bekapcsolva kell maradnia. Az ellenőrzés kikapcsolása a proxy átlépéséhez más problémát old meg, mint amilyen Önnél van.

Vannak külön elrendezések, ahol egy szervezet szándékosan lezárja és vizsgálja a TLS-t. Ezek saját bizalmi konfigurációt és saját szakpolitikai döntést igényelnek, és nem azok, amit egy közönséges http-proxy-sor kér.

A TCP ára a TCP-n belül

Az alagút TCP-n való átvitele a külső folyamot rendezetten és újraküldéssel tartja, a belső forgalom pedig általában szintén TCP. A két helyreállítási mechanizmus nem hangolódik össze, ezért egyetlen elveszett szegmens megállíthat mindent, ami ezt a külső folyamot osztja, amíg újra nem küldik. Ez valódi kompromisszum a kompatibilitásért, nem ingyenes fejlesztés.

Használja a proxy útvonalát, amikor a hálózat nem hagy alternatívát, és részesítse előnyben a közvetlen UDP-útvonalat, ahol a szabályzat engedi. Mindenképpen ellenőrizze egy változtatás után, hogy ugyanaz a proxy, cél és profil eléri-e a következő szakaszt; egy böngésző, amely ezen a címen oldalt tölt be, más protokollt használ, és semmit nem bizonyít az alagútról.