라우터의 VPN에서 STUN이 보는 출발지 주소는?
경로, 출발지 선택, 변환이 리플렉터가 보고하는 주소를 결정합니다. 적어 둘 세 가지 사실과 어느 경로가 이기는지 확인할 질의 하나.
이 질문은 한 번의 조회처럼 들리지만 실제로는 세 가지 결정입니다. binding request가 어느 경로로 나가는지, 그 경로에 대해 커널이 어느 출발지를 고르는지, 그리고 도중에 무언가가 그 출발지를 다시 쓰는지. 셋 중 하나만 바꿔도 STUN 서버가 보고하는 주소가 함께 바뀝니다. 그래서 VPN이 라우터에 있다는 말은 그 자체로 거의 아무것도 알려 주지 않습니다.
결정은 세 가지 사실에 달려 있습니다
첫째 경로에서는 정책 규칙과 라우팅 테이블이 요청이 터널로 나갈지 일반 WAN으로 나갈지를 정하며, 제외된 목적지는 터널이 올라가 있어도 두 번째 경로를 택합니다. 둘째 출발지에서는 커널이 선택된 경로에 대해 출발지를 고르고, 그 선택은 경로의 선호 출발지와 일치한 규칙에 달려 있습니다. 셋째 변환에서는 도중의 NAT가 선택된 출발지를 대체합니다. 반사된 주소는 셋의 곱이며 터널의 속성이 아닙니다.
셋 중 하나를 바꾸면 답이 바뀌지만, 각 구성 요소는 자기 로그에서 여전히 정상으로 보입니다. 이것이 이 진단이 막히는 흔한 이유입니다.
시작하기 전에 시험할 흐름에 대한 세 가지 사실을 적어 두세요. 인터페이스, 경로, 변환 규칙만으로 결과를 예측할 수 있고, 그 예측이야말로 놀라움을 유익하게 만듭니다. 셋 중 하나를 채울 수 없다면 그 공백이 진짜 발견입니다.
binding request 하나를 경로를 따라가며 관찰하기
STUN의 binding request는 서버에 관측한 출발지 전송 주소를 보고하라고 요청합니다.응답은 요청이 지나온 경로를 설명하며, 클라이언트 머신의 인터페이스 목록이 아닙니다. 두 경로를 지난 두 요청은 정직하게 서로 다른 두 주소를 보고합니다.
| Path taken | Source the reflector sees | What it means |
|---|---|---|
| Tunnel to a public exit that translates | The exit's public address | The reflector learns nothing about the LAN |
| Tunnel to a private reflector, translated to the tunnel address, no later translation | That tunnel address | An internal identifier is disclosed to that reflector |
| Excluded flow over the ordinary WAN | The WAN address | The tunnel was not used at all |
그 표는 공급자 메뉴가 아니라 조건의 집합으로 읽으세요. 가운데 줄은 사설 리플렉터가 터널 자체의 라우팅과 피어 정책 아래에서 도달 가능해야 한다고 요구하는데, 이는 검증할 수 있는 구성 사실이며 계정 등급이 함축하는 것이 아닙니다. 아래 줄은 그 트래픽이 터널 안에 머물러야 했기 때문에 보통 정책상 중요합니다. 그 사이에 일반적인 경우가 있고, 출구가 변환하며 리플렉터는 출구만 봅니다.
호스트 후보와 서버 반사 후보는 서로 다른 메커니즘에서 나오므로 후보 목록은 미디어가 실제로 어느 경로를 썼는지 말해 주지 않습니다. 세션이 어디로 갔는지 알고 싶을 때는 수집 로그가 아니라 선택된 쌍을 읽으세요.
라우터의 터널 주소가 아닌 것
라우터에 할당된 터널 주소는 라우터의 한 인터페이스에 속합니다. LAN 호스트의 브라우저는 자신의 인터페이스 주소를 가지며 라우터의 터널 인터페이스를 직접 보지 못합니다. 둘을 서로 바꿀 수 있는 것으로 다루면 웹 페이지가 무엇을 알 수 있는지에 대해 자신만만한 잘못된 답이 나옵니다.
전달이 둘을 연결합니다. 요청은 라우팅된 트래픽으로 라우터를 지나며, 그 출발지는 라우팅과 변환이 만들어 낸 것입니다.
터널 경로가 LAN 출발지를 보존하면 사설 리플렉터가 그 LAN 주소를 알 수 있고, 이는 실제 노출이며 터널 주소와 다릅니다. 경로가 터널 주소로 변환하면 리플렉터는 대신 터널 주소를 알게 됩니다. 두 결과 모두 같은 호스트의 같은 브라우저와 양립하므로 관측은 특정 흐름에 묶여야 합니다. 애플리케이션을 탓하기 전에 커널이 어느 출발지를 쓸지 물어보세요.
노출과 우회: 두 가지 발견, 두 가지 수정
반사된 터널 주소는 허용한 경로로 내부 식별자를 노출합니다. WAN을 통한 직접 요청은 강제하려던 경로를 우회합니다. 전자는 정보의 문제, 후자는 집행의 문제이며 고치는 곳이 다릅니다. 둘을 한 단어로 합치면 어느 쪽도 다루지 못하는 수정이 됩니다.
WebRTC는 후보를 모으는 것이 후보를 고르는 것과 같지 않기 때문에 이것을 틀리게 하지 않으면서 더 잘 보이게 합니다.
ip route get 203.0.113.7 from 192.0.2.25
ip rule show허용하는 모든 리플렉터 주소에 대해 그 흐름이 실어 나른다고 기대하는 출발지로 경로 질의를 실행하고, 다음으로 제외된 범위에 대해서도 실행해 대안이 무엇을 고르는지 보세요. 두 답을 적어 둔 정책과 비교하세요. 의도하지 않은 방식으로 다르다면 브라우저의 후보 목록을 해석할 필요 없이 수정 지점을 찾은 것입니다.