OpenVPN a través dun proxy HTTP: lea primeiro a resposta CONNECT
Un proxy CONNECT retransmite bytes, así que os dous extremos necesitan TCP. Lea 407, 403 e 503 antes de culpar os certificados, e manteña activa a verificación do servidor.
Dirixa un cliente VPN a un proxy HTTP corporativo e o primeiro dato útil é que o proxy non fala o protocolo da VPN. Abre unha conexión TCP normal ao enderezo que indicou e despois apártase, deixando que o cliente e o servidor fagan o seu propio intercambio por ese fluxo. Todo o que o cliente necesita, desde o tipo de transporte ata o oínte do servidor, debe coincidir con esa disposición. Dous desaxustes explican a maioría dos fallos: un perfil UDP dirixido a un proxy CONNECT e unha resposta do proxy tomada por un erro da VPN.
Que transporta o proxy e que non
O proxy é só un salto de transporte. Non se converte no proxy do navegador, non almacena en caché os sitios que visita polo túnel e non ve o tráfico interno salvo que alguén configurase a inspección a propósito. O túnel que abre é opaco para el por deseño.
Iso tamén significa que o proxy non pode arranxar un servidor que non ten un oínte correspondente. O permiso para chegar a un destino e un servizo que escoita nese destino son feitos distintos, e só o primeiro pertence ao administrador do proxy.
O portador debe ser TCP nos dous extremos
Un proxy CONNECT convencional só retransmite un fluxo de bytes , así que o cliente debe usar un transporte de fluxo. Un fragmento de cliente para ese caso ten este aspecto:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128O lado do servidor necesita un oínte TCP real no porto indicado na liña remote. Cambiar proto udp por proto tcp-client nun perfil crea un cliente que espera un fluxo; non crea o fluxo no outro extremo. Se o mesmo servidor tamén responde por UDP nese porto, é outro oínte, non un segundo modo do mesmo.
Onde existe unha instancia TCP separada, o seu dispositivo de túnel, o seu conxunto de enderezos e o seu encamiñamento son recursos propios. Copiar unha configuración que funciona e editar a palabra de transporte deixa eses recursos apuntando á instancia orixinal, o que produce unha conexión que se autentica e logo non encamiña nada.
Lea a resposta do proxy antes do resultado da VPN
O primeiro intercambio do cliente é unha liña de solicitude que nomea o host e o porto de destino. A resposta a esa liña dille se existe algún fluxo de bytes, e chega antes de que se comprobe calquera certificado ou credencial:
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 |
Unha resposta de clase 200 a CONNECT significa que o fluxo existe. Non di nada sobre se o certificado da pasarela é de confianza, se a clave compartida coincide ou se a conta de usuario é válida. Esas comprobacións ocorren despois, dentro do fluxo, e fallan coas propias mensaxes do cliente en lugar dunha liña de estado HTTP. Lea o rexistro do cliente para o primeiro OpenVPN evento despois do aperto de mans co proxy, non para a última liña antes de que se pechase a xanela.
As credenciais do proxy e as da VPN adoitan ser identidades distintas en mans de equipos distintos. Un 407 non é un contrasinal incorrecto da conta da VPN, e un certificado rexeitado non é un problema de permisos do proxy.
Que non expón CONNECT
Un túnel CONNECT explícito non é intercepción. O proxy reenvía bytes e non remata a sesión TLS da VPN, así que a verificación do certificado do servidor por parte do cliente segue tendo sentido e debe permanecer activa. Desactivar a verificación para pasar un proxy resolve un problema distinto do que ten.
Existen disposicións separadas nas que unha organización remata e inspecciona TLS a propósito. Esas requiren a súa propia configuración de confianza e a súa propia decisión de política, e non son o que pide unha liña http-proxy corrente.
O custo de TCP dentro de TCP
Levar o túnel sobre TCP mantén o fluxo exterior ordenado e con retransmisión, e o tráfico interior adoita ser tamén TCP. Os dous mecanismos de recuperación non se coordinan, así que un só segmento perdido pode deter todo o que comparte ese fluxo exterior ata que se retransmita. É un intercambio real por compatibilidade, non unha actualización gratuíta.
Use a ruta do proxy cando a rede non lle deixe alternativa, e prefira unha ruta UDP directa onde a política o permita. En calquera caso, tras un cambio confirme que o mesmo proxy, o mesmo destino e o mesmo perfil chegan á seguinte etapa; un navegador que carga unha páxina nese enderezo exerce outro protocolo e non demostra nada sobre o túnel.