OpenVPN přes HTTP proxy: nejdřív si přečtěte odpověď CONNECT

Nasměrujte VPN klienta na podnikovou HTTP proxy a první užitečný fakt je, že proxy nemluví protokolem VPN. Otevře obyčejné TCP spojení na adresu, kterou jste uvedli, a pak ustoupí stranou, takže váš klient a server vedou vlastní výměnu přes tento proud. Vše, co klient potřebuje, od typu transportu po serverový posluchač, musí tomuto uspořádání odpovídat. Většinu selhání vysvětlují dvě neshody: profil UDP mířící na proxy CONNECT a odpověď proxy považovaná za chybu VPN.

Co proxy přenáší a co ne

Proxy je jen transportní meziskok. Nestává se proxy vašeho prohlížeče, neukládá stránky, které navštěvujete tunelem, a nevidí vnitřní provoz, pokud někdo záměrně nenastavil inspekci. Tunel, který otevírá, je pro něj z podstaty neprůhledný.

To také znamená, že proxy nemůže opravit server, který nemá odpovídající posluchač. Povolení dosáhnout cíle a služba naslouchající na tomto cíli jsou dva oddělené fakty a jen první patří správci proxy.

Přenos musí být TCP na obou koncích

Běžná proxy CONNECT přenáší jen proud bajtů , takže klient musí používat proudový transport. Fragment klienta pro tento případ vypadá takto:

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

Strana serveru potřebuje skutečný TCP posluchač na portu uvedeném na řádku remote. Změna proto udp na proto tcp-client v profilu vytvoří klienta, který očekává proud; nevytvoří proud na druhé straně. Pokud stejný server odpovídá i na UDP na tomto portu, je to jiný posluchač, ne druhý režim téhož.

Kde existuje samostatná instance TCP, její tunelové zařízení, fond adres a směrování jsou vlastní prostředky. Zkopírování funkční konfigurace a úprava slova transportu nechá tyto prostředky ukazovat na původní instanci, což vytvoří spojení, které se ověří a potom nic nesměruje.

Přečtěte si odpověď proxy dřív než výsledek VPN

První výměna klienta je řádek požadavku s názvem cílového hostitele a portu. Odpověď na tento řádek vám řekne, zda vůbec nějaký proud bajtů existuje, a přichází dřív, než se zkontroluje jakýkoli certifikát nebo přihlašovací údaj:

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

Odpověď třídy 200 na CONNECT znamená, že proud existuje. Neříká nic o tom, zda je certifikát brány důvěryhodný, zda sedí sdílený klíč nebo zda je uživatelský účet platný. Tyto kontroly proběhnou potom, uvnitř proudu, a selhávají vlastními zprávami klienta, ne řádkem stavu HTTP. V logu klienta hledejte první OpenVPN událost po handshaku s proxy, ne poslední řádek před zavřením okna.

Přihlašovací údaje k proxy a k VPN jsou často různé identity v rukou různých týmů. 407 není špatné heslo k účtu VPN a odmítnutý certifikát není problém oprávnění proxy.

Co CONNECT neodhaluje

Explicitní tunel CONNECT není odposlech. Proxy předává bajty a neukončuje relaci TLS VPN, takže ověřování serverového certifikátu klientem zůstává smysluplné a mělo by zůstat zapnuté. Vypnutí ověřování, abyste prošli proxy, řeší jiný problém, než máte.

Existují samostatná uspořádání, kdy organizace TLS záměrně ukončuje a kontroluje. Ta vyžadují vlastní konfiguraci důvěry a vlastní rozhodnutí o politice a nejsou tím, co žádá obyčejný řádek http-proxy.

Cena TCP uvnitř TCP

Přenos tunelu přes TCP drží vnější proud uspořádaný a se znovuzasíláním a vnitřní provoz je obvykle také TCP. Oba mechanismy obnovy se nekoordinují, takže jeden ztracený segment může zablokovat vše, co sdílí tento vnější proud, dokud není znovu odeslán. To je skutečná výměna za kompatibilitu, ne bezplatné vylepšení.

Použijte cestu přes proxy, když vám síť nenechává alternativu, a preferujte přímou cestu UDP tam, kde to politika dovoluje. V každém případě po změně ověřte, že stejná proxy, cíl a profil dosáhnou další fáze; prohlížeč, který na této adrese načítá stránku, používá jiný protokol a o tunelu nic nedokazuje.