VPN 게이트웨이를 통한 EAP: 누가 메서드를 종료하는가

헬프데스크 티켓은 실패한 VPN 로그인과 더 강한 메서드를 요구하는 RADIUS 정책을 같은 문제인 것처럼 적지만, 그렇지 않다. 게이트웨이는 자격 증명을 받아 전달하거나, 클라이언트와 인증 서버 사이에서 EAP 대화를 운반한다. 둘 중 무엇이 일어나는지가 서버 측 변경으로 무엇이든 고칠 수 있는지를 결정한다. 서버 그룹을 편집하기 전에 그 교환을 읽어 보라.

로그에서 같아 보이는 두 인증 경로

첫 번째 경로에서 VPN 게이트웨이는 사용자 이름과 비밀번호를 모아 비밀번호 속성이 붙은 RADIUS Access-Request를 보낸다. 인증 서버는 그것을 자기 자격 증명 저장소와 비교해 수락 또는 거부로 답한다. 클라이언트는 EAP 메서드를 전혀 실행하지 않는다. 아무도 요구하지 않았기 때문이다.

두 번째 경로에서는 클라이언트와 인증 서버가 EAP 메서드를 끝에서 끝까지 실행하고, 게이트웨이는 둘 사이에서 EAP-Message 속성을 전달한다. 게이트웨이는 여전히 바깥 RADIUS 대화를 종료하지만, 메서드의 논리는 양 끝단에 있다.

두 경로 모두 인증이 실패했다는 줄을 로그에 남긴다. 서버가 선호하는 EAP 메서드의 영향을 받는 것은 두 번째뿐이고, 게이트웨이가 비밀번호를 읽는 방식의 영향을 받는 것은 첫 번째뿐이다. 둘을 서로 바꿔 쓸 수 있다고 보는 것이, PEAP를 말할 생각이 없던 클라이언트 때문에 팀이 하루 종일 서버 그룹을 바꾸는 이유다.

메서드가 실제로 도는 곳

RFC 3579는 통과 방식을 정의한다. NAS는 EAP 패킷을 RADIUS 속성에 담아 나르며 EAP 유형마다 메서드 전용 코드가 필요하지 않다. 그래서 게이트웨이는 PEAP과 EAP-TLS를 둘 다 구현하지 않고도 지원할 수 있다.

비밀번호를 제출하는 게이트웨이는 PEAP을 나르지 않는다. 백엔드가 다른 클라이언트의 PEAP을 받아들인다 해도 마찬가지다. 서버 정책에서 PEAP을 켜도 한 번도 제안하지 않은 클라이언트에 메서드가 추가되지는 않는다.

PPP 인증 설정은 PPP 서비스에 속한다. 같은 AAA 서버를 쓰는 모든 IPsec이나 오래된 XAuth 경로를 조용히 다시 구성하지 않으므로, 한 액세스 유형에서 통하는 변경이 다른 쪽을 그대로 둘 수 있다.

NAS가 지원해야 할 것

통과는 요구 조건을 메서드 코드에서 전달자 지원으로 옮긴다. 게이트웨이는 자기 VPN 프로토콜로 EAP를 날라야 하고, 그 위의 RADIUS 클라이언트는 해당 크기의 EAP-Message 속성을 보내고 받을 수 있어야 한다.

IKEv2에서 EAP는 정의된 인증 흐름의 일부이며, 서버 신원과 신뢰 검사는 그 흐름에서 나온다. 802.1X 배포에서 빌려온 PEAP 라벨은 자동으로 옮겨지지 않는다. 그 주변의 협상이 다르기 때문이다.

클라이언트 쪽에도 요구 사항이 있다. 메서드에 맞게 구성되어야 하고, 메서드가 제시하는 서버 인증서를 신뢰해야 하며, 메서드가 쓸 수 있는 자격 증명이 있어야 한다. 클라이언트 인증서가 없는 인증서 기반 메서드는 RADIUS가 무엇인가를 보기 전에 실패한다. 이는 서버 정책이 아니라 프로비저닝 문제다.

정책을 바꾸기 전에 시도 하나를 읽어라

게이트웨이와 인증 서버에서 승인된 시도 하나를 캡처한다. RADIUS 요청에서 EAP-Message 속성을 찾는다. 그것이 있으면 통과 경로가 쓰이고 있다는 뜻이고, 없으면 자격 증명 교환을 가리킨다.

Linux 게이트웨이에서는 RADIUS 포트에서 캡처하면 선로에 어떤 속성이 있는지 보인다.

sudo tcpdump -ni any -X 'udp port 1812' -c 20

다음으로 거부 지점을 비교한다. RADIUS 패킷이 오기 전에 게이트웨이에서 실패하면 클라이언트와 게이트웨이가 메서드에 합의하지 못한 것이다. EAP 속성을 담은 RADIUS 거부는 양 끝단이 메서드를 실행했고 그중 하나가 결과를 거부했다는 뜻이다.

마이그레이션을 끝에서 끝까지 하나의 변경으로 계획하라

메서드를 바꾼다는 것은 클라이언트 구성, 게이트웨이의 전달자 지원, 서버의 메서드 정책, 자격 증명 저장소를 함께 바꾸는 것이다. 이 순서로 하고, 새 경로가 증명될 때까지 동작하는 경로를 유지하라. 서버 측만 바꾸는 것은 추측이며 보통 동작하던 클라이언트를 깨뜨린다. 그룹을 건드리기 전에 시험용 신원 하나에서 변경을 준비하라.

동작하는 조합을 기록하라. VPN 프로토콜, EAP 전달자, 상대 메서드, 서버 메서드, 자격 증명 유형, 서버 신원 확인이다.

관리용 로그인 AAA는 작업이 둘 다를 명시하지 않는 한 VPN 인증과 분리해 두라. 원격 액세스를 위한 변경이 그것을 종료하는 장비를 관리할 능력을 빼앗아서는 안 된다.