Wi-Fi 포털 로그인과 VPN 로그인을 구분하세요
두 개의 서로 다른 시스템이 로그인을 요구합니다. 장소의 Wi-Fi와 VPN 게이트웨이입니다. 화면에서는 비슷해 보이지만 승인하는 대상은 전혀 다릅니다. 모든 창에서 물으세요. 이 비밀을 실제로 검증할 수 있는 사람은 누구인가?
공용 네트워크에서 유용한 것에 도달하기 전에 두 개의 서로 다른 시스템, 곧 장소의 Wi-Fi와 VPN 게이트웨이가 로그인을 요구합니다. 화면에서는 비슷해 보이지만 승인하는 대상은 전혀 다릅니다. 포털은 이 기기가 로컬 네트워크를 쓸 수 있는지 정하고, VPN은 다른 곳의 사설 네트워크에 도달할 수 있는지 정합니다. 저는 모든 창에서 ‘이 비밀을 실제로 검증할 수 있는 사람은 누구인가’라는 한 가지 질문으로 둘을 구분합니다. 다음은 호텔, 공항, 회의장에서 제가 쓰는 점검 목록이며, 입력을 멈추는 지점도 포함합니다.
각 로그인을 검사하는 서비스에 대응시키세요
호텔 연결 하나에도 네 가지 별도 검사가 관련될 수 있고, 입력을 요구하는 것은 일부뿐입니다. 먼저 순서대로 정리하되, 화면은 어느 단계에 속하는지 거의 알려주지 않습니다.
| Stage | Who checks it | What you give it | What it proves |
|---|---|---|---|
| Wi-Fi association | The access point | WPA2 passphrase or 802.1X credentials | That the device may join this SSID |
| Portal authorization | The venue or its portal provider | Room number, booking name, voucher, email or access code | That a guest may use local access |
| VPN authentication | Your gateway or identity provider | Client certificate, password, one-time code or SSO approval | That the user or device may enter the private network |
| Application login | Each internal service | That service's own account | That you may use that service |
사무실과 대학에서 흔한 802.1X 네트워크는 처음 두 줄을 흐리게 만듭니다. 거기서 Wi-Fi 로그인 자체가 RADIUS 서버에 대한 신원 검사이고, 클라이언트는 라우팅 신원을 제시할 수 있으며 실제 계정은 암호화된 교환 안에서 이동합니다. 그때도 검사는 네트워크 가입에 관한 것이고, 터널을 승인하지 않으며, VPN 게이트웨이는 그것을 무엇의 증거로도 받아들이지 않습니다.
순서는 라벨보다 중요합니다. 캡티브 포털이 존재하는 이유는 연결 후에 접근을 부여할 수 있기 때문이며, 그래서 장소는 페이지를 전문 업체에 맡길 수 있습니다. IETF의 RFC 8952는 포털을 별도 구성 요소로 취급하므로 낯선 도메인은 검증할 이유이지 그 자체로 사기 증거가 아닙니다. 도메인은 장소의 서면 지침과, 항목은 표와 대조하세요.
포털이 요구해도 되는 것을 확인하세요
포털 항목은 권리에 관한 것이지 신원에 관한 것이 아닙니다. 객실 번호, 예약 성, 바우처 코드, 키 케이스에 인쇄된 코드, 시간 제한 패스용 이메일, 약관 동의이며, 장소는 누가 객실을 예약했는지 이미 알고 있으므로, 다른 곳에서 당신으로 행동할 수 있게 하는 정보를 배우지 않고도 그 사실을 대조할 수 있습니다.
그 목록을 넘어서는 것은 잠시 멈출 가치가 있습니다. 핫스팟 페이지 도메인 비밀번호를 검증할 수 없습니다, 그리고 VPN의 일회용 코드, 복구 코드, 개인 키도 검증할 수 없고 그것을 원할 이유도 없습니다. 유일한 정당한 예외는 조직이 운영하는 네트워크로, 사무실 게스트 SSID나 회의 Wi-Fi는 업무에 이미 쓰는 ID 공급자로 당신을 보낼 수 있습니다. 그래도 로그인 호스트는 평소 것이고, 동의 화면은 당신의 테넌트를 표시하며, 흐름은 보이는 브라우저 탭에서 열리므로 구별됩니다.
마케팅 이메일은 별개로, 여행용 별칭이면 업무 신원을 넘기지 않고 항목을 채울 수 있습니다.
VPN 클라이언트가 자체 자격 증명을 원하는지 확인하세요
클라이언트는 프로필에 설정된 것만 요구하므로 기대되는 창은 프로필의 성질이고, 우연히 있는 네트워크의 성질이 아닙니다. 인증서 프로필은 보통 프로필 선택을 보여 준 뒤 조용히 연결합니다. 사용자 이름과 비밀번호 프로필은 둘 다 요구하며 종종 일회용 코드를 씁니다. SSO 프로필은 브라우저를 ID 공급자로 열고 토큰을 가지고 돌아옵니다. WireGuard는 또 다른데, 공개 키로 장치를 인증하고 사용자 로그인이 없으므로, WireGuard 사용자 이름과 비밀번호를 묻는 창은 WireGuard를 설명하지 않습니다.
여행 전에 프로필을 읽으세요. OpenVPN에서 auth-user-pass은 비밀번호 입력이 예상된다는 뜻이고, cert, key, pkcs12는 인증서가 일해야 한다는 뜻입니다. 평소 입력 없이 연결하는 프로필이 갑자기 비밀번호를 요구하면 인증서를 불러오지 못했거나 다른 방식으로 떨어진 프로필을 의심하세요. 입력 요구는 나타난 아무 창에나 업무 비밀번호를 입력하라는 초대가 아닙니다.
정당한 VPN 클라이언트는 객실 번호, 포털 바우처, Wi-Fi 암호 구문을 인증 입력으로 요구하지 않습니다. 그런 일이 생기면 클라이언트가 주장하는 것이 아니거나, 캡티브 포털이 터널 형성 전에 트래픽을 가로채고 당신이 로그인처럼 꾸민 HTML 페이지를 읽는 것입니다.
다음 다섯 조건에서 멈추세요
여기가 그럴듯한 우회로 진행하는 대신 제가 멈추는 지점입니다. 각각 확인은 싸고 틀리면 비쌉니다.
- 포털이나 SSO 페이지에 인증서 또는 TLS 경고가 나타납니다. 네트워크에 도달하려고 클릭으로 통과하지 마세요.
- 페이지는 VPN 게이트웨이나 ID 공급자만 검증할 수 있는 도메인 비밀번호, 일회용 코드, 복구 코드, 개인 키를 요구합니다.
- 도메인이 장소의 인쇄된 지침이나 조직이 자체 서비스용으로 문서화한 로그인 호스트와 일치하지 않습니다.
- 장치 관리에서 나오지 않은 루트 인증서, 구성 프로필 또는 보조 앱을 설치하라고 요구합니다.
- 직접 시작하지 않은 MFA 승인이 도착하거나 VPN 클라이언트가 호텔 자격 증명을 요구합니다.
대안은 다른 비밀번호가 아닙니다. 휴대폰 핫스팟을 쓰고, 프런트에서 정확한 네트워크 이름과 접속 방법을 물으며, 그 페이지를 네트워크 운영자나 IT 데스크에 신고하세요. 어느 것도 귀속시킬 수 없는 페이지에 자격 증명을 시험하라고 요구하지 않습니다.
실패를 올바른 단계에 귀속시키세요
두 단계를 통과한 뒤에도 실패는 일어나고, 오류를 순서대로 읽으면 보통 연결, 주소 할당, 포털 승인, 터널 설정, 그다음 내부 리소스 중 어느 단계인지 밝힙니다. 포털 코드가 만료돼서 VPN 비밀번호를 바꾸는 것은 시간을 낭비하고 진짜 문제를 그대로 둡니다.
몇 가지 시험으로 단계를 구분할 수 있습니다. 포털 로그인 후 평범한 공용 HTTPS 페이지를 요청하세요. 대신 포털이 돌아오면 그 계층에서 승인이 끝난 적이 없습니다. VPN 클라이언트가 게이트웨이에 닿지 못한다고 보고하면 문제는 터널 아래인 포털 세션, 이름 해석, 포트를 막는 네트워크 중 하나입니다. 터널이 올라오고 내부 호스트 이름 하나만 실패하면 사설 네트워크 안의 이름 해석이나 정책이 더 의심스럽습니다.
포털 세션도 터널과 무관하게 만료됩니다. 장소가 접근을 철회하면 자격 증명이 틀린 적이 없어도 이미 맺어진 VPN 연결이 끊깁니다. 포털을 다시 승인한 뒤 VPN을 다시 연결하고 재협상하게 하세요. 그때 VPN 비밀번호를 돌려도 아무것도 고쳐지지 않고 잠길 수 있습니다.
각 비밀은 그것을 검증할 수 있는 시스템에만 주고, 표에 맞지 않는 요구는 피해야 할 단계가 아니라 정지 신호로 다루세요. 두 단계를 통과했는데도 터널이 거부하면 어떤 자격 증명도 바꾸기 전에 클라이언트의 정확한 오류를 기록하세요.