Cloudflare 프록시가 하나의 이름으로 OpenVPN을 나를 수 없는 이유

한 대의 머신이 웹사이트와 OpenVPN 서버를 함께 운영하므로, 하나의 호스트 이름을 그 머신으로 향하게 하고 주황색 구름이 트래픽을 정리해 주기를 바라는 유혹이 생깁니다. 프록시가 정리하는 것은 HTTP와 HTTPS입니다. OpenVPN 세션은 그 세션이 어느 포트를 쓰든 정리하지 않습니다. 이름 두 개, 하나는 직접, 하나는 프록시를 거치게 하면 비용이 들지 않고 이런 혼란의 부류 전체가 사라집니다.

두 개의 이름, 두 개의 전송

웹사이트에는 프록시된 레코드를 주어 HTTP와 HTTPS 트래픽이 Cloudflare를 지나게 하십시오. VPN에는 DNS 전용 레코드를 주어 공용 VPN 진입점으로 곧장 해석되게 하고, 클라이언트가 설정된 UDP 또는 TCP 포트를 쓰게 하십시오.

두 이름이 같은 원본 머신에 도달할 수 있습니다. 차이는 클라이언트와 그 머신 사이에서 벌어지는 일이며, 그 차이가 바로 분리의 요점입니다.

Cloudflare의 네트워크 포트 참조에는 일반 웹 프록시가 받아들이는 포트가 나열됩니다. 그 목록은 해당 포트에서의 HTTP와 HTTPS에 관한 것이지, 우연히 같은 번호를 공유하는 임의의 프로토콜에 관한 것이 아닙니다.

포트는 프로토콜이 아니다

OpenVPN을 TCP 443으로 옮긴다고 HTTPS가 되지는 않습니다. 프록시는 여전히 연결 시작 시 HTTP 요청을 기대하고, OpenVPN 클라이언트는 대신 이진 제어 메시지를 보냅니다. 연결은 로그에 유용한 것이 아무것도 닿지 않기 때문에 네트워크 차단처럼 보이는 방식으로 실패합니다.

요구 사항이 정말로 VPN 데이터 경로에 Cloudflare 제품을 넣는 것이라면, 필요한 프로토콜 지원을 문서화한 제품을 평가하십시오. 주황색 구름은 특정한 역할을 가진 웹 트래픽용 리버스 프록시이므로 일반적인 TCP나 UDP 터널이라고 가정하지 마십시오.

DNS 전용 레코드가 실제로 작동하는 지루한 답이며, 가장 먼저 손을 뻗어야 할 대상입니다.

한 대의 머신에는 여전히 두 개의 리스너가 필요하다

이름을 나눈다고 두 프로세스가 같은 주소, 포트, 전송을 동시에 묶을 수 있는 것은 아닙니다. 웹 서버가 이미 모든 주소에서 TCP 443을 점유하고 있다면, OpenVPN 인스턴스는 의도적인 합의 없이 그것을 함께 가져갈 수 없습니다.

VPN 리스너를 다른 포트나 다른 주소에 묶거나, 문서화된 멀티플렉서를 앞에 두고 그에 따르는 운영 비용을 받아들이십시오. 그 각각의 선택은 아무도 문서화하지 않은 리스너가 바로 장애 때 놓치는 리스너이기 때문에 방화벽 규칙에 보여야 합니다. 선택한 바인딩을 터널을 설명하는 같은 런북에 적으십시오. 그러면 다음 사람이 새벽 두 시에 그것을 다시 발견하지 않아도 됩니다.

인증서는 자기가 보호하는 연결을 따른다

브라우저가 Cloudflare로 가는 TLS 연결과 Cloudflare가 당신의 원본으로 가는 연결은 두 개의 별도 인증서를 가진 두 개의 별도 관계입니다. 브라우저는 엣지 인증서를 봅니다. 원본은 자기 인증서를 Cloudflare에 제시하며, Cloudflare Origin CA 인증서는 바로 그 두 번째 관계를 위한 것입니다.

그 원본 인증서는 Full (strict) 모드에서 Cloudflare가 신뢰하며 일반적으로 신뢰되는 브라우저 인증서가 아닙니다. 누군가 DNS 전용 호스트 이름을 직접 방문해 경고를 받는다면, 그것은 신뢰 경로가 바뀐 당연한 결과이지 암호화가 멈췄다는 증거가 아닙니다.

따라서 직접 방문되는 웹사이트에는 그 브라우저들이 신뢰하는 인증서 체인이 필요합니다. 이는 원본을 전혀 방문할 생각이 없는 프록시된 사이트와 공존할 수 있습니다.

OpenVPN은 자체 서버 신원과 클라이언트 인증을 자체 인증 기관과 자체 제어 채널 보호와 함께 지닙니다. 웹사이트의 자물쇠는 그중 아무것도 제공하지 않으며, 두 준비 과정은 분리되어 있어야 합니다.

노출은 이름을 따른다

DNS 전용 VPN 레코드는 자신이 가리키는 주소를 공개합니다. 그 주소가 웹 원본이기도 하다면 원본은 숨겨지지 않으며, 다른 이름이 프록시되었다는 이유로 숨겨졌다고 설명하는 것은 누군가 스캔할 때까지 남는 오류입니다.

어떤 웹 요청이 원본에 직접 닿아도 되는지 정하고 그것을 원본에서 강제한 다음, VPN 리스너를 그 나름의 조건으로 허용하십시오. 관리 페이지, 프로필 다운로드, 데이터 리스너는 하나의 패키지가 셋 다 제공하더라도 서로 다른 세 가지 노출 요건을 가질 수 있습니다.

생성된 링크는 공개 웹 이름과 HTTPS 스킴에 두고, 클라이언트 프로필은 VPN 이름에 실제 프로토콜과 포트로 두십시오. 정상 운영 중에 어느 서비스도 상대의 프록시 설정을 뒤집는 데 의존해서는 안 됩니다.

작업 순서는 사이트에 프록시된 이름, VPN에 DNS 전용 이름, 별도의 리스너, 관계마다 인증서, 그리고 각 이름이 마땅히 닿아야 할 서비스에만 닿는다는 것을 증명하는 한 번의 시험입니다.