OpenVPN printr-un proxy HTTP: citiți mai întâi răspunsul CONNECT

Îndreptați un client VPN către un proxy HTTP corporativ, iar primul fapt util este că proxy-ul nu vorbește protocolul VPN. Deschide o conexiune TCP obișnuită către adresa indicată și apoi se dă la o parte, lăsând clientul și serverul să facă schimbul lor prin acel flux. Tot ce are nevoie clientul, de la tipul de transport până la ascultătorul serverului, trebuie să corespundă acestei aranjamente. Două nepotriviri explică majoritatea eșecurilor: un profil UDP îndreptat către un proxy CONNECT și un răspuns al proxy-ului luat drept eroare VPN.

Ce transportă proxy-ul și ce nu

Proxy-ul este doar o etapă de transport. Nu devine proxy-ul browserului, nu memorează în cache site-urile pe care le vizitați prin tunel și nu vede traficul intern decât dacă cineva a configurat inspectarea intenționat. Tunelul pe care îl deschide este opac pentru el prin proiectare.

Asta înseamnă și că proxy-ul nu poate repara un server fără un ascultător potrivit. Permisiunea de a ajunge la o destinație și un serviciu care ascultă la acea destinație sunt două fapte separate, iar doar primul aparține administratorului proxy-ului.

Transportatorul trebuie să fie TCP la ambele capete

Un proxy CONNECT obișnuit retransmite doar un flux de octeți , așa că clientul trebuie să folosească un transport de flux. Un fragment de client pentru acel caz arată astfel:

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

Partea serverului are nevoie de un ascultător TCP real pe portul menționat în linia remote. Schimbarea proto udp în proto tcp-client într-un profil creează un client care așteaptă un flux; nu creează fluxul de cealaltă parte. Dacă același server răspunde și prin UDP pe acel port, este un alt ascultător, nu un al doilea mod al aceluiași.

Unde există o instanță TCP separată, dispozitivul ei de tunel, pool-ul de adrese și rutarea sunt resurse proprii. Copierea unei configurații funcționale și modificarea cuvântului de transport lasă acele resurse îndreptate spre instanța originală, ceea ce produce o conexiune care se autentifică și apoi nu rutează nimic.

Citiți răspunsul proxy-ului înainte de rezultatul VPN

Primul schimb al clientului este o linie de cerere care numește gazda și portul destinației. Răspunsul la acea linie vă spune dacă există vreun flux de octeți, și sosește înainte de a fi verificat orice certificat sau acreditare:

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

Un răspuns din clasa 200 la CONNECT înseamnă că fluxul există. Nu spune nimic despre dacă certificatul gateway-ului este de încredere, dacă cheia partajată se potrivește sau dacă contul de utilizator este valid. Acele verificări au loc după aceea, în interiorul fluxului, și eșuează cu mesajele clientului însuși, nu cu o linie de stare HTTP. Citiți jurnalul clientului pentru primul OpenVPN eveniment după strângerea de mână cu proxy-ul, nu pentru ultima linie înainte de închiderea ferestrei.

Acreditările proxy-ului și cele ale VPN-ului sunt adesea identități diferite în mâinile unor echipe diferite. Un 407 nu este o parolă greșită a contului VPN, iar un certificat respins nu este o problemă de permisiuni ale proxy-ului.

Ce nu expune CONNECT

Un tunel CONNECT explicit nu este interceptare. Proxy-ul transmite octeți și nu termină sesiunea TLS a VPN-ului, așa că verificarea certificatului serverului de către client rămâne semnificativă și ar trebui să rămână activă. Dezactivarea verificării pentru a trece de un proxy rezolvă o altă problemă decât a dumneavoastră.

Există aranjamente separate în care o organizație termină și inspectează TLS în mod deliberat. Acestea necesită propria configurare de încredere și propria decizie de politică, și nu sunt ceea ce cere o linie http-proxy obișnuită.

Costul TCP în interiorul TCP

Transportarea tunelului peste TCP menține fluxul exterior ordonat și retransmis, iar traficul interior este de obicei tot TCP. Cele două mecanisme de recuperare nu se coordonează, așa că un singur segment pierdut poate bloca tot ce împarte acel flux exterior până când este retransmis. Este un schimb real pentru compatibilitate, nu o actualizare gratuită.

Folosiți calea prin proxy când rețeaua nu vă lasă alternativă și preferați o cale UDP directă acolo unde politica permite. În orice caz, după o modificare confirmați că același proxy, destinație și profil ajung la etapa următoare; un browser care încarcă o pagină la acea adresă folosește alt protocol și nu demonstrează nimic despre tunel.