AWS Client VPN에서 SAML 로그인을 완료할 수 있는 클라이언트

같은 AWS Client VPN과 SAML 질문에도 답은 정반대로 갈립니다. 매일 아침 Ubuntu 노트북에서 로그인하는 사람이 있는가 하면, 휴대폰과 내려받은 프로필을 가지고 있으면서 그 안의 한 줄이 클라이언트에 거부되는 사람도 있습니다. 차이는 운도 아니고 대시보드의 숨은 스위치도 아닙니다. 세 가지 조건이 결정합니다. 플랫폼이 AWS가 자체 클라이언트에 대해 지원하는 것인지, 손에 든 도구가 연동 브라우저 교환을 수행할 수 있는지, 엔드포인트가 SAML용으로 설정되어 있는지입니다. 셋 중 하나라도 빠지면 로그인은 다른 지점에서 멈춥니다.

로그인을 끝낼 수 있는지 결정하는 세 가지 조건

먼저 플랫폼입니다. AWS는 Windows, macOS, 그리고 AMD64의 Ubuntu용 자체 Client VPN 클라이언트를 제공하며, 2026년 시월 말 기준 Linux 요구 사항 페이지에는 Ubuntu 22.04, 24.04, 26.04가 적혀 있습니다. 다시 패키징한 빌드나 변환한 패키지, 다른 배포판은 동작할 수 있지만 지원되는 플랫폼이 아니며, 그것이 깨질 때 지원 창구는 바로 여러분입니다.

다음은 클라이언트입니다. 연동 로그인은 모든 OpenVPN 호환 앱이 해석하는 프로필 옵션이 아닙니다. 제공된 클라이언트는 브라우저에서 자격 증명 공급자를 열고 서명된 인증 응답을 받아 그 응답을 엔드포인트로 보냅니다. 프로필을 읽고 터널만 올리는 앱은 연결 로그가 아무리 깔끔해도 이 단계를 수행하지 않습니다.

마지막은 엔드포인트입니다. Active Directory 자격 증명이나 상호 인증서를 쓰는 엔드포인트는 구조가 전혀 다르며, 클라이언트를 바꿔도 달라지지 않습니다. 다른 무엇을 디버깅하기 전에 프로필을 발급한 쪽과 인증 모드를 확인하십시오.

세 조건을 모으면 짧은 결정 표가 됩니다:

OpenVPN 가져오기가 auth-federate에서 멈추는 이유

내보낸 AWS Client VPN 프로필에는 인증이 터널 밖에서 연동을 통해 이루어진다고 클라이언트에 알리는 지시문이 들어 있습니다. 일반 OpenVPN 클라이언트는 그 줄을 아예 거부하거나 무시하고, 그러면 제시할 자격 증명이 없습니다. Android 시도의 대부분이 여기서 끝납니다. 프로필은 가져와지고, 앱이 이의를 제기하거나, 패킷 하나가 기기를 떠나기도 전에 구성 오류로 연결이 죽습니다.

auth-federate을 삭제하는 것이 다음의 유혹적인 수단이지만, 분명한 실패를 혼란스러운 실패로 바꿀 뿐입니다. 지시문을 제거한다고 SAML 엔드포인트가 사용자 이름과 비밀번호 인증이 되지는 않습니다. 엔드포인트는 여전히 서명된 SAML 응답을 기대하며 클라이언트가 대신 보내는 것을 거부합니다. 계정 비밀번호, 내려받은 프로필, 복사한 어서션은 서로 바꿔 쓸 수 있는 자격 증명이 아닙니다.

휴대폰 Chrome에서 자격 증명 공급자에 로그인하는 것은 공급자가 사용자를 받아들였다는 것만 증명합니다. 응답이 엔드포인트로 되돌려 보낼 수 있는 클라이언트에 도달하는지는 말해 주지 않습니다. 연동 인증 요구 사항이 제공된 클라이언트를 흐름의 일부로 만드는 이유가 바로 그것입니다. 브라우저 단계는 필요하지만 충분하지 않습니다.

지원되는 Linux 데스크톱 경로

AWS가 Ubuntu AMD64용으로 배포하는 패키지를 시스템 패키지 관리자로 설치한 뒤, 프로필을 범용 VPN 앱으로 가져오지 말고 그 클라이언트에서 연결을 여십시오. 관리자가 이 엔드포인트용으로 내보낸 프로필을 사용하고, 오래된 안내서의 콜백 URL이나 클라이언트 식별자로 바꾸지 마십시오. 클라이언트가 받아들이더라도 마찬가지입니다.

