OpenVPN per HTTP tarpinį serverį: pirmiausia perskaitykite CONNECT atsakymą
CONNECT tarpinis serveris persiunčia baitus, todėl abiem galams reikia TCP. Perskaitykite 407, 403 ir 503 prieš kaltindami sertifikatus, ir palikite serverio tikrinimą įjungtą.
Nukreipkite VPN klientą į įmonės HTTP tarpinį serverį, ir pirmasis naudingas faktas yra tai, kad tarpinis serveris nekalba VPN protokolu. Jis atidaro įprastą TCP ryšį nurodytu adresu ir tada pasitraukia, palikdamas klientą ir serverį atlikti savo mainus per tą srautą. Viskas, ko klientui reikia, nuo transporto tipo iki serverio klausytojo, turi atitikti šią tvarką. Du neatitikimai paaiškina daugumą gedimų: UDP profilis, nukreiptas į CONNECT tarpinį serverį, ir tarpinio serverio atsakymas, palaikytas VPN klaida.
Ką tarpinis serveris perduoda, o ko ne
Tarpinis serveris yra tik transporto pakopa. Jis netampa jūsų naršyklės tarpiniu serveriu, netalpineja svetainių, kurias lankote per tunelį, ir nemato vidinio srauto, nebent kas nors sąmoningai sukonfigūravo patikrinimą. Tunelis, kurį jis atidaro, pagal projektą jam yra nepermatomas.
Tai taip pat reiškia, kad tarpinis serveris negali sutaisyti serverio, neturinčio atitinkamo klausytojo. Leidimas pasiekti paskirties vietą ir paslauga, kuri klausosi toje vietoje, yra du atskiri faktai, ir tik pirmasis priklauso tarpinio serverio administratoriui.
Perdavėjas turi būti TCP abiejuose galuose
Įprastas CONNECT tarpinis serveris persiunčia tik baitų srautą , todėl klientas turi naudoti srauto transportą. To atvejo kliento fragmentas atrodo taip:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Serverio pusei reikia tikro TCP klausytojo prievade, nurodytame remote eilutėje. Pakeitus proto udp į proto tcp-client profilyje, sukuriamas klientas, kuris tikisi srauto; tai nesukuria srauto kitoje pusėje. Jei tas pats serveris tame prievade atsako ir per UDP, tai kitas klausytojas, o ne antrasis to paties režimas.
Kur egzistuoja atskiras TCP egzempliorius, jo tunelio įrenginys, adresų telkinys ir maršrutizavimas yra atskiri ištekliai. Nukopijavus veikiančią konfigūraciją ir pakeitus transporto žodį, tie ištekliai lieka nukreipti į pradinį egzempliorių, todėl gaunamas ryšys, kuris autentifikuojasi ir tada nieko nemaršrutizuoja.
Perskaitykite tarpinio serverio atsakymą prieš VPN rezultatą
Pirmasis kliento mainas yra užklausos eilutė, nurodanti paskirties hostą ir prievadą. Atsakymas į tą eilutę pasako, ar baitų srautas apskritai egzistuoja, ir jis ateina prieš tikrinant bet kurį sertifikatą ar prisijungimo duomenis:
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 |
200 klasės atsakymas į CONNECT reiškia, kad srautas egzistuoja. Jis nieko nesako apie tai, ar tinklo vartų sertifikatas yra patikimas, ar bendras raktas sutampa, ar vartotojo paskyra galioja. Tie patikrinimai vyksta vėliau, srauto viduje, ir jie nepavyksta su paties kliento pranešimais, o ne su HTTP būsenos eilute. Kliento žurnale ieškokite pirmojo OpenVPN įvykio po rankos paspaudimo su tarpiniu serveriu, o ne paskutinės eilutės prieš uždarant langą.
Tarpinio serverio ir VPN prisijungimo duomenys dažnai yra skirtingos tapatybės skirtingų komandų rankose. 407 nėra blogas VPN paskyros slaptažodis, o atmestas sertifikatas nėra tarpinio serverio leidimų problema.
Ko CONNECT neatskleidžia
Aiškus CONNECT tunelis nėra pasiklausymas. Tarpinis serveris persiunčia baitus ir nebaigia VPN TLS sesijos, todėl kliento atliekamas serverio sertifikato tikrinimas išlieka prasmingas ir turėtų likti įjungtas. Tikrinimo išjungimas norint praeiti tarpinį serverį sprendžia kitą problemą nei jūsų.
Yra atskirų susitarimų, kai organizacija sąmoningai baigia ir tikrina TLS. Jiems reikia savo pasitikėjimo konfigūracijos ir savo politikos sprendimo, ir jie nėra tai, ko prašo įprasta http-proxy eilutė.
TCP kaina TCP viduje
Tunelio perdavimas per TCP palaiko išorinį srautą tvarkingą ir su pakartotiniu siuntimu, o vidinis srautas paprastai taip pat yra TCP. Du atkūrimo mechanizmai nesuderinami, todėl vienas prarastas segmentas gali sustabdyti viską, kas dalijasi tuo išoriniu srautu, kol jis nebus persiųstas. Tai tikra mainai dėl suderinamumo, o ne nemokamas atnaujinimas.
Naudokite tarpinio serverio kelią, kai tinklas nepalieka alternatyvos, ir pirmenybę teikite tiesioginiam UDP keliui ten, kur politika leidžia. Bet kuriuo atveju po pakeitimo patikrinkite, ar tas pats tarpinis serveris, paskirties vieta ir profilis pasiekia kitą etapą; naršyklė, kuri tame adrese įkelia puslapį, naudoja kitą protokolą ir nieko neįrodo apie tunelį.