VPN은 연결됐지만 IP 주소가 바뀌지 않았습니다: 이유

연결하면 클라이언트는 연결됐다고 하고, 주소 테스트는 이전과 같은 숫자를 계속 보여 줍니다. 표시등에 문제가 있는 것은 아니고, 프로필과 앱 사이의 무언가가 그 요청을 터널 밖에 붙잡아 둔 것입니다. 설정을 건드리기 전에 공인 주소를 한 번도 측정하지 않은 테스트, 트래픽의 일부만 덮는 터널, 라우팅 결정을 이기는 두 번째 경로 중 무엇을 보고 있는지 정하세요. 각각에는 일 분이 채 걸리지 않는 확인이 하나씩 있습니다.

테스트가 실제로 무엇을 측정했는지 확인하세요

Wi-Fi 또는 Ethernet 대화 상자에 표시되는 주소는 자기 구간의 인터페이스 주소이며 웹사이트가 보는 주소가 아니므로, 터널이 완벽하게 작동해도 그대로일 수 있습니다. 위치도 별개의 신호로, 저장된 계정 지역이나 허용된 지리 위치 판독은 출구를 바꿔도 움직이지 않고 이미 당신을 인식하는 로그인도 마찬가지입니다.

공인 주소 에코를 사용하고 각 주소 체계에 따로 물어보세요(이중 스택 테스트 결과는 흥미로운 경우를 숨기기 때문):

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

연결 전과 후에 둘 다 실행하세요. IPv4 응답이 출구 주소로 바뀌고 IPv6 응답이 그대로라면 터널이 고장 난 것이 아니라 한 체계가 그 밖으로 다니는 것입니다. 두 응답이 모두 그대로라면 요청이 터널에 아예 닿지 않았고 여기 나머지가 적용됩니다.

프로필이 트래픽의 일부만 덮을 수 있습니다

분할 터널 프로필은 흔한 답이며 결함이 아닙니다. OpenVPN은 redirect-gateway가 푸시된 옵션에 있을 때만 모든 것을 터널로 보내며, 그것이 없으면 클라이언트는 몇 개의 특정 경로를 받고 기본 경로는 물리 링크에 남습니다. Windows에서는 같은 스위치가 어댑터의 IPv4 속성에 «원격 네트워크에서 기본 게이트웨이 사용»으로 나타나며, 이를 해제하는 것은 다시 연결할 때마다 유지되는 의도적인 선택입니다.

앱별 범위는 두 번째 계층입니다. Android의 앱별 VPN 설정은 어떤 앱이 포함되는지 정하므로 상태 표시줄의 VPN 키가 브라우저가 그 안에 있다는 것을 증명하지 않습니다. 자기 트래픽을 프록시하는 브라우저 확장은 거울상을 만들어, 브라우저는 출구 주소를 보여 주지만 같은 컴퓨터의 메일 클라이언트나 게임은 여전히 당신의 주소를 보여 줍니다. 같은 요청을 두 앱에서 비교하세요. 하나가 바뀌고 다른 하나가 그대로라면 보고 있는 것은 범위이지 고장 난 터널이 아닙니다.

한 주소 체계는 여전히 직접 나갈 수 있습니다

대부분의 VPN 프로필은 IPv4용으로 작성되었고 지금도 그런 경우가 많습니다. 이중 스택 네트워크에서 터널은 IPv4용으로 10.8.0.x를 받지만 물리 링크는 전역 IPv6 주소와 기본 경로를 유지하므로, IPv6를 지원하는 사이트는 직접 도달하고 그것이 보고하는 주소는 공급자의 주소입니다. 이것은 작동하는 IPv4 터널이 있어도 새는 것이며, IPv4만 말하는 테스트에는 보이지 않습니다.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

각 응답에서 인터페이스를 읽으세요. IPv6 조회가 당신의 Ethernet 또는 Wi-Fi 장치를 지목하는데 IPv4 조회가 터널을 지목한다면, 그 체계의 정책은 고장 난 것이 아니라 없는 것입니다. 장치 전체에서 IPv6를 끄면 증상은 사라지고 결정은 숨겨지므로, 프로필의 적용 범위를 고치거나 그 연결에서만 체계를 비활성화하는 편이 낫고, 둘 중 무엇을 골랐는지 기록하세요.

두 번째 경로가 조회를 이길 수 있습니다

경쟁 프록시, 두 번째 VPN 클라이언트, 컨테이너나 원격 데스크톱 도구의 가상 어댑터, 또는 테스트 중인 정확한 프리픽스에 대한 추가 경로가 모두 우선할 수 있습니다. 특정 경로는 항상 기본 경로를 이기므로, 측정 중인 사이트를 위한 남은 /24가 LAN 게이트웨이를 가리키면 터널이 아무리 건강해도 그 트래픽은 계속 터널 밖으로 나갑니다.

무엇이든 바꾸기 전에 읽기 전용 명령으로 목록을 만드세요:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

그럴듯한 메트릭을 가진 기본 경로가 둘 이상인지, 목적지를 덮는 특정 경로가 있는지 찾으세요. 브라우저에서는 프록시 확장이나 시스템 프록시 설정이 연결을 소유하는지도 확인하는데, 확장은 자체 업스트림을 지목하고 운영 체제의 출구를 그대로 둘 수 있어 같은 컴퓨터의 터미널과 다른 주소가 브라우저에 나타납니다.

새 요청으로 다시 측정하세요

다시 연결한 뒤, 캐시된 페이지나 재사용된 연결이 이전 상태를 보고하므로 처음 테스트한 것과 같은 앱에서 측정을 반복하세요. 연결하는 동안에는 클라이언트의 로그나 이벤트 보기를 지켜보세요: 인증 후 경로를 적용할 때의 오류는 어떤 표시보다 강한 증거이며 보통 실패한 경로나 어댑터를 지목합니다.

두 결과를 분리하세요. 주소가 바뀌었는데 한 사이트가 여전히 거부한다면 터널은 작동하고 사이트가 데이터 센터 주소를 거부하는 것이며, 그것은 다른 답을 가진 다른 문제입니다. 주소가 결코 바뀌지 않는다면 테스트가 어떤 주소를 출력했는지, 어떤 체계였는지, 어떤 앱이 요청했는지, 그 요청이 어떤 경로를 따랐는지 네 가지 질문을 순서대로 진행하세요. VPN 라우팅 결정에 관한 Microsoft 문서는 둘 다 경로가 있을 때 Windows 클라이언트가 터널과 물리 어댑터 중 무엇을 고르는지 설명합니다.