연결을 시작하고 열린 브라우저에서 로그인과 MFA 요구를 마치고, 브라우저에서 클라이언트로 돌아오는 흐름이 끝나게 하십시오. 그다음 실제로 필요한 사설 주소를 새로 요청하십시오. 로그인 성공을 알리는 페이지는 터널이 올라왔다는 증거가 아닙니다.

Linux 클라이언트는 SAML 응답을 위해 로컬 TCP 포트 8096부터 8115까지를 예약합니다. 자격 증명 공급자가 여러분을 받아들인 뒤에도 전달이 멈춘다면, 그 범위에서 이미 무엇이 수신 중인지 확인하십시오:

ss -ltnp | grep -E ":809[6-9]|:81(0[0-9]|1[0-5])"

포트가 점유되어 있거나 루프백 수신을 엔드포인트 보안 소프트웨어가 막으면, 로그인은 완료된 것처럼 보이고 그다음 연결되지 않습니다. 이 범위는 로컬로 두십시오. 클라이언트 측 반환 경로이며 EC2 보안 그룹이나 게이트웨이 방화벽 규칙에서 열 대상이 아니고, 인터넷에 열면 아무것도 고치지 못한 채 노출만 늘어납니다.

무엇을 바꾸기 전에 실패한 단계를 읽으십시오

클라이언트를 탓하는 것이 흔한 반사이지만, 실패 지점마다 담당이 다릅니다. 먼저 자신이 실제로 어디에 있는지 파악하십시오.

• 브라우저 창이 열리지 않습니다. 프로필의 인증 모드, 선택한 연결, 데스크톱 기본 브라우저 연동을 확인하십시오.
• 자격 증명 공급자가 계정을 거부합니다. 계정 할당, MFA 등록, SAML 애플리케이션 구성은 모두 관리자 영역입니다.
• 브라우저는 끝나지만 클라이언트가 연결되지 않습니다. 만료되었거나 쓸 수 없는 인증 응답, 차단된 반환 포트, 실패한 전달입니다.
• 터널은 올라왔지만 애플리케이션에 닿지 않습니다. 엔드포인트 경로, 권한 부여 규칙, 보안 그룹, DNS. 브라우저 로그인을 반복해도 빠진 네트워크 권한이 생기지 않습니다.

에스컬레이션할 때 클라이언트의 오류 텍스트와 시도 시각을 남기십시오. SAML이 고장 났다는 말과 클라이언트가 유효한 인증 응답을 받은 적이 없다는 말은 사람들을 전혀 다른 곳으로 보냅니다.

그래도 요구 사항이 Android일 때

Android는 AWS가 자체 클라이언트를 배포하는 플랫폼이 아니므로, 설치할 수 있는 지원 모바일 클라이언트가 없다는 것이 정직한 답입니다. 이것은 설계상 제약이며, 프로필을 고쳐 무언가 연결될 때까지 휴대폰에서 풀어야 할 퍼즐이 아닙니다.

바뀔 수 있는 것은 그 뒤의 접근 설계이고, 그 결정은 관리자의 몫입니다. 휴대폰이 필요로 하는 단 하나의 내부 서비스로 가는 승인된 애플리케이션 접근 경로, 조직이 이미 운영하는 모바일 지원 VPN 제품, 또는 SAML만 쓰는 엔드포인트를 위한 지원 데스크톱입니다. 각 선택지는 자체 엔드포인트 구성과 자격 증명 등록, 권한 부여 규칙을 동반하며, 그중 어느 것도 사용자가 내려받은 프로필에서 만들 수 없습니다.

격차를 메운다고 주장하는 타사 도구에는 MFA, 응답 처리, 기기 정책, 업데이트 주기를 포괄하는 명시적인 지원 및 보안 검토가 필요합니다. 존재한다고 해서 AWS가 제공하는 Android 클라이언트가 되는 것은 아니며, 그중 하나를 동작시키려고 재사용 가능한 인증 자료를 휴대폰으로 옮겨서는 안 됩니다.

지시문에 대한 긴 스레드 대신 관리자에게 세 가지 사실을 주십시오. 엔드포인트의 인증 모드, 휴대폰이 도달해야 하는 사설 리소스, 그리고 마감 기한입니다. 데스크톱, 애플리케이션 접근 경로, 새 VPN 제품 중에서 고르기에 그것으로 충분합니다.

새 티켓을 열기 전에 조건을 순서대로 확인하십시오. 플랫폼이 제공 클라이언트 목록에 있는지, 브라우저 교환을 완료할 수 있는 도구인지, 실제로 연동을 위해 구성된 엔드포인트인지, Linux에서는 루프백 포트 범위인지입니다. 처음 실패한 항목이 고칠 대상입니다. 그 뒤의 모든 것은 추측입니다.