OpenVPN gjennom en HTTP-proxy: les CONNECT-svaret først
En CONNECT-proxy videresender bytes, så begge ender trenger TCP. Les 407, 403 og 503 før du gir sertifikatene skylden, og hold serververifiseringen på.
Pek en VPN-klient mot en bedrifts-HTTP-proxy, og det første nyttige faktum er at proxyen ikke snakker VPN-ens protokoll. Den åpner en vanlig TCP-forbindelse til adressen du oppgav, og trer så til side, slik at klienten og serveren kan gjøre sin egen utveksling gjennom den strømmen. Alt klienten trenger, fra transporttypen til serverens lytter, må passe til den ordningen. To avvik forklarer de fleste feilene: en UDP-profil rettet mot en CONNECT-proxy, og et proxy-svar som tas for en VPN-feil.
Hva proxyen bærer, og hva den ikke bærer
Proxyen er bare et transportsteg. Den blir ikke nettleserproxyen din, den bufrer ikke nettstedene du besøker gjennom tunnelen, og den ser ikke den indre trafikken med mindre noen bevisst har satt opp inspeksjon. Tunnelen den åpner, er ugjennomsiktig for den av design.
Det betyr også at proxyen ikke kan reparere en server uten en samsvarende lytter. Tillatelse til å nå en destinasjon og en tjeneste som lytter på den destinasjonen er to separate fakta, og bare det første tilhører proxyadministratoren.
Bæreren må være TCP i begge ender
En vanlig CONNECT-proxy videresender bare en bytestrøm , så klienten må bruke en strømtransport. Et klientutdrag for det tilfellet ser slik ut:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Serversiden trenger en ekte TCP-lytter på porten som er nevnt i remote-linjen. Å endre proto udp til proto tcp-client i en profil lager en klient som forventer en strøm; det lager ikke strømmen i den andre enden. Hvis samme server også svarer på UDP på den porten, er det en annen lytter, ikke en andre modus av den samme.
Der en separat TCP-instans finnes, er tunneleenheten, adressepuljen og rutingen dens egne ressurser. Å kopiere en fungerende konfigurasjon og endre transportordet lar disse ressursene peke på den opprinnelige instansen, noe som gir en forbindelse som autentiserer og deretter ikke ruter noe.
Les proxy-svaret før VPN-resultatet
Klientens første utveksling er en forespørselslinje som navngir destinasjonsverten og porten. Svaret på den linjen forteller deg om det i det hele tatt finnes en bytestrøm, og det kommer før noe sertifikat eller noen legitimasjon kontrolleres:
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 |
Et svar i 200-klassen på CONNECT betyr at strømmen finnes. Det sier ingenting om hvorvidt gateway-sertifikatet er betrodd, om den delte nøkkelen passer, eller om brukerkontoen er gyldig. De kontrollene skjer etterpå, inne i strømmen, og de feiler med klientens egne meldinger i stedet for en HTTP-statuslinje. Les klientloggen etter den første OpenVPN hendelsen etter proxy-håndtrykket, ikke den siste linjen før vinduet ble lukket.
Proxy-legitimasjon og VPN-legitimasjon er ofte forskjellige identiteter hos forskjellige team. En 407 er ikke et dårlig passord på VPN-kontoen, og et avvist sertifikat er ikke et proxy-tillatelsesproblem.
Hva CONNECT ikke avdekker
En eksplisitt CONNECT-tunnel er ikke avlytting. Proxyen videresender bytes og avslutter ikke VPN-ens TLS-økt, så klientens verifisering av servercertifikatet forblir meningsfull og bør holdes på. Å slå av verifiseringen for å komme forbi en proxy løser et annet problem enn det du har.
Det finnes separate ordninger der en organisasjon bevisst avslutter og inspiserer TLS. De krever sin egen tillitskonfigurasjon og sin egen politikkbeslutning, og de er ikke det en vanlig http-proxy-linje ber om.
Prisen for TCP inne i TCP
Å bære tunnelen over TCP holder den ytre strømmen i orden og med gjensending, og den indre trafikken er vanligvis også TCP. De to gjenopprettingsmekanismene koordinerer ikke, så ett tapt segment kan stoppe alt som deler den ytre strømmen, til det sendes på nytt. Det er en reell avveining for kompatibilitet, ikke en gratis oppgradering.
Bruk proxyveien når nettverket ikke gir deg noe alternativ, og foretrekk en direkte UDP-vei der politikken tillater det. Uansett bør du etter en endring bekrefte at samme proxy, destinasjon og profil når neste trinn; en nettleser som laster en side på den adressen, bruker en annen protokoll og beviser ingenting om tunnelen.