OpenVPN tra HTTP-prokurilo: unue legu la CONNECT-respondon
CONNECT-prokurilo plusendas bajtojn, do ambaŭ finoj bezonas TCP. Legu 407, 403 kaj 503 antaŭ ol kulpigi la atestilojn, kaj lasu la servilan kontrolon ŝaltita.
Direktu VPN-klienton al kompania HTTP-prokurilo, kaj la unua utila fakto estas, ke la prokurilo ne parolas la protokolon de la VPN. Ĝi malfermas ordinaran TCP-konekton al la adreso, kiun vi indikis, kaj poste flankenpaŝas, lasante vian klienton kaj la servilon fari sian propran interŝanĝon tra tiu fluo. Ĉio, kion la kliento bezonas, de la transporta tipo ĝis la aŭskultanto de la servilo, devas kongrui kun tiu aranĝo. Du malkongruoj klarigas la plej multajn malsukcesojn: UDP-profilo celanta CONNECT-prokurilon, kaj prokurila respondo komprenata kiel VPN-eraro.
Kion la prokurilo portas, kaj kion ĝi ne portas
La prokurilo estas nur transporta paŝo. Ĝi ne fariĝas via retumila prokurilo, ĝi ne kaŝmemorigas la retejojn, kiujn vi vizitas tra la tunelo, kaj ĝi ne vidas la internan trafikon, se iu ne intence agordis inspektadon. La tunelo, kiun ĝi malfermas, estas por ĝi netravidebla pro la dezajno.
Tio ankaŭ signifas, ke la prokurilo ne povas ripari servilon, kiu ne havas kongruan aŭskultanton. Permeso atingi celon kaj servo aŭskultanta ĉe tiu celo estas du apartaj faktoj, kaj nur la unua apartenas al la prokurila administranto.
La portilo devas esti TCP ĉe ambaŭ finoj
Ordinara CONNECT-prokurilo nur plusendas bajtan fluon , do la kliento devas uzi fluan transporton. Klienta fragmento por tiu kazo aspektas tiel:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128La servila flanko bezonas veran TCP-aŭskultanton ĉe la pordo nomita en la linio remote. Ŝanĝi proto udp al proto tcp-client en profilo kreas klienton, kiu atendas fluon; ĝi ne kreas la fluon ĉe la alia flanko. Se la sama servilo ankaŭ respondas per UDP ĉe tiu pordo, tio estas alia aŭskultanto, ne dua reĝimo de la sama.
Kie ekzistas aparta TCP-kazo, ĝia tunela aparato, adresaro kaj enkursigado estas propraj rimedoj. Kopii funkciantan agordon kaj ŝanĝi la transportan vorton lasas tiujn rimedojn montri al la origina kazo, kio produktas konekton, kiu aŭtentikas kaj poste enkursigas nenion.
Legu la prokurilan respondon antaŭ la VPN-rezulto
La unua interŝanĝo de la kliento estas petlinio nomanta la celan gastigan kaj pordon. La respondo al tiu linio diras al vi, ĉu entute ekzistas baja fluo, kaj ĝi alvenas antaŭ ol kontroliĝas iu ajn atestilo aŭ akreditaĵo:
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 |
Respondo de klaso 200 al CONNECT signifas, ke la fluo ekzistas. Ĝi diras nenion pri tio, ĉu la porda atestilo estas fidata, ĉu la komuna ŝlosilo kongruas, aŭ ĉu la uzanta konto validas. Tiuj kontroloj okazas poste, interne de la fluo, kaj ili malsukcesas per la propraj mesaĝoj de la kliento, ne per HTTP-statlinio. Legu la klientan protokolon por la unua OpenVPN evento post la prokurila manpremo, ne por la lasta linio antaŭ ol fermiĝis la fenestro.
Prokurilaj akreditaĵoj kaj VPN-akreditaĵoj ofte estas malsamaj identoj tenataj de malsamaj teamoj. 407 ne estas malbona pasvorto ĉe la VPN-konto, kaj malakceptita atestilo ne estas prokurila permesproblemo.
Kion CONNECT ne malkaŝas
Rekta CONNECT-tunelo ne estas interkaptado. La prokurilo plusendas bajtojn kaj ne finas la TLS-sesion de la VPN, do la kontrolo de la servila atestilo fare de la kliento restas senchava kaj devus resti ŝaltita. Malŝalti la kontrolon por preterpasi prokurilon solvas alian problemon ol la via.
Ekzistas apartaj aranĝoj, kie organizo intence finas kaj inspektas TLS. Tiuj postulas sian propran fidan agordon kaj sian propran politikan decidon, kaj ili ne estas tio, kion petas ordinara http-proxy-linio.
La kosto de TCP ene de TCP
Porti la tunelon super TCP tenas la eksteran fluon ordigita kaj reelsendata, kaj la interna trafiko kutime ankaŭ estas TCP. La du riparaj mekanismoj ne kunordigas, do unu perdita segmento povas haltigi ĉion, kio dividas tiun eksteran fluon, ĝis ĝi estos reelsendita. Tio estas reala interŝanĝo por kongrueco, ne senpaga ĝisdatigo.
Uzu la prokurilan vojon, kiam la reto ne lasas al vi alternativon, kaj preferu rektan UDP-vojon, kie politiko permesas. Ĉiuokaze post ŝanĝo konfirmu, ke la sama prokurilo, celo kaj profilo atingas la sekvan etapon; retumilo, kiu ŝargas paĝon ĉe tiu adreso, uzas alian protokolon kaj pruvas nenion pri la tunelo.