Windows VPN에 255.255.255.255가 표시됩니다: 마스크가 잘못된 걸까요?

터널은 연결되는데 어댑터 세부 정보를 열어 보면 마스크가 255.255.255.255로 표시된다. 사무실 LAN의 255.255.255.0와 비교하면 고장처럼 보이고, 보통 그 지점에서 판단이 틀어진다. 지점 간 링크에서 호스트 마스크는 로컬 끝점을 정확히 설명하는 값이며, 원격 네트워크는 직접 연결된 서브넷이 아니라 경로로 전달된다. 아래 절차는 두 질문을 분리해, 표시값 하나 때문에 멀쩡한 DHCP 범위를 다시 만들지 않도록 한다.

지점 간 링크는 이더넷 세그먼트가 아니다

이더넷 인터페이스에 서브넷 마스크가 필요한 이유는 그 범위의 모든 주소가 같은 케이블에서 도달 가능할 수 있기 때문이다. PPP 방식 터널의 반대편에는 상대가 정확히 하나뿐이다. 브로드캐스트 도메인도, ARP도 없고, 로컬 주소가 범위를 설명해야 할 이유도 없다.

이 모델의 주소 협상은 RFC 1332에 정의되어 있으며, 양 끝이 각자의 주소에 어떻게 합의하는지 설명한다. 다만 사무실 LAN을 직접 연결된 네트워크로 클라이언트에 넘기지는 않는다. 클라이언트는 링크를 통해 경로를 설치하면서 사무실의 위치를 배우고, 실제 도달성을 결정하는 것은 이 경로들이다.

그렇다고 해서 보이는 모든 마스크가 옳다는 뜻은 아니다. 잘못 구성된 클라이언트도 이상한 주소를 만들 수 있다. 논점은 더 좁다. 이 유형의 어댑터에서 호스트 마스크는 예상되는 값이므로, 그 자체로는 고장의 증거가 아니다.

1단계: 인터페이스 유형 확인

무엇을 말하는지 판단하기 전에 어댑터가 무엇인지 확인한다. 설명 문자열이 드라이버를 알려 주고, 할당된 주소의 접두사 길이가 클라이언트가 협상한 결과를 뒷받침한다:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

논쟁을 끝내는 것은 세 번째 명령이다. 최대 전송 단위가 낮은 것은 캡슐화된 링크의 특징이고, 이더넷에 가까운 값은 다른 가상 어댑터 모델을 가리킨다. 설명에 PPP 또는 RAS 드라이버가 있고 접두사가 32라면, 바로 위에서 설명한 설계를 보고 있는 것이므로 마스크 걱정은 접어도 된다.

2단계: 실패하는 목적지의 경로 읽기

도달성은 목적지별로 결정되며, 연결된 인터페이스 하나로는 아무것도 알 수 없다. 사용자가 실제로 도달하려는 주소를 라우팅 테이블에 직접 물어본다:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute가 직접적인 답이다. 그 목적지에 시스템이 사용할 인터페이스와 원본 주소를 알려 준다. 터널이 반환되면 그 호스트로 가는 트래픽은 터널을 지나며, 마스크는 애초에 문제가 아니었다.

물리 어댑터가 반환되면 두 후보 경로와 메트릭을 비교한다. 더 구체적인 로컬 경로, 다른 클라이언트에서 남은 항목, 물리 경로의 더 낮은 메트릭은 모두 넓은 터널 경로를 이긴다. 보이는 결과는 나머지는 다 되는데 한 리소스만 닿지 않는 것이다. 더 긴 접두사가 항상 이기므로, 승자는 몇 달 전 누군가 추가하고 잊은 호스트 경로인 경우가 많다.

여기서 양방향도 함께 확인한다. 서버 쪽으로 가는 경로는 필요조건일 뿐 충분조건이 아니다. 응답도 터널을 통해 돌아와야 하기 때문이다. 내부 호스트 하나는 되고 다른 하나는 안 될 때, 차이는 대개 어댑터 설정이 아니라 이 표에 있다.

3단계: 이름 해석과 서비스 접근 분리

공유를 열지 못하는 앱은 아주 다른 두 단계 중 하나에서 실패할 수 있다. 먼저 이름을 해석하고, 다음으로 주소에 도달한다. 앞이 실패하고 뒤가 성공하면 터널은 정상이고 리졸버가 문제다:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

주소 테스트가 성공하고 이름 테스트가 실패하면 문제는 이름 해석으로 좁혀진다. 두 번째 명령은 터널 인터페이스가 서버를 받았는지도 보여 준다. 많은 클라이언트가 터널 설정의 일부로 DNS를 밀어 넣는데, 그 밀어 넣은 옵션을 무시하는 프로필은 사설 영역을 보지 못하는 리졸버를 남긴다.

되는 주소를 영구 수정으로 여기지 않는다. 주소로 접속하면 이름 해석을 우회하고, 앱이 원래 수행해야 할 서버 신원 검증을 약화시킬 수 있다. 이것은 임시 우회책으로 포장된 보안 후퇴다. 문제를 좁히는 데 쓰고, 그다음 이름 해석을 고친다.

되돌리기: 표시값 때문에 DHCP를 다시 만들지 말 것

주소 서비스를 이미 바꾸기 시작했다면 멈추고, 바꾼 것 중에 기반을 지탱하는 것이 있는지 확인한다. 범위를 다시 만들거나 임대를 다시 내주거나 풀을 옮기면 다른 클라이언트가 의존하는 상태가 바뀐다. 지점 간 어댑터의 호스트 마스크는 그 어느 것의 근거도 되지 않는다.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

대상이 분명한 변경을 할 때마다 이 세 가지를 실행하고 직전 결과와 비교한다. 쓸모 있는 성과는 리소스로 가는 기록 가능한 경로이지, 마스크가 사무실 LAN을 닮은 어댑터가 아니다.

그다음 이 마스크가 실제로 무엇을 뜻하는지 적어 둔다. 다음 사람도 같은 대화상자를 열고 같은 결론에 이르기 때문이다. 프로필 메모에 한 줄, 터널은 지점 간이고 원격 서브넷은 경로로 전달된다고 적어 두면 다음번에는 조사 자체를 아낄 수 있다.