넓은 VPN 경로가 일부 공개 사이트를 깨뜨리는 이유

넓은 접두사가 주소를 붙잡기 때문에 일부 사이트만 실패하고 나머지는 로드됩니다. 경로를 확인된 주소와 대조한 뒤 누가 이를 설치했는지 찾아내세요.

대부분의 페이지는 로드되고, 둘 또는 셋은 시간 초과되며, 브라우저는 연결을 탓합니다. 실패하는 사이트에는 작동하는 사이트에 없는 공통점이 있습니다. 확인된 주소가 VPN이 설치한 접두사 안에 들어가는 것입니다. 공개 범위를 덮을 만큼 넓은 경로는 터널이 애초에 전달할 생각이 없던 트래픽을 붙잡고, 증상은 라우팅 결정이 아니라 웹사이트 문제처럼 보입니다.

실패하는 이름을 확인한 다음 브라우저가 아니라 라우팅 테이블을 보세요.

사이트 이름이 아니라 주소를 비교하세요

클라이언트가 실제로 시도한 주소를 찾은 다음 어떤 경로가 그것과 일치하는지 확인하세요. 45.61.20.10 안의 목적지는 그 접두사가 있으면 45.0.0.0/8 아래에 들어갑니다. 사이트 자체가 터널과 아무 관련이 없어도 마찬가지입니다. 실패한 주소를 설치된 접두사와 비교하는 것은 뺄셈 문제이지 추측이 아닙니다.

Windows는 양쪽 절반에 직접 답할 수 있고, 조회는 어떤 인터페이스와 다음 홉이 선택을 이겼는지 보여 줍니다. 사이트가 여러 주소를 반환하면 이름을 두 번 확인하세요. 각각을 일치한 경로와 함께 기록하세요. 주소가 다르면 답도 달라질 수 있고, 그중 하나만 실패 사례일 수 있습니다.

Resolve-DnsName www.example.org
Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 45.61.20.10
Get-VpnConnection | Format-List Name,SplitTunneling,Routes

가장 구체적으로 일치하는 접두사를 읽고, 익숙해 보이는 첫 줄에서 멈추지 마세요. 테이블에 있는 경로가 조회에서 이겼다는 증거는 아니며, 가장 긴 일치가 그것을 결정합니다. 두 접두사가 한 주소에 일치할 수 있고, 패킷을 받는 것은 하나뿐입니다. 진 쪽도 테이블에 남아 목록에서는 똑같이 실제처럼 보입니다.

접두사, 그 인터페이스, 확인된 주소를 적으세요. 이 세 값이 진단의 전부입니다.

경로를 누가 설치했는지 찾으세요

경로는 네 곳에서 옵니다. 기본 VPN 프로필, 관리 정책, 연결 스크립트, 또는 전혀 다른 클라이언트입니다. 활성 항목을 지우면 관련성을 확인할 수 있지만 다음 연결이 저장된 구성에서 그것을 다시 만듭니다. 그래서 바꿔야 하는 것은 근원입니다.

먼저 프로필의 경로 목록을 확인하고, 다음 관리 정책, 다음 연결 시 실행되는 스크립트를 확인하세요. 이 순서는 각각이 책임자로 밝혀지는 빈도와 맞습니다. 변경을 세 계층이 아니라 한 계층에 머물게 합니다.

기본 클래스 기반 동작을 주의해서 읽으세요

기본 Windows 프로필에는 문서화된 설정 NativeProfile/DisableClassBasedDefaultRoute 이 있으며, 인터페이스 주소에서 추론된 자동 경로를 제어합니다. 45로 시작하는 프로필 주소는 이 동작에서 45.0.0.0/8 항목을 만들 수 있고, 이렇게 하나의 공개 주소가 클래스 A 범위 전체를 붙잡습니다.

속성 이름은 잘못된 읽기를 유도합니다. true로 설정하면 추론이 꺼지고 false는 켭니다. 또한 기본 경로와 같은 대상이 아니며, 자체 접두사를 설치하는 타사 클라이언트를 제어하지 않습니다.

추론이 입증된 원인이라면 관리 소유자를 통해 프로필을 고치고 의도한 사설 접두사를 명시적으로 제공하세요. 스크립트가 항목을 추가했다면 스크립트를 고치세요. 설명되지 않은 넓은 경로를 다른 것으로 바꾸는 것은 증상만 바꾸고 질문에 답하지 않습니다.

근원을 고친 다음 두 경로를 다시 확인하세요

변경 후 다시 연결하고 실패하는 공개 사이트와 터널을 써야 하는 리소스에 대해 조회를 반복하세요. 전자는 이제 물리 인터페이스로 확인되어야 하고, 후자는 여전히 VPN을 선택해야 합니다. 첫 성공에서 멈추지 마세요. 사설 접근도 깨뜨리는 수정은 하나의 결함을 다른 결함과 맞바꾼 것입니다.

동시에 서버의 주소 계획을 검토하세요. 공개 공간과 겹치는 풀은 이런 종류의 문제를 거듭 일으킵니다. 운영자가 의도적으로 고른 범위는 자동 재번호가 아니라 다른 대화를 받을 자격이 있습니다.

MTU를 올리거나 DNS를 비우는 것은 그 주소를 여전히 터널로 보내는 접두사를 고치지 못합니다. 먼저 선택을 시험하고, 그다음 경로를 시험하세요.

관련 글