도메인 프런팅은 VPN이 아니다: 두 이름, 하나의 요청

두 기법이 한 서랍에 들어가는 이유는 둘 다 중개자를 끼고 있고 둘 다 숨기는 것처럼 들리기 때문이다. 하지만 작동하는 대상이 다르다. 도메인 프런팅은 하나의 HTTPS 요청에서 어느 계층에 어느 이름이 나타나는가의 문제다. VPN은 어떤 패킷이 어떤 경로로 피어까지 가는가의 문제다. 프런팅을 VPN의 한 종류라고 부르면 작동할 수 없는 설계와, 엉뚱한 질문을 하는 검토가 나온다.

두 이름, 두 계층

TLS 연결은 핸드셰이크에 서버 이름을 실을 수 있다. 연결이 만들어지면 HTTP 요청은 자기가 원하는 권한을 밝히며, 보통 Host 헤더에 담는다. 이 둘은 서로 다른 시점에 서로 다른 소프트웨어 조각이 읽는 두 개의 필드다.

도메인 프런팅은 앞의 두 계층 사이의 차이를 이용해, 프런팅 서비스가 연결을 받아들인 뒤 요청을 다른 곳으로 보내게 한다. 그것이 통하는 곳은 그 서비스가 그렇게 보내기를 허용하는 경우뿐이며, 이는 프로토콜 요령이 아니라 공급자 정책의 문제다.

프런팅은 기법이 아니라 공급자에 달려 있다

제한된 예로, Front Door 자주 묻는 질문 Azure의 문서는 도메인 프런팅에 대한 보호를 기록한다. 같은 구독과 구성된 경로 안의 도메인에 대해서는 허용되는 불일치가 있고, 불일치 보호가 요청을 막을 때는 421 Misdirected Request 응답이 온다고 설명한다.

그렇게 문서화된 하나의 정책이 두 구호를 동시에 무너뜨린다. 서로 다른 이름의 모든 조합이 통하는 것도 아니고, 모든 불일치가 금지되는 것도 아니다. 다른 서비스에는 저마다의 검사, 저마다의 배포 요건, 저마다의 오류 코드가 있다.

이것은 다른 네트워크의 제한을 우회하는 지침도 아니다. 공급자의 라우팅 규칙을 읽어 무엇을 허용하는지 이해하는 일은 설계 작업이다. 그 규칙을 우회 요령으로 다루는 것은 다른 결과를 낳는 다른 행위다. 쓰는 문서에서는 이 두 행위를 분리해 두어라. 검토에서 설계가 반려되는 이유는 후자다.

VPN이 실제로 고르는 것

네트워크 VPN에서는 라우팅과 플랫폼 정책이 피어로 가는 터널에 넣을 내부 트래픽을 고른다. 구성에 따라 여러 애플리케이션이나 정해진 일부를 대상으로 할 수 있고, HTTP 요청이 전혀 없는 프로토콜도 실어 나를 수 있다.

프런팅은 그중 어느 것도 하지 않는다. 프런팅 서비스를 통해 HTTPS 요청 하나를 마련해도 사설 네트워크 경로가 설치되지 않고, 임의의 UDP 애플리케이션이 실려 나가지 않으며, 기기의 모든 프로그램이 그 서비스를 쓰게 되지도 않는다. 그런 범위가 필요하다면 필요한 것은 프록시나 터널이지 이름 요령이 아니다.

검토에서 둘이 혼동되는 이유는, 둘 다 중개자로 설명되고 둘 다 접속에 관한 문서에 등장하기 때문이다. 각자가 제공하는 인터페이스는 전혀 다르고, 네트워크 경로인 것은 둘 중 하나뿐이다.

가시성은 이분법이 아니다

비교도 단순히 숨김 대 공개가 아니다. DNS 질의, 목적지 주소, 핸드셰이크 특징, 패킷 크기, 타이밍은 모두 그것을 볼 위치에 있는 사람에게는 관찰 가능한 채로 남고, 그 관찰자가 무엇을 알아내는지는 그가 어디에 앉아 있는지에 달려 있다.

애플리케이션 데이터도 그것을 종료하는 종단점에서 보인다. 요청을 라우팅하는 프런팅 서비스가 그 종단점 중 하나이고, VPN 피어는 또 다른 하나다. 어느 구성도 당신에게 서비스하려면 내용을 읽어야 하는 상대에게 내용을 불투명하게 만들지 않는다.

세 개의 상자를 그려라

설계 검토를 위해 TLS 종단점, HTTP 라우팅 서비스, 최종 애플리케이션을 세 개의 별도 상자로 그리고, 그다음 어떤 VPN 피어든 다시 다른 곳에 그려라. 웹 목적지를 고르는 곳과 사설 네트워크 패킷을 나르는 곳이 같은 시스템일 필요는 없고, 보통은 아니다.

상자가 분리되면 질문은 답할 수 있는 것이 된다. 이 공급자는 어떤 이름을 받아들이는가, 어떤 프로토콜에 운반이 필요한가, 어느 쪽이 무엇을 볼 수 있는가. 그것들을 하나로 합친 다이어그램은 아무도 구현할 수 없는 설계와, 어휘를 두고 다투는 검토를 낳는다.