OpenVPN a través d’un proxy HTTP: llegiu primer la resposta CONNECT
Un proxy CONNECT retransmet bytes, així que els dos extrems necessiten TCP. Llegiu 407, 403 i 503 abans de culpar els certificats, i manteniu activa la verificació del servidor.
Adreceu un client VPN a un proxy HTTP corporatiu i el primer fet útil és que el proxy no parla el protocol de la VPN. Obre una connexió TCP senzilla a l’adreça que heu indicat i després es fa a un costat, deixant que el client i el servidor facin el seu propi intercanvi per aquell flux. Tot el que el client necessita, des del tipus de transport fins a l’oient del servidor, ha de coincidir amb aquesta disposició. Dues discrepàncies expliquen la majoria de fallades: un perfil UDP adreçat a un proxy CONNECT i una resposta del proxy presa per un error de la VPN.
Què transporta el proxy i què no
El proxy és només un salt de transport. No es converteix en el proxy del navegador, no fa memòria cau dels llocs que visiteu pel túnel i no veu el trànsit intern tret que algú hagi configurat la inspecció expressament. El túnel que obre és opac per a ell per disseny.
Això també vol dir que el proxy no pot arreglar un servidor que no té cap oient corresponent. El permís per arribar a una destinació i el servei que escolta en aquella destinació són fets separats, i només el primer pertany a l’administrador del proxy.
El transport ha de ser TCP als dos extrems
Un proxy CONNECT convencional només retransmet un flux de bytes , així que el client ha d’utilitzar un transport de flux. Un fragment de client per a aquest cas té aquest aspecte:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128El costat del servidor necessita un oient TCP real al port indicat a la línia remote. Canviar proto udp per proto tcp-client en un perfil crea un client que espera un flux; no crea el flux a l’altre costat. Si el mateix servidor també respon per UDP en aquell port, és un oient diferent, no un segon mode del mateix.
On existeix una instància TCP separada, el seu dispositiu de túnel, el seu pool d’adreces i l’encaminament són recursos propis. Copiar una configuració que funciona i editar la paraula de transport deixa aquests recursos apuntant a la instància original, cosa que produeix una connexió que s’autentica i després no encamina res.
Llegiu la resposta del proxy abans del resultat de la VPN
El primer intercanvi del client és una línia de petició que anomena l’amfitrió i el port de destinació. La resposta a aquesta línia us diu si existeix cap flux de bytes, i arriba abans que es comprovi cap certificat ni cap 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 |
Una resposta de classe 200 a CONNECT significa que el flux existeix. No diu res sobre si el certificat de la passarel·la és de confiança, si la clau compartida coincideix o si el compte d’usuari és vàlid. Aquestes comprovacions passen després, dins del flux, i fallen amb els missatges propis del client en lloc d’una línia d’estat HTTP. Llegiu el registre del client per al primer OpenVPN esdeveniment després de l’apretada de mans amb el proxy, no per a l’última línia abans que es tanqui la finestra.
Les credencials del proxy i les de la VPN sovint són identitats diferents en mans d’equips diferents. Un 407 no és una contrasenya dolenta del compte de la VPN, i un certificat rebutjat no és un problema de permisos del proxy.
Què no exposa CONNECT
Un túnel CONNECT explícit no és intercepció. El proxy reenvia bytes i no acaba la sessió TLS de la VPN, així que la verificació del certificat del servidor per part del client continua tenint sentit i ha de romandre activa. Desactivar la verificació per passar un proxy resol un problema diferent del que teniu.
Hi ha disposicions separades en què una organització acaba i inspecciona TLS deliberadament. Aquestes requereixen la seva pròpia configuració de confiança i la seva pròpia decisió de política, i no són el que demana una línia http-proxy senzilla.
El cost de TCP dins de TCP
Portar el túnel sobre TCP manté el flux exterior ordenat i retransmès, i el trànsit interior normalment també és TCP. Els dos mecanismes de recuperació no es coordinen, així que un sol segment perdut pot bloquejar tot el que comparteix aquell flux exterior fins que es retransmet. És un intercanvi real per compatibilitat, no una actualització gratuïta.
Utilitzeu el camí del proxy quan la xarxa no us deixi cap alternativa, i preferiu un camí UDP directe on la política ho permeti. De qualsevol manera, confirmeu que el mateix proxy, la mateixa destinació i el mateix perfil arriben a la fase següent després d’un canvi; un navegador que carrega una pàgina en aquella adreça fa servir un altre protocol i no demostra res sobre el túnel.