Windows VPN 라우팅 테이블에 0.0.0.0/1과 128.0.0.0/1이 표시되는 이유

Windows VPN에 연결해 라우팅 테이블을 열면 두 항목이 눈에 띕니다. 0.0.0.0/1과 128.0.0.0/1입니다. 이들은 오타가 아니며 기본 경로를 대체하지도 않습니다. 표시 여부는 프로필 옵션 하나에 달려 있고, 이 쌍은 스플릿 터널 기능이 아니라 전체 터널을 구성하는 방식입니다. 한 줄이라도 바꾸기 전에 옵션, 접두사, 인터페이스를 함께 읽으세요.

기본 게이트웨이 옵션이 설치하는 것

모든 것을 터널로 보내는 프로필 옵션은 이 두 접두사를 추가하는 방식으로 동작합니다. 옵션을 해제하면 두 항목이 사라지고 터널 어댑터에 부여된 서브넷만 포함하는 경로가 남습니다. 체크박스는 이 쌍을 제어하며 단일 기본 경로를 다시 쓰지는 않습니다. 그래서 체크를 해제한 뒤의 테이블은 삭제가 아니라 부분적인 재작성처럼 보입니다.

0.0.0.0/1은 IPv4 공간의 아래 절반을, 128.0.0.0/1은 위 절반을 포함하므로 함께 모든 유니캐스트 주소를 포함합니다. 각각은 기본 0.0.0.0/0보다 더 구체적이므로 최장 접두사 일치가 일반 트래픽을 터널로 보내고 물리적 기본 경로는 원래 자리에 남습니다. 그 기본 경로를 유지하는 것은 겉치레가 아닙니다. 암호화된 페이로드를 감싸는 패킷은 서버의 공인 주소로 향하며 물리 어댑터를 통해 나가야 합니다. 기본 경로를 분할하지 않고 대체하면 터널 자체의 전송이 터널로 들어가려 하며, 이는 연결이 아니라 루프입니다.

따라서 VPN 어댑터를 가리키는 문자 그대로의 0.0.0.0/0이 있다면 잠시 멈출 만합니다. 네이티브 클라이언트는 보통 그런 경로를 쓰지 않으므로 수동 경로나 다른 클라이언트의 구성이 몰래 테이블을 바꾼 것입니다. 하위 계층을 디버깅하기 전에 그것을 찾으세요.

게이트웨이를 저장하는 것보다 해제가 저렴하다

하나가 아니라 두 항목을 두는 실용적 근거는 해제입니다. 클라이언트는 연결 중에 정확히 두 개의 경로를 소유하고 연결이 끊기면 이를 삭제하여 그 순간 물리 어댑터가 가진 것을 남깁니다. 단일 기본 경로를 대체했던 클라이언트라면 이전 게이트웨이를 기억해야 하고, DHCP 임대가 바뀐 뒤에는 더 이상 존재하지 않는 게이트웨이를 복원할 수도 있습니다. 소유한 두 항목은 그런 상태를 지니지 않습니다.

다른 클라이언트들도 같은 설계에 도달했습니다. redirect-gateway def1을 사용하는 OpenVPN 프로필은 기본 경로를 삭제하는 대신 이 두 접두사를 설치하며, Windows 클라이언트도 같은 라우팅 이유로 이 패턴을 따릅니다.

분할을 기대했는데 테이블이 전체 터널처럼 보이는 것도 이 때문입니다. 이 쌍은 전체 터널을 구성하는 방식이지 스플릿 터널 실수의 증거가 아닙니다. 프로필이 원격 게이트웨이를 사용하도록 설정되어 있으면 로컬 애플리케이션이 무엇에 닿든 모든 것이 라우팅됩니다.

가장 긴 접두사는 어떤 메트릭보다 먼저 이긴다

접두사 길이가 다른 어떤 필드보다 먼저 조회를 결정합니다. 메트릭은 동일한 접두사를 가진 경로 사이의 동점만 깨므로 /1 항목은 메트릭이 더 나빠도 /0 기본 경로를 이깁니다. 인터페이스 바인딩은 두 경로가 접두사를 공유할 때 Windows가 어느 어댑터로 패킷을 보낼지 선택해야 하는 상황에서 남는 것을 결정합니다.

