고정 VPN IP: RADIUS Framed-IP-Address 또는 풀 예약

VPN 클라이언트의 고정 내부 주소를 보관할 수 있는 곳은 세 곳이며, 그중 하나만 소유해야 합니다. RADIUS는 Access-Accept에서 주소를 돌려줄 수 있고, 게이트웨이는 계정에 대한 정적 매핑을 유지할 수 있으며, 클라이언트 어댑터는 수동으로 설정할 수 있습니다. 처음 두 가지는 정책이고 세 번째는 게이트웨이가 무시하거나 덮어쓸 수 있는 로컬 추측입니다. 처음 두 가지 중에서 고르는 것이 진짜 결정이며, 네트워크 액세스 서버가 실제로 무엇을 구현하는지에 달려 있습니다.

고정 주소가 있을 수 있는 세 곳

응답이 Framed-IP-Address를 담고 게이트웨이가 그 값을 세션에 적용할 때 RADIUS가 주소를 소유합니다. 관리자가 계정을 풀 안의 정적 주소로 매핑할 때 게이트웨이가 소유합니다. 클라이언트는 아무것도 소유하지 않습니다. 어댑터에 수동 주소가 표시되어도 서버가 협상 중에 내부 주소를 할당하며, 로컬 설정은 서버가 아무것도 보내지 않을 때만 의미가 있습니다. 세 가지 모두 동작하는 연결에서는 똑같아 보이므로 충돌이 늦게 드러납니다. 차이는 재연결, 두 번째 장치, 정책 변경 후에 나타납니다.

소유자가 둘이면 구성이 깨집니다. RADIUS 응답이 172.28.4.77을 할당하는데 게이트웨이가 172.28.4.90에 대한 정적 매핑을 보유하면, 벤더 코드가 먼저 확인하는 값을 따르고 진 쪽은 로그 한 줄 없이 버려집니다. 같은 계정이 두 번째 장치에서 중복 주소를 받고, 증상은 할당 충돌이 아니라 라우팅 장애처럼 읽힙니다. 두 번째 메커니즘을 추가하기 전에 소유자를 정하십시오.

클라이언트 측 옵션은 배제하기 위해서만 언급할 가치가 있습니다. 수동 어댑터 주소는 운영체제가 제시할 수 있는 선호일 뿐 예약이 아니며, 다른 세션이 같은 주소를 받는 것을 막을 수 없습니다.

RADIUS 응답이 약속할 수 있는 것과 없는 것

RFC 2865Framed-IP-Address를 사용자에게 구성할 IPv4 주소로 정의하며, 이는 Access-Accept에 속합니다. Access-Request의 같은 속성은 서버가 무시할 수 있는 힌트일 뿐이며, 클라이언트나 게이트웨이가 선호 주소를 제시할 때 중요합니다. 프로토콜에서 게이트웨이가 응답을 존중하도록 강제하는 것은 없습니다. 응답을 세션에 적용하는 주체가 네트워크 액세스 서버이기 때문입니다.

지원 여부는 프로토콜이 아니라 제품의 문제입니다. 일부 게이트웨이는 프레임 주소를 기본으로 적용하고, 일부는 그룹 수준 스위치를 켜야 하며, 일부는 속성을 받아들이고 원격 액세스 세션에는 절대 사용하지 않습니다. 마지막 경우가 위험합니다. 과금 기록에는 응답이 남는데 클라이언트는 풀 주소를 받기 때문입니다. 동작은 실제로 운용하는 게이트웨이 모델과 펌웨어에서 확인하십시오. 자매 제품 문서로는 부족합니다.

게이트웨이가 무시하는 응답은 한 번도 전송되지 않은 응답과 똑같아 보입니다. Access-Accept와 세션 주소를 나란히 읽는 것이 두 경우를 구분하는 유일한 방법입니다.

이미 라우팅하는 풀 안에서 주소를 예약하십시오

