OpenVPN përmes një proxy HTTP: lexoni fillimisht përgjigjen CONNECT

Drejtojeni një klient VPN drejt një proxy HTTP korporativ, dhe fakti i parë i dobishëm është se proxy-i nuk flet protokollin e VPN-së. Ai hap një lidhje TCP të zakonshme drejt adresës që treguat dhe pastaj tërhiqet mënjanë, duke lënë klientin dhe serverin të bëjnë shkëmbimin e tyre përmes atij rrjedhe. Gjithçka që i nevojitet klientit, nga lloji i transportit deri te dëgjuesi i serverit, duhet të përputhet me këtë rregullim. Dy mospërputhje shpjegojnë shumicën e dështimeve: një profil UDP i drejtuar drejt një proxy CONNECT, dhe një përgjigje e proxy-it e marrë gabimisht si gabim i VPN-së.

Çfarë mbart proxy-i dhe çfarë jo

Proxy-i është vetëm një hap transporti. Ai nuk bëhet proxy-i i shfletuesit tuaj, nuk i ruan në cache faqet që vizitoni përmes tunelit, dhe nuk e sheh trafikun e brendshëm nëse dikush nuk ka konfiguruar qëllimisht inspektimin. Tuneli që hap është i errët për të sipas dizajnit.

Kjo do të thotë gjithashtu se proxy-i nuk mund të rregullojë një server pa një dëgjues përputhës. Leja për të arritur një destinacion dhe një shërbim që dëgjon në atë destinacion janë dy fakte të veçanta, dhe vetëm i pari i përket administratorit të proxy-it.

Transportuesi duhet të jetë TCP në të dy skajet

Një proxy CONNECT konvencional përçon vetëm një rrjedhë bajtësh , prandaj klienti duhet të përdorë një transport rrjedhe. Një fragment klienti për atë rast duket kështu:

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

Ana e serverit ka nevojë për një dëgjues të vërtetë TCP në portën e përmendur në rreshtin remote. Ndryshimi i proto udp në proto tcp-client në një profil krijon një klient që pret një rrjedhë; nuk e krijon rrjedhën në anën tjetër. Nëse i njëjti server përgjigjet edhe përmes UDP në atë portë, ky është një dëgjues tjetër, jo një modalitet i dytë i të njëjtit.

Aty ku ekziston një instancë e veçantë TCP, pajisja e tunelit, grupi i adresave dhe rrugëtimi i saj janë burime të vetat. Kopjimi i një konfigurimi që funksionon dhe ndryshimi i fjalës së transportit i lë ato burime duke treguar drejt instancës origjinale, gjë që prodhon një lidhje që autentifikohet dhe pastaj nuk rrugëton asgjë.

Lexoni përgjigjen e proxy-it përpara rezultatit të VPN-së

Shkëmbimi i parë i klientit është një rresht kërkese që emërton hostin dhe portën e destinacionit. Përgjigja për atë rresht ju tregon nëse ekziston fare një rrjedhë bajtësh, dhe vjen përpara se të kontrollohet çdo certifikatë ose kredencial:

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

Një përgjigje e klasës 200 ndaj CONNECT do të thotë që rrjedha ekziston. Ajo nuk thotë asgjë nëse certifikata e portës është e besuar, nëse çelësi i përbashkët përputhet apo nëse llogaria e përdoruesit është e vlefshme. Ato kontrolle ndodhin më pas, brenda rrjedhës, dhe dështojnë me mesazhet e vetë klientit dhe jo me një rresht statusi HTTP. Lexoni regjistrin e klientit për OpenVPN ngjarjen e parë pas shtrëngimit të duarve me proxy-in, jo rreshtin e fundit përpara se të mbyllej dritarja.

Kredencialet e proxy-it dhe ato të VPN-së shpesh janë identitete të ndryshme në duart e ekipeve të ndryshme. Një 407 nuk është fjalëkalim i gabuar i llogarisë VPN, dhe një certifikatë e refuzuar nuk është problem lejeje i proxy-it.

Çfarë nuk zbulon CONNECT

Një tunel CONNECT i qartë nuk është përgjim. Proxy-i përçon bajtë dhe nuk e përfundon sesionin TLS të VPN-së, prandaj verifikimi i certifikatës së serverit nga klienti mbetet kuptimplotë dhe duhet të mbetet aktiv. Fikja e verifikimit për të kaluar një proxy zgjidh një problem tjetër nga ai juaji.

Ekzistojnë rregullime të veçanta ku një organizatë e përfundon dhe e inspekton TLS me qëllim. Ato kërkojnë konfigurimin e tyre të besimit dhe vendimin e tyre të politikës, dhe nuk janë ajo që kërkon një rresht http-proxy i zakonshëm.

Kostoja e TCP brenda TCP

Mbartja e tunelit mbi TCP e mban rrjedhën e jashtme të rregullt dhe me ritransmetim, dhe trafiku i brendshëm është zakonisht gjithashtu TCP. Dy mekanizmat e rikuperimit nuk koordinohen, prandaj një segment i humbur mund të ndalojë gjithçka që ndan atë rrjedhë të jashtme derisa të ritransmetohet. Ky është një shkëmbim i vërtetë për përputhshmëri, jo një përmirësim falas.

Përdorni rrugën përmes proxy-it kur rrjeti nuk ju lë alternativë, dhe preferoni një rrugë të drejtpërdrejtë UDP aty ku politika e lejon. Në çdo rast, pas një ndryshimi konfirmoni se i njëjti proxy, destinacion dhe profil arrijnë fazën tjetër; një shfletues që ngarkon një faqe në atë adresë përdor një protokoll tjetër dhe nuk provon asgjë për tunelin.