RADIUS VLAN 응답이 VPN 사용자에게 아무 일도 하지 않는 이유

NPS 정책에 VLAN 속성을 추가하고 VPN 사용자가 연결해도 노트북은 여전히 기본 풀에 떨어집니다. RADIUS 서버는 요청한 값을 그대로 반환하므로 장애가 캐시 문제처럼 보입니다. 보통은 아닙니다. Access-Accept는 권한 부여 힌트를 운반하며, 이를 받은 네트워크 액세스 서버만이 하나를 네트워크 할당으로 바꿀 수 있습니다.

정책이 아니라 게이트웨이에서 시작하십시오

무엇이든 바꾸기 전에 클라이언트에서 안쪽으로 체인을 따라가십시오. 클라이언트는 게이트웨이에 세션을 요청하고, 게이트웨이는 RADIUS에 사용자가 세션을 받을 수 있는지 묻고, RADIUS는 결과와 속성 집합으로 응답합니다. 그런 다음 게이트웨이는 자기가 적용할 줄 아는 것을 적용합니다.

확인은 네 번째 단계에서 시작하므로 처음 세 단계는 정상으로 보입니다. 교환 과정의 어떤 것도 게이트웨이가 받은 속성을 구현하도록 강제하지 않습니다. 응답은 게이트웨이에 대한 요청이지 클라이언트에 관한 사실이 아닙니다.

스위치는 되고 VPN은 안 되는 일

802.1X 액세스 스위치는 포트가 있는 인증자이며, 동적 VLAN 할당은 그 포트 중 하나를 스위치가 이미 전달하는 VLAN으로 옮깁니다. RADIUS 터널 속성은 그 의도를 스위치가 이해하는 형식으로 설명합니다. 라우팅된 VPN은 터널을 종료하지 스위치 포트를 종료하지 않으며, 그 클라이언트는 보통 브로드캐스트 도메인의 구성원 자격 대신 주소와 경로를 받습니다. 옮길 포트가 없으므로 같은 속성이 작용할 대상이 없습니다.

이것은 벤더 버그가 아니라 모델 차이입니다. 일부 게이트웨이는 스크린샷에서 비슷해 보이는 자체 그룹 정책, 풀 선택 또는 필터 메커니즘을 추가합니다. 다른 게이트웨이는 그중 아무것도 구현하지 않으며 속성은 기록되고 무시됩니다. 스크린샷에 있는 모드가 아니라 실제로 활성화한 원격 액세스 모드의 설명서를 읽으십시오.

서버가 실제로 보낸 응답을 읽으십시오

정책 편집기가 표시하는 것이 아니라 RADIUS가 반환한 것을 확인하십시오. 같은 사용자 이름과 알려진 암호로 테스트 요청을 하면 응답 속성이 읽을 수 있는 형태로 출력되어 한 단계로 문제가 해결됩니다.

radtest alice secret 10.0.0.10 0 testing123

해당 응답에 VLAN 속성이 없으면 먼저 정책 일치를 수정하십시오. 속성이 있으면 서버는 자기 몫을 다한 것이고 격차는 하류에 있습니다.

먼저 세션 정책을, 다음으로 도달성을 증명하십시오

이제 게이트웨이가 만든 세션을 보십시오. 활성 세션 목록은 풀, 할당된 주소, 게이트웨이가 연결한 그룹 정책을 보여 주며, 적용에 중요한 유일한 증거입니다. 정책이 의도한 것과 비교하지 말고 사용자가 도달할 수 있는 것과 비교하십시오.

swanctl --list-sas

올바른 풀의 주소로는 격리가 증명되지 않으므로 클라이언트에서 허용된 리소스 하나와 거부된 리소스 하나를 시험하십시오. 게이트웨이에 원하는 할당을 위한 메커니즘이 없다면 속성 사본을 더 만들어도 생기지 않습니다. 예상 풀의 주소는 다른 모든 풀에 대한 전체 액세스와 공존할 수 있습니다. 지원되는 정책 메커니즘을 선택하거나 의도적으로 네트워크 설계를 바꾸십시오.