NPS 그룹 정책은 VPN 리소스 적용이 아닙니다

두 그룹, 두 개의 액세스 프로필, 하나의 VPN 게이트웨이가 있고 결국 두 그룹 모두 같은 서버에 도달합니다. 흔한 원인은 깨진 정책이 아니라 설계의 빠진 후반부입니다: NPS는 누가 세션을 설정할 수 있는지 결정하고, 그 세션이 무엇에 도달할 수 있는지는 다른 무언가가 결정해야 합니다. 전반부만 존재하면 인증하는 모든 사람에게 권한 부여가 성공합니다. 정책은 제 역할을 하고 있고, 설계는 여전히 불완전합니다.

그룹과 일치하는 네트워크 정책은 허용에 관한 증거입니다. 패킷에 관한 증거는 아니며, 이 두 진술 사이의 간극이 바로 이 작업의 대부분이 일어나는 곳입니다.

세션을 실제로 허용한 정책을 찾으십시오

NPS는 정렬된 네트워크 정책을 평가하며, 조건이 일치하는 첫 번째 활성화된 규칙이 이깁니다. 조건에는 사용자 또는 컴퓨터 그룹 구성원 자격, 연결 유형, 시간, 장치 상태가 포함될 수 있습니다. 따라서 목록에서 더 앞에 있는 광범위한 정책은 아래쪽의 더 좁은 규칙이 검토되기도 전에 연결을 허용합니다. 순서는 인터페이스의 세부 사항이 아니라 정책 그 자체입니다.

목록을 순서대로 읽고 일치한 항목을 식별한 다음, 그것이 반환한 설정을 기록하십시오. 편집기의 그룹 이름은 결과가 아니며, 결과는 서버가 받은 권한 부여입니다. 배포에서 둘 다 사용하는 곳에서는, 터널을 열 수 있는 계정이 자동으로 모든 내부 서비스에 도달해야 하는 계정은 아니기 때문에, 사용자 권한 부여와 장치 권한 부여를 분리하십시오.

RADIUS 응답은 지시이며 필터가 아닙니다

Filter-Id 특성은 필터 목록의 이름을 전달합니다. 모든 수신자가 이해하는 이식 가능한 패킷 필터 규칙 집합을 보내는 것이 아니며, 게이트웨이가 정의한 적 없는 이름을 보내면 아무것도 적용되지 않습니다. 같은 주의가 VLAN 특성에도 적용됩니다: 터널 세션을 VLAN에 할당하는 것 자체가 해당 사용자에 대한 라우팅된 액세스 규칙은 아닙니다.

여기서 NPS 쪽에서 완전해 보이는 설계가 조용히 아무것도 하지 않습니다. 표준 특성 이름이 표준 동작을 의미한다고 가정하는 대신, 어떤 권한 부여 특성이 지원되는지와 수신자가 각각을 어떻게 처리하는지를 게이트웨이 공급업체 문서로 확인하십시오.

적용을 트래픽이 지나가는 곳에 두십시오

사용자의 패킷을 처리하는 게이트웨이는 세션별 필터를 적용하거나, 그룹을 게이트웨이 정책에 매핑하거나, 방화벽이 다르게 처리하는 분리된 풀에서 세션에 주소를 줄 수 있습니다. 이들 중 어느 것이든 동작할 수 있으며, 실패하는 방식은 서로 다릅니다. 그 정책을 작성하기 전에 게이트웨이가 어떤 메커니즘을 지원하는지 확인하십시오. 그런 다음 침묵이 기본값이므로, 그 메커니즘이 없을 때 세션에 무슨 일이 일어나는지 기록하십시오.

의도한 권한을 네 부분으로 설명하십시오: 소스 ID 또는 그룹, 대상, 프로토콜, 포트입니다. 사용자가 실제로 필요로 하는 종속성, 예를 들어 DNS 또는 인증 서비스를 추가하지 않으면, 제한이 아무도 테스트할 생각을 하지 못한 로그인 흐름을 깨뜨립니다. 규칙은 실제로 필터링하는 인터페이스에 대해 작성하고, 편집기에서 우연히 열려 있는 인터페이스에 대해 작성하지 마십시오.

주소 변환도 고려하십시오. 하위 방화벽이 터널 사용자마다 하나의 변환된 소스 주소를 본다면, 그 주소만으로 개인을 구별할 수 없으며, 구별할 수 있는 것처럼 작성된 규칙은 쓸모없거나 너무 광범위할 것입니다.

클라이언트 프로필은 신뢰할 수 없는 쪽에 있습니다

관리되는 VPN 프로필은 경로, 분할 터널 규칙 또는 애플리케이션 필터를 푸시할 수 있으며, 그것들이 예의 바른 장치의 동작을 형성합니다. 그것들은 서비스에 대한 보호가 아닙니다: 클라이언트가 바로 제한하려는 당사자이기 때문입니다. 프로필에서 경로를 제거하는 것도 권한 부여가 아닙니다: 클라이언트가 같은 대상에 다른 경로를 가질 수 있기 때문입니다.

클라이언트 설정은 편의로, 게이트웨이 설정은 통제로 취급하십시오. 둘이 불일치할 때는 패킷을 보는 쪽이 게이트웨이이기 때문에 게이트웨이가 옳습니다.

두 계정으로 허용한 다음 순서대로 추적하십시오

의도한 권한이 다른 일반 테스트 계정 두 개를 만들고 새 세션을 설정한 뒤 각각의 유효 게이트웨이 정책을 확인하십시오. 그런 다음 무해한 허용 작업 하나와 명시적으로 거부된 리소스 하나를 테스트하십시오. ping 실패만으로는, ICMP가 필터링되어도 그 뒤의 TCP 서비스는 흔쾌히 응답할 수 있기 때문에, 거의 아무것도 증명하지 못합니다.

두 계정이 여전히 광범위한 액세스를 얻는다면 정해진 순서로 추적하십시오: 어떤 정책이 일치했는지, 응답이 어떤 권한 부여를 담았는지, 게이트웨이가 그것으로 무엇을 했는지입니다. 수신자가 그것들을 구현한다고 확인하기 전에 NPS 특성을 더 추가하는 것이 작은 권한 부여 문제를 결과 없는 변경 창으로 만드는 길입니다.