OpenVPN fia in HTTP-proxy: lês earst it CONNECT-antwurd
In CONNECT-proxy ferstjoert bytes, dus beide einen hawwe TCP nedich. Lês 407, 403 en 503 foardat jo de sertifikaten de skuld jouwe, en hâld de serverferifikaasje oan.
Rjochtsje in VPN-klant op in bedriuws-HTTP-proxy, en it earste nuttige feit is dat de proxy it protokoll fan ’e VPN net sprekt. Hy iepenet in gewoane TCP-ferbining nei it adres dat jo neamd hawwe en stapt dan op side, wêrtroch jo klant en de server har eigen útwikseling troch dy stream dwaan. Alles wat de klant nedich hat, fan it transporttype oant de listener fan ’e server, moat by dy regeling passe. Twa misferhâldings ferklearje de measte mislearrings: in UDP-profyl rjochte op in CONNECT-proxy, en in proxy-antwurd dat foar in VPN-flater oansjoen wurdt.
Wat de proxy draacht, en wat net
De proxy is mar in transportstap. Hy wurdt net jo browserproxy, hy bewarret de siden dy’t jo troch de tunnel besykje net yn ’e cache, en hy sjocht it ynderlike ferkear net, útsein as immen opsetlik ynspeksje konfigurearre hat. De tunnel dy’t hy iepenet is foar him ûntrochsichtich neffens it ûntwerp.
Dat betsjut ek dat de proxy in server sûnder byhearrende listener net reparearje kin. Tastimming om in bestimming te berikken en in tsjinst dy’t op dy bestimming harket binne twa aparte feiten, en allinnich it earste heart by de proxy-administrator.
De drager moat oan beide einen TCP wêze
In gewoane CONNECT-proxy ferstjoert allinnich in bytestream , dus de klant moat in streamtransport brûke. In klientsfragmint foar dat gefal sjocht der sa út:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128De serverside hat in echte TCP-listener nedich op ’e poarte dy’t yn ’e remote-rigel neamd wurdt. It feroarjen fan proto udp nei proto tcp-client yn in profyl makket in klant dy’t in stream ferwachtet; it makket de stream net oan ’e oare kant. As deselde server op dy poarte ek oer UDP antwurdet, is dat in oare listener, net in twadde modus fan deselde.
Wêr’t in aparte TCP-ynstânsje bestiet, binne syn tunnelapparaat, adrespôle en routing eigen boarnen. In wurkjende konfiguraasje kopiearje en it transportwurd feroarje lit dy boarnen nei de oarspronklike ynstânsje wize, wat in ferbining opsmyt dy’t autentisearret en dan neat rûtelet.
Lês it proxy-antwurd foar it VPN-resultaat
De earste útwikseling fan ’e klant is in oanfregelrigel dy’t de bestimmingshost en -poarte neamt. It antwurd op dy rigel fertelt jo oft der hielendal in bytestream bestiet, en it komt foardat hokker sertifikaat of bewiis dan ek kontrolearre wurdt:
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 |
In antwurd fan klasse 200 op CONNECT betsjut dat de stream bestiet. It seit neat oer oft it gateway-sertifikaat fertroud is, oft de dielde kaai oerienkomt, of oft it brûkersaccount jildich is. Dy kontrôles barre dêrnei, binnen de stream, en se mislearje mei de eigen berjochten fan ’e klant ynstee fan in HTTP-statusrigel. Sjoch yn it klantlogboek nei it earste OpenVPN barren nei de proxy-hânskikking, net nei de lêste rigel foardat it finster tichte.
Proxy-bewizen en VPN-bewizen binne faak ferskate identiteiten yn hannen fan ferskate teams. In 407 is gjin ferkeard wachtwurd op it VPN-account, en in wegere sertifikaat is gjin proxy-tastimmingsprobleem.
Wat CONNECT net blootleit
In eksplisite CONNECT-tunnel is gjin ûnderskepping. De proxy ferstjoert bytes en einiget de TLS-sesje fan ’e VPN net, dus de ferifikaasje fan it serversertifikaat troch de klant bliuwt sinfol en moat oan bliuwe. Ferifikaasje útskeakelje om in proxy foarby te kommen is in oar probleem oplosse as dat jo hawwe.
Der besteane aparte regelingen wêrby’t in organisaasje TLS opsetlik einiget en ynspektearret. Dy freegje har eigen fertrouwenskonfiguraasje en har eigen beliedsbeslút, en se binne net wat in gewoane http-proxy-rigel freget.
De kosten fan TCP yn TCP
De tunnel oer TCP drage hâldt de bûtenste stream oardere en mei werstjoering, en it ynderlike ferkear is meastentiids ek TCP. De twa herstelmechanismen koördinearje net, dus ien ferlern segmint kin alles stopsette wat dy bûtenste stream dielt oant it wer ferstjoerd wurdt. Dat is in echte ruil foar kompatibiliteit, gjin fergees opwurdearring.
Brûk it proxypaad as it netwurk jo gjin alternatyf lit, en foarkar in direkt UDP-paad wêr’t belied it tasteat. Yn elk gefal, befêstigje nei in feroaring dat deselde proxy, bestimming en profyl de folgjende stap berikke; in browser dy’t in side op dat adres laadt brûkt in oar protokoll en bewiist neat oer de tunnel.