새 핫스팟 클라이언트가 IP 주소 획득에서 멈추는 것은 VPN 결함이 아니다

휴대폰이 핫스팟에 참여하고 «IP 주소 획득 중»에 머물다가 결국 포기합니다. 자연스러운 결론은 휴대폰의 VPN이 DNS를 방해한다는 것이어서 사람들은 리졸버와 추가된 규칙을 편집하기 시작합니다. 그것은 잘못된 단계입니다. 클라이언트는 로컬 주소를 받은 적이 없고, 그것이 없으면 게이트웨이도, 리졸버도, 전달할 것도 없으므로 호스트 휴대폰의 어떤 VPN 설정으로도 이 실패를 설명할 수 없습니다. 연결, 로컬 주소 할당, 그리고 전달은 세 가지 별개의 단계이며, 오직 마지막 단계만 터널과 관련됩니다.

세 단계, 그리고 당신이 있는 단계

먼저 연결이 옵니다: 클라이언트가 핫스팟의 무선 네트워크에 참여합니다. 잘못된 비밀번호, WPA3 불일치, 무선 호환성 문제는 여기서 실패하며 클라이언트는 보통 그렇게 표시합니다. 두 번째는 주소 할당입니다: IPv4의 경우 클라이언트가 임대를 요청하고 주소와 로컬 게이트웨이 설정을 받으며, IPv6은 보통 DHCP 대신 라우터 광고를 사용합니다. AOSP의 테더링 문서가 설명하는 대로입니다. 세 번째는 외부 접근입니다: 호스트 휴대폰이 허용된 트래픽을 자신이 선택한 업스트림 경로로 전달하며, 그 경로는 자신의 터널일 수도 있고 아닐 수도 있습니다.

클라이언트의 문구가 단계를 알려줍니다. 주소 획득에서 멈춰 있는 것은 두 번째 단계로, 아직 인터넷으로 패킷이 나가지 않았습니다. 연결되었고 주소도 있지만 아무것도 로드되지 않는다면 세 번째 단계이며, 여기서는 라우팅, 이름, 터널 범위가 모두 중요합니다. 클라이언트가 두 번째 단계에서 멈춰 있는데 세 번째 단계를 진단하는 것은 오 분짜리 임대 문제를 DNS 편집으로 반나절 보내는 방법입니다.

속설: 라우팅된 VPN이 로컬 DHCP를 원격 요청으로 바꾼다

라우팅된 터널은 자신이 선택한 목적지에 대해 IP 패킷을 옮깁니다. DHCP 검색은 핫스팟 자체 세그먼트의 브로드캐스트이며, 휴대폰의 테더링 서비스가 이를 로컬에서 응답합니다. 그래서 터널이 켜져 있어도 클라이언트가 주소를 받을 수 있습니다. 의도적으로 브리지하거나 릴레이하는 설계만이 그 교환을 다른 곳으로 보내며, 그것은 다른 실패 서명을 가진 다른 구성입니다.

따라서 «VPN 서버가 DHCP에 응답하지 않는다»는 진단이 아니라 모델 오류입니다. 로컬 중개자는 휴대폰에 있습니다. 그것이 응답을 멈춘다면 이유는 로컬입니다: 테더링 서비스, 클라이언트 한도, 임대 풀, 또는 연결을 제대로 끝내지 못한 클라이언트입니다. 그중 어느 것도 터널의 먼 쪽에 있지 않습니다.

기존 클라이언트가 동작한다는 것이 실제로 증명하는 것

이미 연결되어 있던 노트북이 계속 동작하는데 새 휴대폰이 그렇지 않다면, 핫스팟과 업스트림 경로는 대체로 살아 있습니다. 그 비교는 유용하지만 어느 구성 요소가 잘못인지의 증거는 아닙니다. 동작하는 클라이언트가 변경 이전의 임대를 그대로 유지하며 조용히 갱신하고 있을 수 있기 때문입니다.

거기 있는 동안 두 가지 로컬 한도를 확인할 가치가 있습니다. 핫스팟은 유한한 임대 풀과 구성 가능한 클라이언트 한도를 제공하므로, 참여했다가 잠든 기기가 주소를 붙잡고 있는 동안 새 기기가 기다릴 수 있습니다. 그리고 다른 네트워크의 정적 구성을 기억하는 클라이언트는 임대를 아예 요청하지 않으며, 이는 밖에서는 똑같아 보이고 휴대폰이 아니라 클라이언트에서 고칩니다.

비교는 로컬이고 되돌릴 수 있게 유지하세요

정책이 허용하는 기기에서 터널을 끈 상태와 켠 상태로 새 클라이언트의 참여 한 번을 비교하되, 핫스팟과 클라이언트는 그 밖의 부분에서 바꾸지 마세요. 휴대폰과 클라이언트의 버전, 선택한 프로필, 실패한 정확한 단계를 기록하세요. 관리되는 휴대폰에서는 더 깨끗한 시험을 위해 적용을 끄는 대신 승인된 비교를 요청하세요.

터널에 의존하는 일관된 임대 실패는 로컬 정책이나 구현 상호작용에 관한 유용한 증거입니다. 기기의 모든 전달 및 NAT 규칙을 지워도 된다는 허가는 아닙니다. 그 규칙들은 무관한 트래픽을 보호하며, 광범위한 전달 허용은 로컬 DHCP 서비스가 응답을 멈춘 이유를 설명하지 않습니다.

빠진 임대를 추측한 정적 주소로 덮지 마세요. 의도적인 정적 구성에는 실제 서브넷, 게이트웨이, 할당 계획, 충돌 확인이 필요합니다. 클라이언트의 DNS를 바꾸는 것은 그중 어느 것도 제공하지 않으며 다음 기기를 같은 실패에 남겨 둡니다.

임대가 증명하지 않는 것

주소를 받는 것은 로컬 네트워크로의 입장을 증명할 뿐, 휴대폰 터널에 의한 보호를 증명하지 않습니다. 클라이언트가 임대를 가지면 다운스트림 경로를 따로 평가하세요: 클라이언트의 트래픽이 실제로 휴대폰을 지나는가, 조회가 기대하는 곳에서 해석되는가, 외부 주소가 의도한 출구와 일치하는가? 이것들은 세 번째 단계의 질문이며 참여에 접어 넣는 대신 자체 시험을 받을 자격이 있습니다.

단계를 순서대로 다루면 실패가 옮겨 다니지 않습니다. 주소 획득에서 멈춘 클라이언트는 로컬 테더링 문제이고, 주소는 있지만 페이지가 없는 클라이언트는 전달이나 이름 문제이며, 페이지는 있지만 출구가 잘못된 클라이언트는 터널 범위 문제입니다. 이들을 분리해 두는 것이 디버깅의 대부분입니다.