HTTP 프록시를 통한 OpenVPN: 먼저 CONNECT 응답을 읽으십시오
CONNECT 프록시는 바이트를 중계하므로 양쪽 끝에 TCP가 필요합니다. 인증서를 탓하기 전에 407, 403, 503을 읽고 서버 검증을 켜 두십시오.
VPN 클라이언트를 기업 HTTP 프록시로 향하게 하면, 첫 번째 유용한 사실은 프록시가 VPN의 프로토콜을 말하지 않는다는 것입니다. 프록시는 지정한 주소로 평범한 TCP 연결을 열고 나서 비켜서며, 클라이언트와 서버가 그 스트림을 통해 자체 교환을 수행합니다. 클라이언트에 필요한 모든 것, 전송 유형에서 서버의 리스너까지 이 배치와 맞아야 합니다. 대부분의 실패는 두 가지 불일치, 즉 CONNECT 프록시를 겨냥한 UDP 프로필과 VPN 오류로 오해된 프록시 응답으로 설명됩니다.
프록시가 운반하는 것과 운반하지 않는 것
프록시는 전송 단계일 뿐입니다. 브라우저 프록시가 되지 않고, 터널을 통해 방문하는 사이트를 캐시하지 않으며, 누군가 의도적으로 검사를 구성하지 않는 한 내부 트래픽을 보지 않습니다. 프록시가 여는 터널은 설계상 프록시에게 불투명합니다.
이는 프록시가 일치하는 리스너가 없는 서버를 고칠 수 없다는 뜻이기도 합니다. 목적지에 도달할 권한과 그 목적지에서 수신하는 서비스는 별개의 사실이며, 전자만 프록시 관리자에게 속합니다.
운반자는 양쪽 끝 모두 TCP여야 합니다
일반적인 CONNECT 프록시는 바이트 스트림만 중계합니다, 따라서 클라이언트는 스트림 전송을 사용해야 하며, 해당 경우의 클라이언트 조각은 다음과 같습니다.
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128서버 측에는 remote 줄에 명시된 포트에서 실제 TCP 리스너가 필요합니다. 프로필에서 proto udp을 proto tcp-client으로 바꾸면 스트림을 기대하는 클라이언트가 생길 뿐, 반대편에 스트림이 생기지는 않습니다. 같은 서버가 그 포트에서 UDP로도 응답한다면 그것은 다른 리스너이며, 같은 리스너의 두 번째 모드가 아닙니다.
별도의 TCP 인스턴스가 있는 곳에서는 그 터널 장치, 주소 풀, 라우팅이 각자의 자원입니다. 작동하는 구성을 복사하고 전송 단어만 바꾸면 그 자원들이 원래 인스턴스를 가리킨 채로 남아, 인증은 되지만 아무것도 라우팅하지 않는 연결이 생깁니다.
VPN 결과보다 프록시 응답을 먼저 읽으십시오
클라이언트의 첫 교환은 목적지 호스트와 포트를 지정하는 요청 줄입니다. 그 줄에 대한 응답은 바이트 스트림이 존재하는지를 알려 주며, 어떤 인증서나 자격 증명이 확인되기 전에 도착합니다:
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 |
CONNECT에 대한 200번대 응답은 스트림이 존재한다는 뜻입니다. 게이트웨이 인증서가 신뢰되는지, 공유 키가 일치하는지, 사용자 계정이 유효한지는 말해 주지 않습니다. 그 확인은 나중에 스트림 안에서 일어나며, HTTP 상태 줄이 아니라 클라이언트 자체 메시지로 실패합니다. 클라이언트 로그에서 프록시 핸드셰이크 이후의 첫 OpenVPN 이벤트를 찾아야 하며, 창이 닫히기 전의 마지막 줄이 아닙니다.
프록시 자격 증명과 VPN 자격 증명은 서로 다른 팀이 보유한 서로 다른 신원인 경우가 많습니다. 407은 VPN 계정의 잘못된 비밀번호가 아니며, 거부된 인증서는 프록시 권한 문제가 아닙니다.
CONNECT가 드러내지 않는 것
명시적 CONNECT 터널은 도청이 아닙니다. 프록시는 바이트를 전달하고 VPN의 TLS 세션을 종료하지 않으므로, 클라이언트의 서버 인증서 검증은 여전히 의미가 있으며 켜 둬야 합니다. 프록시를 통과하려고 검증을 끄는 것은 여러분의 문제와 다른 문제를 푸는 일입니다.
조직이 의도적으로 TLS를 종료하고 검사하는 별도의 구성도 있습니다. 그것들은 자체 신뢰 구성과 자체 정책 결정이 필요하며, 평범한 http-proxy 줄이 요구하는 것이 아닙니다.
TCP 안의 TCP 비용
터널을 TCP 위로 운반하면 바깥 스트림이 순서와 재전송을 유지하고, 안쪽 트래픽도 보통 TCP입니다. 두 복구 메커니즘은 서로 조정하지 않으므로, 세그먼트 하나가 손실되면 재전송될 때까지 그 바깥 스트림을 공유하는 모든 것이 멈출 수 있습니다. 이는 호환성을 위한 실제 맞바꿈이며 무료 업그레이드가 아닙니다.
네트워크가 대안을 남기지 않을 때는 프록시 경로를 사용하고, 정책이 허용하는 곳에서는 직접 UDP 경로를 선호하되, 변경 후 같은 프록시, 목적지, 프로필이 다음 단계에 도달하는지 확인하십시오. 그 주소에서 페이지를 로드하는 브라우저는 다른 프로토콜을 사용하며 터널에 대해 아무것도 증명하지 않습니다.