VPN이 라우터에서 실행될 때 STUN 응답이 알려주는 것

터널이 라우터에 있으면 브라우저를 실행하는 컴퓨터에는 터널 인터페이스가 전혀 없습니다. 그 컴퓨터에 로컬 주소를 물으면 사설 LAN 주소와 루프백이 나올 뿐 VPN 주소를 닮은 것은 없습니다. 그래도 반대편의 STUN 서버는 경로에 대해 여전히 의미 있는 무언가를 보고할 수 있으며, 무엇을 보고하는지는 그 특정 요청이 어떻게 라우팅되고 변환되었는지에 전적으로 달려 있습니다.

바로 이 부분에서 속도를 늦출 가치가 있습니다. “브라우저가 VPN 주소를 소유하지는 않는다”는 인터페이스에 관한 질문에 답하는 반면, 반사된 주소는 변환을 거치는 경로에 대한 답입니다. 둘을 혼동하면 증거가 뒷받침하지 않는 노출에 관한 확신에 찬 결론이 나옵니다.

두 장치, 두 세트의 인터페이스

라우터 기반 구성에서는 터널이 라우터에서 끝나고 LAN 클라이언트는 일반 트래픽을 기본 게이트웨이로 보냅니다. 클라이언트의 인터페이스 목록은 사설 주소 하나, 다른 네트워크를 위한 두 번째 주소, 루프백 정도로 짧게 유지됩니다. 위험은 그중 하나가 우연히 터널 주소인 것이 아니라, 요청이 선택하지 않은 경로로 나가는 것입니다.

어떤 인터페이스가 있는지 묻는 대신 클라이언트에 특정 목적지가 어떤 경로를 택할지 물으십시오. 답은 게이트웨이와 커널이 사용할 출발지 주소를 지목하며, 그것은 어떤 주소 목록보다 이미 더 많은 정보를 담고 있습니다.

ip route get 198.51.100.20
ip -6 route get 2001:db8::20
wg show wg0 allowed-ips

문서용 주소 범위는 결코 실제 서비스로 해석되지 않으므로 좋은 테스트 대상입니다. 클라이언트가 말하는 것과 라우터가 말하는 것을 비교하고, 어떤 불일치든 정책 라우팅, 분할 터널 규칙 또는 두 번째 기본 경로가 고려하지 않은 일을 하고 있다는 증거로 다루십시오.

Binding 응답이 말할 수 있는 것

RFC 8489는 Binding 요청과 응답을 정의하며, 서버는 해당 요청에 대해 관찰한 출발지 전송 주소를 보고합니다. 이것은 한 순간의 하나의 오중항에 대한 진술이며 클라이언트 인터페이스의 인구 조사가 아닙니다. 따라서 흥미로운 모든 일은 클라이언트와 관찰 지점 사이에서 일어납니다.

그 틈을 라우팅과 변환이 채웁니다. 나가는 트래픽에 출발지 NAT를 수행하는 라우터는 클라이언트의 사설 출발지를 나가는 인터페이스의 자기 주소로 바꿉니다. 그 인터페이스가 터널이면 반사기는 터널 주소를 봅니다. 패킷이 터널에서 제외되었다면 반사기는 WAN 변환이 만들어낸 것을 봅니다. 같은 클라이언트, 같은 반사기, 다른 답입니다.

비슷해 보이지만 그렇지 않은 세 경우

유용한 구분은 공인 대 사설이 아니라 어느 집행 지점이 패킷을 처리했는지입니다. 브라우저 하나가 작성했다 잊은 규칙에 따라 세 가지를 모두 만들어낼 수 있으므로 라우터 자체의 표를 열어 둔 채 경우를 살펴보십시오.

두 번째 경우만이 일부 트래픽이 결코 직접 나가지 않아야 한다는 요구를 깨뜨리고, 첫 번째와 세 번째 경우만이 터널 측 식별자를 노출합니다. 세 행 중 어느 것도 특정 공급자의 행동에 대한 주장이 아니며, 사설 반사기에 도달할 수 있는지는 라우팅, 상대편의 허용된 IP 주소, 양쪽 끝의 방화벽 정책에 달려 있습니다.

같은 공급자의 계정을 가지고 있다고 해서 그중 어느 것도 입증되지 않습니다. 라우팅된 요청은 아무것도 변환하지 않으면 클라이언트의 LAN 출발지를 유지할 수 있으므로 출발지 필드는 토폴로지 다이어그램에서 가정하지 말고 추적해야 한다는 점도 기억할 가치가 있습니다.

수집은 선택이 아니다

WebRTC는 시도할 후보 주소를 수집하며, 진단 목록에 나타난 후보가 실제로 미디어를 전혀 나르지 않았을 수 있습니다. 목록을 “상대편이 배운 것은 이것”이라고 읽는 것은 증거를 과대평가합니다. 실제로 세션을 나른 것은 선택된 쌍이며, 그것은 다른 필드에 있습니다.

HTTPS 출구 검사기는 해당 요청에 대해 웹 서버가 본 출발지 주소라는 또 다른 질문에 답합니다. 이것이 유용한 교차 검사인 이유는 UDP 반사기와 다른 프로토콜을, 흔히 다른 목적지를 사용하기 때문이며, 둘 사이의 불일치는 보통 버그가 아니라 라우팅 규칙을 가리킵니다.

정책을 정한 다음 답을 읽으십시오

테스트 전에, 어떤 트래픽이 터널을 써야 하는지, 어느 것이 직접 나가도 되는지, 어떤 주소 계열이 범위에 있는지, 터널이 끊겼을 때 무슨 일이 일어나야 하는지를 적어 두십시오. 그 기준선이 없으면 의도적으로 허용한 경로와 누출을 구분할 수 없으므로 모든 관찰은 모호합니다.

그런 다음 한 번에 하나씩 물으십시오. 이 목적지는 어떤 경로를 택하는가. 이 반사기는 어떤 주소를 보고하는가. 세션은 어느 후보 쌍을 선택했는가. 답을 정책 옆에 두고, 펌웨어 업데이트가 작년의 결론을 조용히 무효화할 수 있음을 고려해 날짜를 붙이십시오.

라우터는 여전히 강력한 집행 지점입니다. 클라이언트가 스스로를 재구성하지 않고는 우회할 수 없는 트래픽을 보기 때문이며, 모든 애플리케이션 프로토콜의 모든 필드가 아무것도 드러내지 않는다는 약속도, 허용하기로 선택한 경로를 적어 두는 일을 대신하지도 않습니다.