OpenVPN gjennom ein HTTP-proxy: les CONNECT-svaret først
Ein CONNECT-proxy sender bytes vidare, så begge endar treng TCP. Les 407, 403 og 503 før du gir sertifikata skulda, og hald serververifiseringa på.
Pek ein VPN-klient mot ein bedrifts-HTTP-proxy, og det første nyttige faktumet er at proxyen ikkje snakkar VPN-ens protokoll. Han opnar ei vanleg TCP-tilkopling til adressa du oppgav, og trør så til side, slik at klienten og serveren kan gjere si eiga utveksling gjennom den straumen. Alt klienten treng, frå transporttypen til lyttaren til serveren, må passe til den ordninga. To avvik forklarar dei fleste feila: ein UDP-profil retta mot ein CONNECT-proxy, og eit proxy-svar som vert teke for ein VPN-feil.
Kva proxyen ber, og kva han ikkje ber
Proxyen er berre eit transportsteg. Han vert ikkje nettlesarproxyen din, han bufrer ikkje nettstadene du besøkjer gjennom tunnelen, og han ser ikkje den indre trafikken med mindre nokon medvite har sett opp inspeksjon. Tunnelen han opnar, er ugjennomsiktig for han av design.
Det tyder òg at proxyen ikkje kan reparere ein server utan ein samsvarande lyttar. Løyve til å nå ein destinasjon og ei teneste som lyttar på den destinasjonen er to separate fakta, og berre det første høyrer til proxyadministratoren.
Beraren må vere TCP i begge endar
Ein vanleg CONNECT-proxy sender berre ein bytestraum vidare , så klienten må bruke ein straumtransport. Eit klientutdrag for det tilfellet ser slik ut:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Serversida treng ein ekte TCP-lyttar på porten som er nemnd i remote-linja. Å endre proto udp til proto tcp-client i ein profil lagar ein klient som ventar ein straum; det lagar ikkje straumen i den andre enden. Viss same server òg svarar på UDP på den porten, er det ein annan lyttar, ikkje ein andre modus av den same.
Der ein separat TCP-instans finst, er tunneleininga, adressepulen og rutinga hans eigne ressursar. Å kopiere ein fungerande konfigurasjon og endre transportordet lèt desse ressursane peike på den opphavlege instansen, noko som gjev ei tilkopling som autentiserer og deretter ikkje ruter noko.
Les proxy-svaret før VPN-resultatet
Den første utvekslinga til klienten er ei førespurnadslinje som nemner destinasjonsverten og porten. Svaret på den linja fortel deg om det i det heile finst ein bytestraum, og det kjem før noko sertifikat eller noka legitimasjon vert kontrollert:
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 |
Eit svar i 200-klassen på CONNECT tyder at straumen finst. Det seier ingenting om kvidar gateway-sertifikatet er stole på, om den delte nøkkelen passar, eller om brukarkontoen er gyldig. Dei kontrollane skjer etterpå, inne i straumen, og dei feilar med meldingane til klienten sjølv i staden for ei HTTP-statuslinje. Les klientloggen etter den første OpenVPN hendinga etter proxy-handtrykket, ikkje den siste linja før vindauget vart lukka.
Proxy-legitimasjon og VPN-legitimasjon er ofte forskjellige identitetar hos forskjellige team. Ein 407 er ikkje eit dårleg passord på VPN-kontoen, og eit avvist sertifikat er ikkje eit proxy-løyveproblem.
Kva CONNECT ikkje avdekkjer
Ein eksplisitt CONNECT-tunnel er ikkje avlytting. Proxyen sender bytes vidare og avsluttar ikkje TLS-økta til VPN-en, så verifiseringa av servercertifikatet frå klienten held fram med å vere meiningsfull og bør haldast på. Å slå av verifiseringa for å kome forbi ein proxy løyser eit anna problem enn det du har.
Det finst separate ordningar der ein organisasjon medvite avsluttar og inspiserer TLS. Dei krev sin eigen tillitskonfigurasjon og si eiga politikkavgjerd, og dei er ikkje det ei vanleg http-proxy-linje ber om.
Prisen for TCP inne i TCP
Å bere tunnelen over TCP held den ytre straumen i orden og med gjensending, og den indre trafikken er vanlegvis òg TCP. Dei to gjenopprettingsmekanismane koordinerer ikkje, så eitt tapt segment kan stoppe alt som deler den ytre straumen, til det vert sendt på nytt. Det er ei reell avveging for kompatibilitet, ikkje ei gratis oppgradering.
Bruk proxyvegen når nettverket ikkje gjev deg noko alternativ, og føretrekk ein direkte UDP-veg der politikken tillèt det. Uansett bør du etter ei endring stadfeste at same proxy, destinasjon og profil når neste trinn; ein nettlesar som lastar ei side på den adressa, brukar ein annan protokoll og beviser ingenting om tunnelen.