안정적인 VPN 클라이언트 주소를 위한 RADIUS Framed-IP-Address

RADIUS는 특정 사용자에 대한 주소로 응답할 수 있지만, 터널이 실제로 그 주소를 받는지는 게이트웨이에 달려 있습니다. 안정적인 주소 계획의 대부분은 반환된 주소와 적용된 주소 사이의 이 간극에서 실패합니다. 테스트 응답에 속성이 있다는 것은 서버가 그것을 보낼 수 있음을 증명할 뿐, 원격 액세스 서비스가 그것을 적용한다는 것을 증명하지는 않습니다. 아래의 절차는 주소가 방화벽 규칙에 들어가기 전에 두 부분을 모두 확인합니다.

주소를 어느 계층이 소유하는지 결정하십시오

원격 액세스 게이트웨이에는 보통 로컬 풀이 있으며, 많은 게이트웨이가 인증 응답에서 주소를 받아들일 수도 있습니다. 어느 쪽이 이기는지는 플랫폼, 프로토콜 및 서비스 구성에 따라 다르므로 사용 중인 정확한 릴리스의 우선순위 규칙을 읽으십시오. 로컬 풀이 우선인 경우 속성은 장식일 뿐이며 클라이언트는 결국 임의의 주소에 머뭅니다. 반환된 값이 풀 범위 안에 있어야 하는지 아니면 밖에 있어도 되는지 결정하여 기록하십시오.

RFC 2865는 Framed-IP-Address을 사용자에게 구성해야 할 주소로 정의하며, 특정 게이트웨이가 그것을 존중할 의향이 있는지에 대해서는 아무 말도 하지 않습니다. 우선순위에 대한 권위는 속성의 정의가 아니라 공급업체 문서입니다.

테스트 요청을 보내고 응답을 읽으십시오

먼저 서버를 단독으로 테스트하여 누락된 속성이 게이트웨이 문제로 오해되지 않게 하십시오. radtest은 하나의 Access-Request를 보내고 돌아오는 속성을 인쇄합니다.

radtest alice 'S3cret' 127.0.0.1 0 testing123

Access-Accept에서 Framed-IP-Address을 찾아 값이 의도한 것이며 대체 규칙에서 온 풀 주소가 아님을 확인하십시오. 속성이 없으면 사용자 항목이나 권한 부여 정책이 일치하지 않으며, 게이트웨이 조정으로는 서버가 한 번도 보내지 않은 것을 제공할 수 없습니다. 응답을 특정 규칙으로 추적하기 어렵다면 서버가 디버그 모드로 실행되는 동안 요청을 반복하십시오. 위의 자리 표시자는 자격 증명이 아니므로 공유 비밀을 셸 기록과 티켓에 남기지 마십시오.

게이트웨이가 값을 존중했는지 확인하십시오

올바른 응답은 계약의 절반에 불과합니다. 터널 인터페이스에 나타나는 주소가 중요한 관찰이며, 게이트웨이 구성에서 추론하는 대신 클라이언트에서 읽습니다.

ip -4 addr show tun0

그 주소를 Access-Accept의 속성과 비교하십시오. 불일치는 게이트웨이가 값을 무시하거나 다시 썼다는 뜻이며, 첫 번째 섹션의 우선순위 질문이 다시 열립니다. 첫 시도에서만 작동하는 예약은 보통 오래된 세션이나 이전 연결이 아직 보유한 임대를 가리키므로 한 번 더 다시 연결하십시오. 게이트웨이 릴리스와 프로토콜을 결과 옆에 기록하여 다음 사람이 동작이 버전별인지 판단할 수 있게 하십시오.

동시성과 철회를 계획하십시오

게이트웨이가 로그인 외의 무언가로 세션을 구분하지 않는 한, 하나의 사용자 이름을 두 기기에서 하나의 주소로 매핑할 수는 없습니다. 매핑이 개인, 등록된 기기 또는 인증서 ID에 속하는지 결정하고 그 선택을 정책 저장소에 명시하십시오. 여기서의 충돌은 나중에 라우팅 오류로 다시 나타나므로 두 번째 동시 클라이언트를 테스트하고 할당된 두 주소를 비교하십시오. 이전 방화벽 규칙이 아직 그 주소를 참조하는 동안 재할당된 주소는 권한 부여 버그가 되므로 같은 주의가 철회 계획에도 필요합니다.

안정적인 주소 지정은 규칙과 로그를 단순하게 만들지만 패킷을 누가 생성했는지는 결코 증명하지 않습니다. 그 주소가 나중에 다른 세션으로 옮겨갈 때 인증과 목적지 권한 부여는 여전히 중요합니다.