OpenVPN via en HTTP-proxy: läs CONNECT-svaret först
En CONNECT-proxy vidarebefordrar byte, så båda ändarna behöver TCP. Läs 407, 403 och 503 innan du skyller på certifikaten, och håll serververifieringen på.
Rikta en VPN-klient mot en företags-HTTP-proxy, och det första användbara faktumet är att proxyn inte talar VPN:ens protokoll. Den öppnar en vanlig TCP-anslutning till adressen du angav och stiger sedan åt sidan, så att din klient och servern gör sitt eget utbyte genom den strömmen. Allt klienten behöver, från transporttypen till serverns lyssnare, måste passa in i den ordningen. Två missförhållanden förklarar de flesta felen: en UDP-profil riktad mot en CONNECT-proxy, och ett proxy-svar som tas för ett VPN-fel.
Vad proxyn bär, och vad den inte bär
Proxyn är bara ett transportsteg. Den blir inte din webbläsarproxy, den cachar inte webbplatserna du besöker genom tunneln, och den ser inte den inre trafiken om inte någon medvetet har ställt in inspektion. Tunneln den öppnar är ogenomskinlig för den av design.
Det betyder också att proxyn inte kan laga en server utan en matchande lyssnare. Tillstånd att nå en destination och en tjänst som lyssnar på den destinationen är två separata fakta, och bara det första tillhör proxyadministratören.
Bäraren måste vara TCP i båda ändar
En vanlig CONNECT-proxy vidarebefordrar bara en byteström , så klienten måste använda en strömtransport. Ett klientutdrag för det fallet ser ut så här:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128Serversidan behöver en riktig TCP-lyssnare på porten som nämns i remote-raden. Att ändra proto udp till proto tcp-client i en profil skapar en klient som förväntar sig en ström; det skapar inte strömmen i andra änden. Om samma server också svarar över UDP på den porten är det en annan lyssnare, inte ett andra läge av den samme.
Där en separat TCP-instans finns är dess tunnelenhet, adresspool och routing egna resurser. Att kopiera en fungerande konfiguration och ändra transportordet lämnar dessa resurser pekande på den ursprungliga instansen, vilket ger en anslutning som autentiserar och sedan inte routar något.
Läs proxy-svaret före VPN-resultatet
Klientens första utbyte är en begäransrad som namnger destinationsvärden och porten. Svaret på den raden säger om det överhuvudtaget finns en byteström, och det kommer innan något certifikat eller någon autentiseringsuppgift kontrolleras:
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 |
Ett svar i 200-klassen på CONNECT betyder att strömmen finns. Det säger ingenting om huruvida gateway-certifikatet är betrott, om den delade nyckeln stämmer eller om användarkontot är giltigt. De kontrollerna sker efteråt, inne i strömmen, och de misslyckas med klientens egna meddelanden i stället för en HTTP-statusrad. Läs klientloggen efter den första OpenVPN händelsen efter proxy-handskakningen, inte den sista raden innan fönstret stängdes.
Proxy-autentiseringsuppgifter och VPN-autentiseringsuppgifter är ofta olika identiteter hos olika team. En 407 är inte ett dåligt lösenord på VPN-kontot, och ett avvisat certifikat är inte ett proxybehörighetsproblem.
Vad CONNECT inte avslöjar
En explicit CONNECT-tunnel är inte avlyssning. Proxyn vidarebefordrar byte och avslutar inte VPN:ens TLS-session, så klientens verifiering av servercertifikatet förblir meningsfull och bör hållas på. Att stänga av verifieringen för att komma förbi en proxy löser ett annat problem än ditt.
Det finns separata arrangemang där en organisation medvetet avslutar och inspekterar TLS. De kräver sin egen förtroendekonfiguration och sitt eget policybeslut, och de är inte vad en vanlig http-proxy-rad ber om.
Kostnaden för TCP inuti TCP
Att bära tunneln över TCP håller den yttre strömmen ordnad och med omsändning, och den inre trafiken är oftast också TCP. De två återhämtningsmekanismerna samordnar inte, så ett enda förlorat segment kan stoppa allt som delar den yttre strömmen tills det skickas om. Det är en verklig avvägning för kompatibilitet, inte en gratis uppgradering.
Använd proxyvägen när nätverket inte lämnar dig något alternativ, och föredra en direkt UDP-väg där policyn tillåter det. Kontrollera i alla fall efter en ändring att samma proxy, destination och profil når nästa steg; en webbläsare som laddar en sida på den adressen använder ett annat protokoll och bevisar ingenting om tunneln.