NPS RADIUS 클라이언트로 어떤 주소를 등록합니까?

인증을 Windows NPS에 넘기는 VPN 게이트웨이는 사용자 정책이 돌기 전에 NPS 쪽에 게이트웨이용 RADIUS 클라이언트 항목이라는 객체 하나가 필요합니다. 실패하는 시도의 대부분은 잘못된 주소를 등록하는데, 중요한 주소는 게이트웨이가 백엔드 경로에서 쓰는 주소이고 직원이 VPN 앱에 입력하는 호스트 이름이 아니기 때문입니다. 이 값이 틀리면 NPS는 요청을 조용히 버리며, 클라이언트 쪽에서는 잘못된 비밀번호처럼 보입니다. 어떤 주소를 필드에 넣을지는 세 가지 조건이 정하므로 콘솔을 열기 전에 정리하십시오.

게이트웨이를 등록하고, 노트북이나 풀을 등록하지 않는다

RADIUS 클라이언트 객체는 인증 요청을 보내는 네트워크 액세스 장치를 나타냅니다. 그것은 VPN 게이트웨이이며, 클라이언트를 실행하는 모든 노트북도, 터널 안에서 할당되는 주소 범위도 아닙니다.

그 터널 주소는 RADIUS 요청의 출발지로 나타난 적이 없으며, 요청은 게이트웨이 자체의 네트워크 경로로 이동합니다. 클라이언트 풀 항목을 등록하면 절대 일치할 수 없는 정책이 만들어지고, 실제 요청은 NPS가 들어본 적 없는 주소에서 도착합니다. 같은 혼동 때문에 사람들은 직원마다의 집 IP를 추가하는데, 이는 유지할 수도 없고 틀린 일입니다.

입력하는 주소는 세 가지 조건이 정한다

먼저, 게이트웨이가 NPS 쪽으로 실제 사용하는 출발지 주소를 찾으십시오. 여러 인터페이스가 있는 게이트웨이는 종종 공용 VPN 리스너가 아니라 관리나 백엔드 인터페이스에서 보내므로, 실제로 나가는 주소를 확인해야 합니다. 둘째, 두 지점 사이에 NAT가 있으면 요청이 변환되고, NPS가 보는 변환된 주소가 등록할 값입니다. 셋째, 두 게이트웨이가 역할을 공유하면 요청 출발지마다 클라이언트 항목이 따로 필요하며, 주소 하나를 가진 객체 하나는 그중 하나만 덮습니다.

양끝을 맞춘 기록이 짝을 바르게 유지합니다. 아래 표는 설명을 위해 사설 주소를 쓰므로, 실제 경로가 쓰는 주소로 바꾸십시오.

추측하지 말고 출발지를 확인하십시오. 한 번의 시도 동안 NPS나 방화벽 로그를 보거나, NPS 호스트에서 sudo tcpdump -ni any udp port 1812 로 캡처하십시오. 그 캡처에 나온 주소가 클라이언트 항목에 대해 변호 가능한 유일한 답입니다. 게이트웨이에 가능한 출발지가 여럿이면 각각을 고유한 친숙한 이름으로 등록하십시오.

공유 암호는 게이트웨이와 NPS 사이의 값

공유 암호는 장치 관계를 인증합니다. 사용자 비밀번호가 아니며 직원에게 배포되지도, 클라이언트 프로필에 포함되지도 않습니다.

값 하나를 골라 두 곳에 입력하고, 게이트웨이 구성 백업이 있는 곳에 보관하십시오. 불일치가 생기면 NPS는 쓸모 있는 오류 없이 요청을 버리며, 게이트웨이 로그에서는 연결할 수 없는 서버와 구별되지 않습니다. 유지보수 시간대에 교체하고 같은 변경에서 양쪽 끝을 갱신하십시오.

허용된 요청 하나로 확인한다

통제된 계정을 쓰고 양쪽에서 시도 하나를 맞춰 보십시오. 게이트웨이에서는 요청이 의도한 서버로 나갔는지, NPS에서는 등록된 클라이언트에서 도착해 예상한 연결 요청 정책과 일치했는지 확인합니다. 시간 초과와 거부는 다른 의미이며, 둘 다 자격 증명 문제로 다루면 다음 한 시간을 낭비합니다. 이어서 유효하지만 자격이 없는 계정과 잘못된 비밀번호도 시험해야 하는데, 모든 것을 받아들이는 정책은 첫 시험도 통과하기 때문입니다.

마지막으로, 반환된 권한 부여를 게이트웨이가 어떻게 처리하는지 확인하십시오. RADIUS 클라이언트 등록은 장치의 참여만 허용하며, 그 결과 생기는 각 세션에 LAN 접근을 주지는 않습니다.

진단 출력은 범위를 좁히고, 공유 암호, 사용자 비밀번호, 전체 패킷 페이로드를 지원 티켓에 넣지 마십시오. 설계상 NPS 서버가 디렉터리 특성을 읽어야 한다면 그 권한은 클라이언트 등록과 별개의 관리 작업이며, 없을 때는 다른 방식으로 실패합니다.