RRAS DHCP: 새 주소인가, 아니면 구성 옵션일 뿐인가?

캡처의 DHCPACK를 VPN 클라이언트가 DHCP에서 주소를 받았다는 증거로 읽는 것은 실수다. 보통 그것은 어느 DHCP 메시지에 응답이 있었다는 것만 증명한다. Windows RRAS는 자체 정적 풀에서 세션 주소를 내줄 수 있고, 그동안에도 DHCP는 연결된 클라이언트에 옵션을 공급한다. 두 작업 중 무엇이 진행 중이었는지는 요청 유형이 알려 준다.

같은 메시지 유형을 공유하는 두 작업

DHCP는 두 가지 별개의 일을 하고, 그 둘은 메시지 유형을 공유한다. 하나는 주소와 임대를 할당하는 것이다. 다른 하나는 이미 주소가 있는 호스트에 구성을 전달하는 것이며, RFC 2131은 이를 DHCPINFORM이라고 부른다. 두 번째 경우의 응답은 옵션을 담고 임대 시간은 담지 않는다.

따라서 ACK는 응답의 증거이지 할당의 증거가 아니다. 어떤 질문이 있었는지는 그 앞의 메시지가 결정한다. 먼저 요청 줄을 읽으면 나머지 추적은 대개 스스로 설명된다.

RRAS는 주소를 어디서 얻는가

RRAS는 구성된 IPv4 할당 방법, 즉 DHCP 서버나 정적 주소 풀을 통해 VPN 주소 결정을 소유한다. 풀이 정적이면 풀이 곧 할당자이며, 별도 DHCP 서버의 예약은 그 세션에서 아무 발언권이 없다. 두 메커니즘은 한쪽이 다른 쪽을 제어하지 않은 채 같은 네트워크에서 공존할 수 있다.

Get-Command -Module RemoteAccess *IPAddress*

주소를 디버깅하기 전에 실제 적용 중인 할당 방법을 확인하라. 정적 풀이라면 DHCP 범위는 볼 곳이 아니다. 위 명령은 실행 중인 버전에서 사용할 수 있는 cmdlet을 나열하며, 설정을 찾는 데는 그것으로 충분하다.

사용자 클래스가 증명할 수 있는 것과 없는 것

DHCP 사용자 클래스는 클라이언트가 보내는 문자열이며 인증된 그룹 구성원 자격이 아니다. 클라이언트가 하나를 보내고 서버가 그것에 정책을 맞추더라도, 그 레이블은 문자열이 도착했다는 것만 증명한다. RFC 3004는 이 옵션이 클래스에 대한 권리를 인증하지 않는다고 분명히 말한다.

VPN 사용자 이름, 보안 그룹 식별자, 노트북의 Ethernet 주소가 그 요청에 쓸 만한 형태로 나타나리라고 기대하지 마라. 그것들은 인증과 디렉터리의 사실이며, DHCP 요청은 둘 다 담지 않는다. 요구 사항이 권한 있는 사람을 구별하는 것이라면 신원이 실제로 존재하는 VPN 정책에서 강제하라. 그 분리가 두 시스템을 독립적으로 유지하는 이유다.

ACK가 아니라 증거를 비교하라

패킷 하나를 읽는 대신 증거 사슬을 세워라. 세션이 받은 주소, 요청의 메시지 유형과 필드, 서버가 돌려준 옵션, 그리고 그 뒤 클라이언트의 실효 구성을 기록하라. 각 고리는 서로 다른 질문에 답하며, 빠진 고리가 바로 실제 결함이 자리하는 곳이다.

Get-DhcpServerv4OptionValue -ScopeId 10.90.0.0

주소가 RRAS 풀에서 왔다면 DHCP 예약은 아무것도 설명하지 못한다. 옵션이 도착했는데 클라이언트가 무시했다면 서버는 할 일을 했고 다음 정류장은 클라이언트 구성이다. 이 두 결과를 명시적으로 비교하면 ACK는 더 이상 모호하지 않다. 할당 방법마다 하나씩, 두 개의 추적이 어떤 문서보다 빠르게 논쟁을 정리한다.