iPhone 앱이 보여 주는 IP와 서버가 기록하는 IP가 다른 이유
인터페이스 주소, 소켓 엔드포인트, 서버가 기록하는 원본은 각각 다른 질문에 답합니다. VPN은 맥락을 더할 뿐, 그것들을 하나의 숫자로 만들지 않습니다.
앱이 보여 주는 주소와 서버가 기록한 주소가 다르다며 어느 쪽이 거짓말이냐고 묻는 지원 티켓이 옵니다. 둘 다 아니며, 이는 서로 다른 두 가지에 대한 두 개의 관측입니다. 인터페이스에 묶인 주소, 소켓에 묶인 주소, 원격 서비스가 보는 원본 주소는 서로 다른 세 가지 질문에 답합니다. VPN은 휴대폰에 네트워크 맥락을 더할 뿐이며 그 세 가지를 기기 전체의 하나의 숫자로 합치지 않습니다. 주소를 읽기 전에 티켓의 필드 이름을 먼저 읽으세요.
티켓이 보통 설명하는 것
Wi-Fi에 연결된 채 터널이 올라가 있는 휴대폰을 상상해 보세요. Wi-Fi 인터페이스는 LAN 주소를 갖고, 터널 인터페이스는 할당된 내부 주소를 갖고, 터널을 통해 나가는 요청은 경로상의 어떤 변환에서든 살아남은 원본으로 공용 서비스에 도착합니다. 내부 주소를 출력하는 앱과 변환된 원본을 기록하는 서버는 둘 다 정확하게 보고하며, 그 두 값은 결코 일치하지 않습니다.
세 관측은 무엇을 설명하는지뿐 아니라 무엇을 증명할 수 있는지에서도 다릅니다.
| Observation | What it describes | What it cannot prove |
|---|---|---|
| An address on a local interface | One configured attachment: Wi-Fi, cellular or a tunnel | The source a remote site receives |
| A socket's local endpoint | The binding used by that one connection | The address after translation further along |
| The peer address at a service | What arrived at that observation point | Any other interface on the phone |
여기서 생기는 혼란의 대부분은 네트워크 고장이 아니라 열을 바꿔 넣은 탓이므로, 그 표는 이 값들을 티켓에 채우는 코드 옆에 두세요.
소켓 호출이 답할 수 있는 것과 없는 것
API 수준에서 getsockname은 현재 특정 소켓에 묶여 있는 로컬 엔드포인트를 보고합니다. 연결된 소켓의 경우 그것은 커널이 그 연결을 위해 고른 원본이며, 어떤 인터페이스 목록보다도 이미 구체적입니다. 이것은 공용 주소 조회가 아니고, 묶이지 않은 소켓에서 호출하면 거의 아무것도 알려 주지 않습니다. 반환하는 값은 나중에 경로상에서 다시 쓰일 수 있으므로, 서비스가 무엇을 받았는지에 대해 권위가 있는 것은 서비스 자신의 관측뿐입니다.
Apple 플랫폼에서는 인터페이스 쪽에 별도의 표면이 있고, 터널 설정이 터널 인터페이스에 할당된 주소를 나열합니다. 그것을 읽으면 터널이 어떻게 구성되었는지는 알 수 있지만, 특정 요청이 어느 경로를 탔는지는 라우팅과 앱별 규칙이 연결마다 결정하므로 알 수 없습니다.
분할 터널링은 그 틈을 눈에 보이게 합니다. 한 요청은 터널을 통해 나가고 다음 요청은 다른 목적지나 다른 주소 체계를 향해 나가지 않을 수 있으므로, 같은 앱에서 몇 초 차이로 나온 두 결과가 정직하면서도 다를 수 있습니다.
질문에 맞는 관측을 고르세요
모든 것을 계측하는 대신 의도적으로 고르세요. 백엔드가 보는 것에 대해서는 백엔드에서 원본을 기록하고, 앞에 리버스 프록시가 있으면 클라이언트 주소를 클라이언트가 보낸 무엇이 아니라 배포가 실제로 설정하는 전달 헤더에서 읽으세요.
터널이 구성되었는지 알아보려면 인터페이스를 읽으세요. 이 앱의 트래픽이 그것을 썼는지 알아보려면 그 앱에서 통제하는 목적지로 트래픽을 보내고 양쪽 끝에서 원본을 비교하세요.
앱별 규칙은 그 자체의 문장을 받을 자격이 있습니다. 브라우저 결과는 그 브라우저에 대한 증거이고, 관리되는 앱별 터널은 같은 휴대폰의 두 앱을 같은 순간에 서로 다른 경로에 둘 수 있습니다. 적용 범위를 확인한다는 것은 문제의 앱에서, 문제의 주소 체계로 트래픽을 보내는 것입니다.
인터페이스 이름은 탐지기가 아닙니다
인터페이스 이름을 VPN 확인으로 쓰지도 마세요. 이름은 공개된 계약이 아니며, 휴대폰이 여러 연결을 가진 채 그중 하나만 당신의 요청을 실을 수 있습니다.
필드 이름은 그것이 담는 관측에 따라 붙이세요. local_interface_address, socket_local_endpoint, service_observed_source는 투박하고 모호하지 않으며, 일주일 뒤 그 값이 지원 티켓에 들어갈 때 필요한 것은 바로 그 모호함이 없음입니다. device IP라는 하나의 열은 세 가지를 모두 모은 뒤 그것이 하나인 것처럼 신뢰를 받게 됩니다.
신원을 주소 열 밖에 두세요
공유 VPN 출구는 사용자 신원이 아니고, 사설 주소는 접근 자격 증명이 아닙니다. 둘 다 사람이 아니라 경로를 설명하며, 둘 중 하나를 인증으로 취급하면 라우팅 사고가 권한 결정으로 바뀝니다.
휴대폰이 어떤 주소를 가졌냐고 누가 물으면, 유용한 대답은 어느 연결이고 어느 관측자인지에 대한 질문입니다. getsockname의 정의는 소켓 질문은 해결하면서 나머지 둘을 해결하는 척하지 않으므로 중간 사례에 인용할 만합니다.
그다음 세 가지 중 제품이 실제로 보여 줘야 하는 것이 무엇인지 적고, 나머지 둘은 화면에서 지우세요.