왜 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개를 문서에 적고 순위를 고정했다. 이걸 안 하면 매력적인 신기술 쪽으로 계속 끌려간다.

1. 추가 라이선스 비용 0원 — 협상 불가 조건
2. 다양한 외부망에서 붙을 것 — 정부 부처 기자실, 호텔, 테더링 포함
3. 1인 운영 가능 — 장애 시 혼자 30분 내 원인 절반은 좁힐 수 있는 구조
4. 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 디렉터리 하나 때문에 며칠을 태운 이야기도 여기에 나온다.