왜 IKEv2 + EAP-TTLS + FreeRADIUS + TOTP인가 — 탈락한 대안들까지 (Part 1)
개요
- 최종 선택: IKEv2 + PSK + EAP-TTLS(inner PAP) + FreeRADIUS + TOTP
- PSK를 고른 이유는 보안이 더 좋아서가 아니라 EMS 없이 150명에게 인증서를 배포·갱신할 방법이 없어서다.
- inner method가 PAP인 이유: TTLS 터널 내부라 평문이 보호되고,
비밀번호+OTP 문자열을 스크립트로 검증하는 방식과 유일하게 깔끔하게 맞는다. - 탈락: 인증서 기반 EAP-TLS, ZTNA, VDI 전환. 이유는 전부 "기술이 나빠서"가 아니라 "이 조건에서 운영 불가"
이 글은 누구를 위한 글인가
읽고 나면 본인 조건에서 무엇이 탈락하는지를 먼저 판단할 수 있게 된다. 이 판단이 먼저 끝나야 설정 작업이 헛돌지 않는다.
설계를 시작하기 전에 기준 4개를 문서에 적고 순위를 고정했다. 이걸 안 하면 매력적인 신기술 쪽으로 계속 끌려간다.
- 추가 라이선스 비용 0원 — 협상 불가 조건
- 다양한 외부망에서 붙을 것 — 정부 부처 기자실, 호텔, 테더링 포함
- 1인 운영 가능 — 장애 시 혼자 30분 내 원인 절반은 좁힐 수 있는 구조
- 2FA 유지 — 기존 수준에서 후퇴하지 않기
3번이 실질적으로 가장 강한 필터였다. 기술적으로 더 우수한 구성이 여러 개 있었지만, 대부분 3번에서 걸렸다.
후보 비교
| 방식 | 라이선스 | 외부망 통과 | 1인 운영 | 판정 |
| IPsec IKEv2 + PSK + EAP + RADIUS | 0원 | UDP/TCP 선택 가능 | 구성요소 3개 | 채택 |
| IPsec IKEv2 + EAP-TLS (인증서) | 0원 | 동일 | 인증서 수명주기 관리 필요 | 탈락 |
| ZTNA (EMS 기반) | EMS 라이선스 | 양호 | EMS 운영 추가 | 탈락 |
| VDI 전환 (원격 데스크톱 방식) | 별도 라이선스 | 양호 | 신규 플랫폼 도입 | 탈락 |
| SSL VPN 유지 | 0원 | 양호 | 현행 유지 | 불가능 (7.6.3에서 제거) |
EAP-TLS를 탈락시킨 이유
기술적으로는 이게 더 낫다. 비밀번호가 오가지 않고, 피싱 저항성도 높다.
문제는 150장의 클라이언트 인증서를 발급하고, 배포하고, 1~2년 뒤 갱신하고, 퇴사자 인증서를 폐기하는 일이다.
EMS가 있으면 이게 자동화되지만 우리에겐 없다.
수동으로 하면 그 자체가 상시 업무가 되고, 갱신 시점이 몰리는 날에는 1인 담당자가 감당할 수 없다.
그리고 더 현실적인 문제: 인증서 파일을 사용자에게 전달하는 과정 자체가 보안 사고 위험이다.
메일로 pfx를 보내고 비밀번호를 카카오톡으로 보내는 식이 되면, EAP-TLS의 이점 대부분이 사라진다.
그래서 기준 3번에서 탈락시켰다. 아쉬움은 있고, Part 12에서 다시 언급한다.
VDI를 탈락시킨 이유
"VPN을 없애고 원격 데스크톱으로 가자"는 안도 검토했다. 세 가지에서 걸렸다.
- 라이선스: 0원 조건과 정면 충돌
- 구축 범위: 1인이 감당할 신규 플랫폼이 아니다
- 사용 패턴 부적합: 기자 업무는 회선 품질이 들쭉날쭉한 환경에서 로컬 파일과 사내 시스템을 오가는 형태다.
세션 끊김에 민감한 원격 데스크톱은 여기서 체감 품질이 나쁘다
여기에 하나 더. 원격접속 게이트웨이 계열 제품군은 최근 몇 년간 실제 악용 사례가 반복적으로 나왔다. 어떤 제품이든 취약점은 나오지만, 패치 적용을 24시간 안에 해야 하는 장비를 1인 담당자가 하나 더 늘리는 것의 실제 비용을 계산하니 답이 나왔다.
PSK + EAP 조합의 실체
여기서 오해가 흔하다. "PSK를 쓰면 공유 비밀번호 하나로 다 들어오는 거 아닌가?"
아니다. 이 구성에서 PSK는 게이트웨이 식별용이고, 사용자 인증은 전부 EAP를 통해 RADIUS로 간다.
클라이언트 FortiGate FreeRADIUS
| | |
|--- IKE_SA_INIT --------->| |
|<-- IKE_SA_INIT ----------| |
|--- IKE_AUTH (PSK) ------>| 게이트웨이 식별 |
|<-- EAP Identity Request -| |
|--- EAP Identity -------->|--- Access-Request ------->|
|<-- EAP-TTLS 터널 협상 -->|<-- Access-Challenge ------|
|--- (터널 내부) ID+PW+OTP >|--- PAP 검증 ------------->| 비밀번호 + TOTP 검증
|<-- EAP Success ----------|<-- Access-Accept ---------|
| | (Framed-IP-Address 등) |즉 PSK가 유출되어도 사용자 계정과 OTP 없이는 들어올 수 없다. 반대로 말하면 PSK는 "비밀"이라기보다 "설정값"에 가깝다.
이 점을 이해하고 나면 프로파일 배포 설계가 훨씬 편해진다. (Part 4)
inner method를 PAP으로 고른 이유
EAP-TTLS는 TLS 터널을 먼저 세우고 그 안에서 실제 인증을 한다. 안쪽에 쓸 방식으로 PAP, CHAP, MSCHAPv2 등이 있다.
PAP을 골랐다. 이유는 하나다.
TOTP를 검증하려면 서버가 사용자가 입력한 문자열 원문을 봐야 한다.
우리 방식은 사용자가 비밀번호 뒤에 6자리 OTP를 붙여 입력하고(mypassword123456), 서버가 뒤 6자리를 떼어 TOTP 검증하고 앞부분을 비밀번호로 검증하는 구조다. MSCHAPv2 같은 챌린지-리스폰스 방식은 서버에 원문이 도달하지 않으므로 이 분리가 불가능하다.
PAP은 평문이라 위험하게 들리지만, 이미 TTLS의 TLS 터널 안에 있다.
터널 밖에서 관측되는 것은 암호화된 EAP 페이로드뿐이다. 무선 랜에서 벌거벗은 PAP을 쓰는 것과는 완전히 다른 상황이다.
왜 굳이 FreeRADIUS인가
FortiGate에도 로컬 사용자 DB가 있고, FortiToken도 있다. 그런데 FreeRADIUS를 세웠다.
- FortiToken은 수량 라이선스다. 무료 제공분을 넘으면 비용이 발생하고, 150명은 넘는다.
- 인증 로직을 내 손에 두고 싶었다. 비밀번호+OTP 결합 검증, 그룹별 IP 할당, 계정별 예외 처리 같은 걸 스크립트로 다룰 수 있다.
- 장비 교체와 무관하게 남는다. 방화벽을 바꿔도 인증 계층은 그대로다.
대가도 있다. 서버 하나가 늘고, 그 서버는 초기 구성에서 단일 장애점이 된다. 이건 정직하게 부채로 남겼고 Part 12에서 다룬다.
최종 구성도
인터넷
|
[ 203.0.113.10 : port1 ]
|
+---------------------------------+
| FortiGate 201F (A-P HA) |
| - IKEv2 dialup, PSK + EAP |
| - transport: UDP (기본) |
| - authusrgrp → RADIUS |
+---------------------------------+
| |
[ 10.10.60.0/24 ] [ 10.10.20.10 ]
VPN 클라이언트 풀 FreeRADIUS 3.0.20
- EAP-TTLS / PAP
- TOTP 검증 스크립트
- rlm_ippool (그룹별 IP)이 결정에서 배운 것
- 제약 조건을 먼저 순위 매겨 문서에 박아두면 후보가 스스로 탈락한다.
이 작업을 안 하면 "이게 더 좋아 보이는데" 사이를 계속 왕복한다. - 기술 선택에서 진짜 비용은 도입이 아니라 1년 뒤의 운영이다. 인증서 배포는 하루면 되지만 인증서 갱신은 영원히 돌아온다.
- "이론적으로 더 안전한 방식"이 배포 과정에서 무너지면 실제로는 더 위험해진다. EAP-TLS 탈락 판단의 핵심이 이거였다.
다음 편에서는
Part 2에서 FreeRADIUS 3.0.20에 EAP-TTLS와 TOTP를 붙인다.
sites-enabled 디렉터리 하나 때문에 며칠을 태운 이야기도 여기에 나온다.