OpenVPN caur HTTP starpniekserveri: vispirms izlasiet CONNECT atbildi
CONNECT starpniekserveris pārsūta baitus, tāpēc abiem galiem vajag TCP. Izlasiet 407, 403 un 503, pirms vainojat sertifikātus, un atstājiet servera pārbaudi ieslēgtu.
Novirziet VPN klientu uz uzņēmuma HTTP starpniekserveri, un pirmais noderīgais fakts ir tas, ka starpniekserveris nerunā VPN protokolā. Tas atver parastu TCP savienojumu uz norādīto adresi un pēc tam pakāpjas malā, ļaujot klientam un serverim veikt savu apmaiņu pa šo straumi. Visam, kas klientam vajadzīgs, no transporta veida līdz servera klausītājam, jāatbilst šim izkārtojumam. Divas neatbilstības izskaidro lielāko daļu kļūmju: UDP profils, kas vērsts uz CONNECT starpniekserveri, un starpniekservera atbilde, kas kļūdaini uzskatīta par VPN kļūdu.
Ko starpniekserveris pārvadā un ko ne
Starpniekserveris ir tikai transporta posms. Tas nekļūst par jūsu pārlūka starpniekserveri, tas nekešo vietnes, kuras apmeklējat pa tuneli, un tas neredz iekšējo satiksmi, ja vien kāds nav apzināti konfigurējis pārbaudi. Tunelis, ko tas atver, pēc dizaina tam ir necaurredzams.
Tas nozīmē arī to, ka starpniekserveris nevar salabot serveri bez atbilstoša klausītāja. Atļauja sasniegt galamērķi un pakalpojums, kas klausās šajā galamērķī, ir divi atsevišķi fakti, un tikai pirmais pieder starpniekservera administratoram.
Pārvadātājam jābūt TCP abos galos
Parasts CONNECT starpniekserveris pārsūta tikai baitu straumi , tāpēc klientam jāizmanto straumes transports. Šī gadījuma klienta fragments izskatās šādi:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Servera pusei vajag īstu TCP klausītāju portā, kas nosaukts remote rindā. Aizstājot proto udp ar proto tcp-client profilā, tiek izveidots klients, kas gaida straumi; tas neizveido straumi otrā pusē. Ja tas pats serveris šajā portā atbild arī ar UDP, tas ir cits klausītājs, nevis tā paša otrais režīms.
Kur pastāv atsevišķa TCP instance, tās tuneļa ierīce, adrešu kopums un maršrutēšana ir pašas par sevi resursi. Nokopējot strādājošu konfigurāciju un mainot transporta vārdu, šie resursi paliek vērsti uz sākotnējo instanci, kas rada savienojumu, kurš autentificējas un pēc tam neko nemaršrutē.
Izlasiet starpniekservera atbildi pirms VPN rezultāta
Klienta pirmā apmaiņa ir pieprasījuma rinda, kas nosauc galamērķa resursdatoru un portu. Atbilde uz šo rindu pasaka, vai baitu straume vispār pastāv, un tā nāk pirms jebkura sertifikāta vai akreditācijas datu pārbaudes:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
Atbilde ar kodu 200 uz CONNECT nozīmē, ka straume pastāv. Tā neko nesaka par to, vai vārtejas sertifikāts ir uzticams, vai koplietotā atslēga sakrīt, vai lietotāja konts ir derīgs. Šīs pārbaudes notiek vēlāk, straumes iekšienē, un tās neizdodas ar paša klienta ziņojumiem, nevis ar HTTP statusa rindu. Klienta žurnālā meklējiet pirmo OpenVPN notikumu pēc rokasspiediena ar starpniekserveri, nevis pēdējo rindu pirms loga aizvēršanas.
Starpniekservera akreditācijas dati un VPN akreditācijas dati bieži ir atšķirīgas identitātes dažādu komandu rokās. 407 nav slikta VPN konta parole, un noraidīts sertifikāts nav starpniekservera atļauju problēma.
Ko CONNECT neatklāj
Skaidrs CONNECT tunelis nav noklausīšanās. Starpniekserveris pārsūta baitus un neizbeidz VPN TLS sesiju, tāpēc klienta veiktā servera sertifikāta pārbaude paliek jēgpilna un tai jāpaliek ieslēgtai. Pārbaudes izslēgšana, lai izietu caur starpniekserveri, risina citu problēmu nekā jūsējā.
Pastāv atsevišķi noteikumi, kuros organizācija apzināti izbeidz un pārbauda TLS. Tiem vajadzīga sava uzticēšanās konfigurācija un savs politikas lēmums, un tie nav tas, ko prasa parasta http-proxy rinda.
TCP izmaksas TCP iekšienē
Tuneļa pārvadāšana pa TCP uztur ārējo straumi sakārtotu un ar atkārtotu pārsūtīšanu, un iekšējā satiksme parasti arī ir TCP. Abi atkopšanas mehānismi nekoordinējas, tāpēc viens pazaudēts segments var apturēt visu, kas dala šo ārējo straumi, līdz tas tiek pārsūtīts vēlreiz. Tā ir īsta maiņa pret saderību, nevis bezmaksas jauninājums.
Izmantojiet starpniekservera ceļu, kad tīkls neļauj alternatīvu, un dodiet priekšroku tiešam UDP ceļam, kur politika atļauj. Jebkurā gadījumā pēc izmaiņām pārliecinieties, ka tas pats starpniekserveris, galamērķis un profils sasniedz nākamo posmu; pārlūks, kas šajā adresē ielādē lapu, izmanto citu protokolu un neko nepierāda par tuneli.