Captive Portal

Captive Portal

Captive Portal은 네트워크에 접속한 사용자를 인증 및 동의 페이지로 강제 유도한 뒤, 조건을 충족해야 실제 인터넷 접근을 허용하는 웹 기반 접근 제어 방식이다. 카페, 호텔, 공항의 게스트 Wi-Fi에 연결했을 때 자동으로 뜨는 로그인/약관 동의 화면이 대표적이다.

802.1X나 MAB가 접속 시점에 단말 차원에서 인증한다면, Captive Portal은 사용자가 브라우저에서 직접 로그인하거나 동의하게 한다. 그래서 별도 클라이언트나 사전 등록이 없어도 되는 게스트와 방문자 접속에 주로 쓰인다.

동작 흐름

미인증 단말을 제한하고, HTTP 요청을 가로채 포털 페이지로 리다이렉트한다.

[단말]  --웹 접속 시도-->  [게이트웨이/컨트롤러]  --포털로 리다이렉트-->  [로그인/동의 페이지]
        (미인증 상태)       HTTP 가로채기                          인증 후 접근 허용

1. 단말이 Wi-Fi에 연결되면 DHCP로 IP는 받지만, 게이트웨이는 이 단말을 미인증 상태로 두고 외부 트래픽을 차단한다.
2. 단말은 연결 직후 인터넷이 실제로 되는지 확인하려 스스로 특정 URL을 조회하여 기대한 응답이 오는지 확인한다.
3. 게이트웨이/무선 컨트롤러가 이 요청을 가로채, 목적지 대신 포털 주소로 이동하라는 응답(HTTP 302) 을 돌려준다. 사용자가 직접 브라우저로 웹사이트에 접속한 경우에도 같은 응답을 받는다.
4. 단말은 기대한 응답 대신 302가 온 것을 보고 목적지에 도달하지 못했다고 판단한다. 운영체제는 "로그인이 필요한 네트워크"로 인식하고, 포털 화면을 자동으로 띄운다.
5. 사용자가 페이지에서 로그인하거나 약관에 동의한다.
6. 인증이 확인되면 게이트웨이가 해당 단말의 MAC을 허용 목록에 올리고, 이후 트래픽을 통과시킨다.

포털 감지에 쓰이는 요청은 평문 HTTP다. HTTPS 요청은 게이트웨이가 응답을 바꿔치기해도 인증서 검증에 걸려 그대로 실패하기 때문에, 포털 페이지를 사용자에게 보여주는 통로가 되지 못한다. OS는 HTTPS 프로브도 함께 보내지만 이는 인터넷 정상 여부를 확인하는 용도이고, 포털이 있는지는 HTTP 응답으로 판정한다.

인증 방식

포털 페이지에서 요구하는 조건은 운영 목적에 따라 다르다.

• 약관 동의만(Click-through) — 로그인 없이 동의 버튼만으로 허용. 공공 Wi-Fi에서 흔하다.
• 계정 로그인 — 이미 발급된 계정으로 인증. 직원 개인 단말(BYOD)은 사번 계정을 쓰고, 방문자는 프런트에서 발급한 임시 계정을 받는다. 공공 Wi-Fi에서는 소셜 로그인을 쓰기도 한다.
• 일회용 코드(Voucher/SMS/OTP) — 프런트에서 발급한 코드나 문자로 받은 코드를 입력. 방문자 임시 접속에 적합하다.
• 스폰서 승인(Sponsor Approval) — 방문자가 요청하면 담당 직원이 승인해야 접속을 여는 방식.

계정 로그인 방식은 뒷단에서 RADIUS 서버로 자격 증명을 검증하는 경우가 많아, 802.1X나 MAB와 같은 인증 인프라를 공유하기도 한다.

다른 인증 방식과의 비교

세 방식 모두 접근 제어(NAC)이지만 인증 계층과 대상이 다르다.

운영 시 고려사항

• 사전 인증 허용 대상 — 포털, DNS, 인증 서버로 가는 트래픽은 미인증 상태에서도 열려 있어야 로그인 페이지가 뜬다. 이 경로를 ACL로 명시적으로 허용한다.
• 게스트망 분리 — 게스트 트래픽은 내부망과 분리된 VLAN에 두고, 인증 후에도 내부 자원 접근은 차단한다.
• 세션 만료 정책 — 인증 유지 시간(재로그인 주기)을 정해 장기 무단 사용을 막는다. MAC 주소로 세션을 유지하는 방식은 위조 가능성도 함께 고려한다.
• HTTPS 리다이렉트 한계 — 최신 브라우저나 OS는 HTTPS 사용과 인증서 검증으로 강제 리다이렉트를 어렵게 만든다. OS의 Captive Portal 감지 기능에 맞춰 구성하는 것이 안정적이다.