게이트웨이가 이미 라우팅하고 방화벽이 이미 신뢰하는 풀 서브넷에서 고정 주소를 고르십시오. 그 범위를 벗어난 주소는 정책 변경을 라우팅 프로젝트로 바꾸고, VPN은 올라오지만 그 뒤에서는 아무것도 응답할 수 없습니다. 주소별 액세스 규칙이 있다면 같은 변경에서 고정 주소도 추가하십시오.

두 번째 동시 세션이 어떻게 동작해야 하는지 정하십시오. 주소 하나를 두 번 할당하는 것은 장치 관리가 아니며, 그 결과 생기는 충돌은 두 세션 모두에서 간헐적 연결로 나타납니다. 장치마다 다른 ID를 발급하거나, 다른 할당을 발급하거나, 지원되는 검사로 동시성을 강제하십시오. 예를 들어 Simultaneous-Use 같은 검사를 쓰고, 이전 세션이 만료되기 전에 클라이언트가 다시 연결하지 않기를 바라는 방식은 피하십시오.

반환 경로도 할당만큼 주의를 기울일 가치가 있습니다. 게이트웨이에는 풀 방향 경로가, 내부 라우터에는 게이트웨이 방향 반환 경로가 필요하며, 고정 주소는 둘 다 물려받습니다. 클라이언트 하나만 동작하고 나머지가 모두 실패하면 보통 풀 경로는 있지만 예약 주소의 호스트 경로가 없다는 뜻입니다.

예약을 신뢰하기 전에 응답을 테스트하십시오

AAA 측과 세션 측을 따로 테스트하십시오. 실패 원인이 다르기 때문입니다. 로컬 radtest는 게이트웨이를 개입시키지 않고 서버가 계정에 대해 무엇을 반환하는지 보여주고, users 파일 항목은 서버가 무엇과 일치해야 하는지 보여줍니다. 그다음 클라이언트를 다시 연결하고 받은 주소를 응답의 속성과 비교하십시오.

Authenticated member: survey-tablet-17
Reply attribute:      Framed-IP-Address = 172.28.4.77

survey-tablet-17  Cleartext-Password := "REPLACE_ME"
                  Framed-IP-Address = 172.28.4.77

radtest survey-tablet-17 REPLACE_ME 127.0.0.1 0 testing123

속성이 없는 Access-Accept는 서버가 항목을 일치시키지 못했거나 그 사용자에게 속성이 적용되지 않았다는 뜻입니다. 속성이 있는 Access-Accept인데 클라이언트가 여전히 풀 주소를 받는다면 게이트웨이가 무시한 것입니다. Access-Reject는 자격 증명이나 그룹 정책으로 되돌리며, 이 결과들 중 어느 것도 클라이언트 어댑터를 편집해서 디버그해서는 안 됩니다.

재연결 후 그리고 다른 장치에서 두 번째 로그인 후에 검사를 반복하십시오. 첫 세션에서만 유지되는 예약은 일어날 때를 기다리는 풀 충돌이며, 감사 중에 찾는 것보다 지금 찾는 편이 쌉니다.

소유자를 하나 고르고 기록하십시오

게이트웨이가 프레임 주소를 안정적으로 적용한다면 RADIUS가 할당을 소유하게 하고 같은 계정의 정적 매핑을 모두 제거하십시오. 그렇지 않다면 게이트웨이가 소유하게 하고 응답에서 속성을 제거해 두 출처가 어긋날 수 없게 하십시오. 둘 다 거의 동작한다고 해서 둘 다 유지하면, 향후 세션이 잘못된 주소로, 뚜렷한 원인도 없이 발생합니다.

선택한 소유자, 예약한 주소, 그 주소가 나온 풀을 계정 기록에 적으십시오. 다음에 장치를 추가하는 사람은 둘 중 하나를 바꾸기 전에 주소가 AAA 정책인지 게이트웨이 매핑인지 확인할 수 있습니다.