OpenVPN gennem en HTTP-proxy: læs CONNECT-svaret først
En CONNECT-proxy videresender bytes, så begge ender har brug for TCP. Læs 407, 403 og 503, før du giver certifikaterne skylden, og hold serververifikationen slået til.
Peg en VPN-klient mod en virksomheds-HTTP-proxy, og den første nyttige kendsgerning er, at proxyen ikke taler VPN'ens protokol. Den åbner en almindelig TCP-forbindelse til den adresse, du angav, og træder derefter til side, så din klient og serveren kan køre deres egen udveksling gennem den strøm. Alt, klienten har brug for, fra transporttypen til serverens lytter, skal passe til den ordning. To uoverensstemmelser forklarer de fleste fejl: en UDP-profil rettet mod en CONNECT-proxy, og et proxy-svar der tages for en VPN-fejl.
Hvad proxyen bærer, og hvad den ikke gør
Proxyen er kun et transportspring. Den bliver ikke din browserproxy, den cacher ikke de sider, du besøger gennem tunnelen, og den ser ikke den indre trafik, medmindre nogen bevidst har konfigureret inspektion. Den tunnel, den åbner, er uigennemsigtig for den af design.
Det betyder også, at proxyen ikke kan reparere en server uden en matchende lytter. Tilladelse til at nå en destination og en tjeneste, der lytter på den destination, er to separate fakta, og kun det første tilhører proxyadministratoren.
Bæreren skal være TCP i begge ender
En almindelig CONNECT-proxy videresender kun en bytestrøm , så klienten skal bruge en strømtransport. Et klientuddrag til det tilfælde ser sådan ud:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Serversiden har brug for en rigtig TCP-lytter på den port, der er nævnt i remote-linjen. At ændre proto udp til proto tcp-client i en profil skaber en klient, der forventer en strøm; det skaber ikke strømmen i den anden ende. Hvis den samme server også svarer på UDP på den port, er det en anden lytter, ikke en anden tilstand af den samme.
Hvor der findes en separat TCP-instans, er dens tunneleenhed, adressepulje og routing egne ressourcer. At kopiere en fungerende konfiguration og ændre transportordet efterlader disse ressourcer pegende på den oprindelige instans, hvilket giver en forbindelse, der godkender og derefter ikke router noget.
Læs proxy-svaret før VPN-resultatet
Klientens første udveksling er en anmodningslinje, der navngiver destinationsværten og porten. Svaret på den linje fortæller dig, om der overhovedet findes en bytestrøm, og det kommer, før noget certifikat eller nogen legitimationsoplysning 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 betyder, at strømmen findes. Det siger intet om, hvorvidt gateway-certifikatet er betroet, om den delte nøgle passer, eller om brugerkontoen er gyldig. De kontroller sker bagefter, inde i strømmen, og de fejler med klientens egne meddelelser i stedet for en HTTP-statuslinje. Læs klientloggen efter den første OpenVPN hændelse efter proxy-håndtrykket, ikke efter den sidste linje, før vinduet lukkede.
Proxy-legitimationsoplysninger og VPN-legitimationsoplysninger er ofte forskellige identiteter hos forskellige teams. En 407 er ikke en dårlig adgangskode på VPN-kontoen, og et afvist certifikat er ikke et proxy-tilladelsesproblem.
Hvad CONNECT ikke afslører
En eksplicit CONNECT-tunnel er ikke aflytning. Proxyen videresender bytes og afslutter ikke VPN'ens TLS-session, så klientens verifikation af servercertifikatet forbliver meningsfuld og bør holdes slået til. At slå verifikationen fra for at komme forbi en proxy løser et andet problem end det, du har.
Der findes separate ordninger, hvor en organisation bevidst afslutter og inspicerer TLS. De kræver deres egen tillidskonfiguration og deres egen politikbeslutning, og de er ikke det, en almindelig http-proxy-linje beder om.
Prisen for TCP inde i TCP
At bære tunnelen over TCP holder den ydre strøm i orden og genudsender, og den indre trafik er normalt også TCP. De to genopretningsmekanismer koordinerer ikke, så et enkelt tabt segment kan stoppe alt, der deler den ydre strøm, indtil det genudsendes. Det er en reel afvejning for kompatibilitet, ikke en gratis opgradering.
Brug proxyvejen, når netværket ikke giver dig noget alternativ, og foretræk en direkte UDP-vej, hvor politikken tillader det. Under alle omstændigheder skal du efter en ændring bekræfte, at den samme proxy, destination og profil når næste trin; en browser, der indlæser en side på den adresse, bruger en anden protokol og beviser intet om tunnelen.