OpenVPN prek proxyja HTTP: najprej preberite odgovor CONNECT

Usmerite odjemalca VPN na poslovni proxy HTTP, in prvo koristno dejstvo je, da proxy ne govori protokola VPN. Odpre običajno povezavo TCP na naslov, ki ste ga navedli, in se nato umakne, tako da odjemalec in strežnik opravita svojo izmenjavo skozi ta tok. Vse, kar odjemalec potrebuje, od vrste prenosa do poslušalca strežnika, se mora ujemati s to ureditvijo. Dve neujemanji pojasnjujeta večino napak: profil UDP, usmerjen na proxy CONNECT, in odgovor proxyja, ki je pomotoma vzet za napako VPN.

Kaj proxy prenaša in česa ne

Proxy je le korak prenosa. Ne postane proxy vašega brskalnika, ne shranjuje v predpomnilnik spletnih mest, ki jih obiskujete skozi tunel, in ne vidi notranjega prometa, razen če je nekdo namerno nastavil pregledovanje. Tunel, ki ga odpre, je zanj po zasnovi nepregleden.

To pomeni tudi, da proxy ne more popraviti strežnika brez ustreznega poslušalca. Dovoljenje za dosego cilja in storitev, ki posluša na tem cilju, sta dve ločeni dejstvi, in le prvo pripada skrbniku proxyja.

Prenosnik mora biti TCP na obeh koncih

Običajni proxy CONNECT posreduje le tok bajtov , zato mora odjemalec uporabljati tokovni prenos. Del odjemalca za ta primer izgleda takole:

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

Stran strežnika potrebuje pravega poslušalca TCP na vratih, navedenih v vrstici remote. Zamenjava proto udp z proto tcp-client v profilu ustvari odjemalca, ki pričakuje tok; sama po sebi ne ustvari toka na drugi strani. Če isti strežnik odgovarja tudi prek UDP na teh vratih, je to drug poslušalec, ne drugi način istega.

Kjer obstaja ločena instanca TCP, so njena tunelska naprava, nabor naslovov in usmerjanje lastni viri. Kopiranje delujoče konfiguracije in spreminjanje besede prenosa pusti te vire usmerjene na prvotno instanco, kar ustvari povezavo, ki se overi in nato ničesar ne usmerja.

Preberite odgovor proxyja pred rezultatom VPN

Prva izmenjava odjemalca je vrstica zahteve, ki imenuje gostitelja in vrata cilja. Odgovor na to vrstico vam pove, ali sploh obstaja tok bajtov, in prispe, preden se preveri katero koli potrdilo ali poverilnica:

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

Odgovor razreda 200 na CONNECT pomeni, da tok obstaja. Ne pove ničesar o tem, ali je potrdilo prehoda zaupanja vredno, ali se skupni ključ ujema ali ali je uporabniški račun veljaven. Ta preverjanja se zgodijo pozneje, znotraj toka, in spodletijo z lastnimi sporočili odjemalca, ne z vrstico stanja HTTP. V dnevniku odjemalca poiščite prvi OpenVPN dogodek po rokovanju s proxyjem, ne zadnje vrstice pred zaprtjem okna.

Poverilnice proxyja in poverilnice VPN so pogosto različne identitete v rokah različnih ekip. 407 ni slabo geslo računa VPN, zavrnjeno potrdilo pa ni težava dovoljenj proxyja.

Česa CONNECT ne razkrije

Izrecen tunel CONNECT ni prestrezanje. Proxy posreduje bajte in ne zaključi seje TLS VPN, zato preverjanje potrdila strežnika s strani odjemalca ostaja smiselno in bi moralo ostati vključeno. Izklop preverjanja, da bi prišli mimo proxyja, rešuje drugačno težavo od vaše.

Obstajajo ločene ureditve, kjer organizacija namerno zaključi in pregleda TLS. Te zahtevajo svojo konfiguracijo zaupanja in svojo politično odločitev ter niso tisto, kar zahteva običajna vrstica http-proxy.

Cena TCP znotraj TCP

Prenos tunela po TCP ohranja zunanji tok urejen in s ponovnim pošiljanjem, notranji promet pa je običajno tudi TCP. Oba mehanizma za obnovitev se ne usklajujeta, zato lahko en sam izgubljen segment ustavi vse, kar si deli ta zunanji tok, dokler ni znova poslan. To je resnična menjava za združljivost, ne brezplačna nadgradnja.

Uporabite pot prek proxyja, ko vam omrežje ne pušča alternative, in dajte prednost neposredni poti UDP tam, kjer politika to dovoljuje. V vsakem primeru po spremembi potrdite, da isti proxy, cilj in profil dosežejo naslednjo stopnjo; brskalnik, ki na tem naslovu naloži stran, uporablja drug protokol in o tunelu ne dokaže ničesar.