route print -4
Get-NetRoute -AddressFamily IPv4 | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.50.5.20

스플릿 터널 테이블에는 물리적 기본 경로, 두 개의 절반 기본 경로, 터널 서브넷 경로, 추가한 모든 사무실 접두사가 들어 있습니다. 물리적 기본 경로는 클라이언트와 프로필에 따라 더 낮거나 높은 메트릭에 있을 수 있으며, /1 쌍이 존재하는 동안에는 그 차이가 아무것도 바꾸지 않습니다. 쌍이 제거되는 순간 모든 것이 바뀌고, 바로 그때 오래된 게이트웨이나 잘못된 인터페이스가 드러납니다. 바꿀 것으로 예상한 한 줄이 아니라 테이블 전체를 읽으세요.

사무실 접두사에 소유자를 하나만 정하라

스플릿 터널에서는 VPN을 사용해야 하는 접두사만 지정하고, 그것을 소유하는 방법을 하나 선택하세요. 경로를 할당된 터널 주소로 지정하는 방식은 그 주소가 바뀔 때까지 동작하고, 인터페이스 바인딩은 주소 변경은 견디지만 프로필 재구성 후 인덱스가 다시 할당되면 깨집니다. 프로필에 바인딩된 cmdlet은 두 문제를 모두 피하지만 프로필이 필요합니다.

route -p add 10.50.0.0 mask 255.255.0.0 172.16.8.1
route -p add 10.50.0.0 mask 255.255.0.0 0.0.0.0 IF 31
Add-VpnConnectionRoute -ConnectionName Office -DestinationPrefix 10.50.0.0/16

cmdlet은 접두사를 지정된 프로필에 바인딩하므로 경로가 연결과 함께 나타나고 연결과 함께 사라지며, 관리되는 노트북이 원하는 것이 바로 이것입니다. 영구 경로는 재부팅을 넘어 유지되고 그것을 유발한 프로필도 넘어 유지되므로, 퇴역한 VPN이 수년간 항목을 남기는 방식입니다. 접두사마다 방법을 하나 선택하고 그 선택을 기록하세요. 영구 경로와 같은 접두사에 대한 프로필 경로가 함께 있으면 해제 시 풀기 힘든 중복이 생깁니다. 무엇을 선택하든 소유권은 머신에만이 아니라 티켓에도 보여야 합니다.

소유권이 이 절이 답하는 질문이며 문법이 아닙니다. 하나의 접두사에 소유자가 둘이 되는 것이 피해야 할 실패 모드입니다.

웹사이트가 아니라 목적지로 검증하라

출구 주소를 알려 주는 웹사이트가 아니라 터널을 통과해야 하는 목적지를 테스트하세요. Find-NetRoute 선택된 경로와 원본 주소를 반환하므로 사무실 접두사가 이겼는지 물리적 기본 경로가 이겼는지 볼 수 있고, 그다음 공유 자체를 엽니다.

Find-NetRoute -RemoteIPAddress 10.50.5.20
Get-VpnConnection -Name Office

출구 주소 사이트는 약한 검증입니다. DNS, IPv6, 브라우저 프록시가 각각 다른 경로로 그 요청을 보낼 수 있기 때문입니다. IPv4와 IPv6는 같은 대화상자에 별도 설정도 있어서 한쪽 상자를 지워도 다른 쪽 체계는 그대로이므로, 이중 스택 머신은 IPv4가 분할 경로를 따르는 동안 IPv6를 터널로 보낼 수 있습니다. 프로필을 분할이라고 부르기 전에 두 체계를 모두 확인하세요. 경로가 맞는데도 서비스가 실패하면 남은 계층은 라우팅이 아니라 필터링입니다.

클라이언트가 관리하는 방화벽은 완벽한 라우팅 테이블이 있어도 사무실 서브넷을 차단할 수 있습니다. 그 정책은 프로필을 배포한 쪽의 것이지 경로를 편집하는 사람의 것이 아닙니다.