OpenVPN deur ’n HTTP-proxy: lees eers die CONNECT-antwoord
’n CONNECT-proxy stuur greus deur, so albei kante het TCP nodig. Lees 407, 403 en 503 voordat jy die sertifikate blameer, en hou bedienerverifiëring aan.
Rig ’n VPN-kliënt op ’n korporatiewe HTTP-proxy, en die eerste nuttige feit is dat die proxy nie die VPN se protokol praat nie. Dit open ’n gewone TCP-verbinding na die adres wat jy genoem het en tree dan opsy, sodat jou kliënt en die bediener hul eie uitruiling deur daardie stroom doen. Alles wat die kliënt nodig het, van die vervoertipe tot die bediener se luisteraar, moet by daardie reëling pas. Twee wanpassings veroorsaak die meeste mislukkings: ’n UDP-profiel wat op ’n CONNECT-proxy gerig is, en ’n proxy-antwoord wat as ’n VPN-fout misverstaan word.
Wat die proxy dra, en wat dit nie dra nie
Die proxy is ’n vervoersprong. Dit word nie jou blaaierproxy nie, dit kas nie die terreine wat jy deur die tonnel besoek nie, en dit sien nie die binneste verkeer nie, tensy iemand opsetlik inspeksie ingestel het. Die tonnel wat dit oopmaak, is per ontwerp ondeursigtig vir hom.
Dit beteken ook dat die proxy nie ’n bediener kan regmaak wat geen ooreenstemmende luisteraar het nie. Toestemming om ’n bestemming te bereik en ’n diens wat op daardie bestemming luister, is aparte feite, en net die eerste een behoort aan die proxy-administrateur.
Die draer moet aan albei kante TCP wees
’n Konvensionele CONNECT-proxy stuur net ’n greusstroom deur , dus moet die kliënt ’n stroomvervoer gebruik. ’n Kliëntfragment vir daardie geval lyk so:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Die bedienerkant het ’n werklike TCP-luisteraar nodig op die poort wat in die remote-lyn genoem word. Om proto udp na proto tcp-client in ’n profiel te verander, skep ’n kliënt wat ’n stroom verwag; dit skep nie die stroom aan die ander kant nie. As dieselfde bediener ook op UDP op daardie poort antwoord, is dit ’n ander luisteraar, nie ’n tweede modus van dieselfde een nie.
Waar ’n aparte TCP-instansie bestaan, is sy tonneltoestel, adrespoel en roetering eie hulpbronne. Om ’n werkende konfigurasie te kopieer en die vervoerwoord te wysig, laat daardie hulpbronne na die oorspronklike instansie wys, wat ’n verbinding lewer wat verifieer en dan niks roeteer nie.
Lees eers die proxy-antwoord voor die VPN-uitslag
Die kliënt se eerste uitruiling is ’n versoeklyn wat die bestemmingsgasheer en -poort noem. Die antwoord op daardie lyn vertel jou of daar hoegenaamd ’n greusstroom bestaan, en dit kom voordat enige sertifikaat of geloofsbrief nagegaan word:
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 |
’n Antwoord in die 200-reeks op CONNECT beteken die stroom bestaan. Dit sê niks oor of die gateway-sertifikaat vertrou word, of die gedeelde sleutel pas, of die gebruikersrekening geldig is nie. Daardie kontroles gebeur daarna, binne die stroom, en hulle misluk met die kliënt se eie boodskappe eerder as ’n HTTP-statuslyn. Lees die kliëntlog vir die eerste OpenVPN gebeurtenis ná die proxy-handskud, nie vir die laaste reël voordat die venster toegemaak het nie.
Proxy-geloofsbriewe en VPN-geloofsbriewe is dikwels verskillende identiteite wat deur verskillende spanne gehou word. ’n 407 is nie ’n slegte wagwoord op die VPN-rekening nie, en ’n verwerpte sertifikaat is nie ’n proxy-toestemmingsprobleem nie.
Wat CONNECT nie blootlê nie
’n Eksplisiete CONNECT-tonnel is nie onderskepping nie. Die proxy stuur greus deur en beëindig nie die VPN se TLS-sessie nie, so die kliënt se verifiëring van die bediener-sertifikaat bly betekenisvol en moet aan bly. Om verifiëring af te skakel om by ’n proxy verby te kom, los ’n ander probleem op as dié wat jy het.
Daar bestaan aparte reëlings waar ’n organisasie TLS doelbewus beëindig en inspekteer. Dié vereis hul eie vertrouenskonfigurasie en hul eie beleidsbesluit, en hulle is nie wat ’n gewone http-proxy-lyn vra nie.
Die koste van TCP binne TCP
Om die tonnel oor TCP te dra, hou die buitenste stroom georden en herversend, en die binneste verkeer is gewoonlik ook TCP. Die twee herstelmechanismes koördineer nie, so ’n enkele verlore segment kan alles wat daardie buitenste stroom deel, laat stilstaan totdat dit herversend word. Dit is ’n werklike ruil vir versoenbaarheid, nie ’n gratis opgradering nie.
Gebruik die proxy-pad wanneer die netwerk jou geen alternatief laat nie, en verkies ’n direkte UDP-pad waar beleid dit toelaat. Maak in elk geval seker dat dieselfde proxy, bestemming en profiel ná ’n verandering die volgende stadium bereik; ’n blaaier wat ’n bladsy by daardie adres laai, gebruik ’n ander protokol en bewys niks oor die tonnel nie.