OpenVPN kroz HTTP proxy: prvo pročitajte CONNECT odgovor

Usmjerite VPN klijent na korporativni HTTP proxy i prva korisna činjenica je da proxy ne govori VPN protokol. On otvara običnu TCP vezu prema adresi koju ste naveli, a zatim se sklanja, ostavljajući vaš klijent i server da svoju razmjenu obave kroz taj tok. Sve što klijentu treba, od tipa transporta do serverovog slušača, mora odgovarati tom rasporedu. Dva nesklada objašnjavaju većinu kvarova: UDP profil usmjeren na CONNECT proxy i odgovor proxyja koji se pogrešno shvati kao VPN greška.

Što proxy prenosi, a što ne

Proxy je samo transportni korak. On ne postaje vaš pretraživački proxy, ne kešira stranice koje posjećujete kroz tunel i ne vidi unutrašnji promet osim ako neko namjerno nije podesio inspekciju. Tunel koji otvara njemu je po dizajnu neproziran.

To također znači da proxy ne može popraviti server koji nema odgovarajući slušač. Dopuštenje da dosegnete odredište i usluga koja sluša na tom odredištu dvije su odvojene činjenice, a samo prva pripada administratoru proxyja.

Prijenosnik mora biti TCP na oba kraja

Uobičajeni CONNECT proxy prenosi samo tok bajtova , pa klijent mora koristiti tokovni transport. Fragment klijenta za taj slučaj izgleda ovako:

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

Strana servera treba pravi TCP slušač na portu navedenom u retku remote. Promjena proto udp u proto tcp-client u profilu stvara klijent koji očekuje tok; ona ne stvara tok na drugoj strani. Ako isti server odgovara i na UDP-u na tom portu, to je drugi slušač, a ne drugi način rada istog.

Gdje postoji zasebna TCP instanca, njezin tunelski uređaj, skup adresa i usmjeravanje vlastiti su resursi. Kopiranje radne konfiguracije i izmjena transportne riječi ostavlja te resurse usmjerene na izvornu instancu, što daje vezu koja se autentificira i zatim ništa ne usmjerava.

Pročitajte odgovor proxyja prije VPN rezultata

Prva razmjena klijenta je redak zahtjeva koji imenuje host i port odredišta. Odgovor na taj redak govori vam postoji li uopće tok bajtova, a dolazi prije provjere bilo kojeg certifikata ili vjerodajnice:

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

Odgovor klase 200 na CONNECT znači da tok postoji. On ne govori ništa o tome je li certifikat pristupnika pouzdan, podudara li se zajednički ključ ili je korisnički račun valjan. Te provjere događaju se poslije, unutar toka, i ne uspijevaju s vlastitim porukama klijenta, a ne s HTTP retkom stanja. Pročitajte zapisnik klijenta za prvi OpenVPN događaj nakon rukovanja s proxyjem, a ne zadnji redak prije zatvaranja prozora.

Vjerodajnice proxyja i vjerodajnice VPN-a često su različiti identiteti koje drže različiti timovi. 407 nije loša lozinka na VPN računu, a odbijeni certifikat nije problem dopuštenja na proxyju.

Što CONNECT ne otkriva

Izričiti CONNECT tunel nije presretanje. Proxy prosljeđuje bajtove i ne prekida VPN-ovu TLS sesiju, pa provjera serverovog certifikata na klijentu ostaje smislena i treba ostati uključena. Isključivanje provjere da biste prošli proxy rješava drugi problem od vašega.

Postoje zasebni aranžmani u kojima organizacija namjerno prekida i pregledava TLS. Oni traže vlastitu konfiguraciju povjerenja i vlastitu odluku o politici i nisu ono što traži običan redak http-proxy.

Cijena TCP-a unutar TCP-a

Prijenos tunela preko TCP-a drži vanjski tok poredanim i s ponovnim prijenosom, a unutrašnji promet obično je također TCP. Dva mehanizma oporavka ne usklađuju se, pa jedan izgubljeni segment može zaustaviti sve što dijeli taj vanjski tok dok se ne prenese ponovno. To je stvarna razmjena za kompatibilnost, a ne besplatna nadogradnja.

Koristite put kroz proxy kada vam mreža ne ostavlja alternative i preferirajte izravan UDP put gdje politika dopušta. U svakom slučaju nakon promjene provjerite da isti proxy, odredište i profil dolaze do sljedeće faze; preglednik koji učitava stranicu na toj adresi koristi drugi protokol i ne dokazuje ništa o tunelu.