OpenConnect 로그인이 엉뚱한 페이지로 가나요? 먼저 경로를 확인하세요

온보딩 메일에서 주소를 붙여 넣으면 클라이언트가 게이트웨이에 도달하고, 나타나는 로그인 양식은 운영자가 설명한 파트너 포털이 아니라 일반 포털입니다. 아무 오류도 표시되지 않아 혼란스러운데, 터널이 심지어 올라올 수도 있지만 잘못된 진입점 뒤에서일 뿐입니다. 그 URL의 경로는 일을 하고 있었고, 그것을 무엇으로 바꾸든 그 일은 사라졌습니다.

티켓에서 하나의 문자열로 도착하는 두 가지, 즉 서비스에 도달하는 주소와 인증이 어디서 시작되는지를 결정하는 입력을 분리하세요. 앞의 것을 고치고 뒤의 것을 무시하는 것이 올바른 호스트 이름이 여전히 잘못된 로그인을 만드는 방식입니다.

양식을 보기 전에 클라이언트가 보내는 것

https://vpn.example.net/partners 같은 주소에서 클라이언트의 첫 동작은 맨 호스트가 아니라 그 경로로 보내는 HTTPS 요청입니다. 돌아오는 것은 보통 로그인 엔드포인트로의 리디렉션이거나 양식 자체입니다. vpn.example.net만 받은 클라이언트는 기본 방문 페이지가 무엇이든 거기서 시작하며, 그것이 다른 포털, 다른 그룹 목록, 또는 전혀 다른 프로토콜을 기대하는 페이지일 수 있습니다. 차이는 자격 증명이 입력되기 훨씬 전에 응답 헤더에서 보입니다.

그래서 작동하는 브라우저 탭과 실패하는 클라이언트 프로필이 같은 게이트웨이를 말하면서도 서로 어긋날 수 있습니다. 브라우저는 경로를 따랐고, 프로필은 그것을 가진 적이 없습니다.

서로 바꿔 쓸 수 있어 보이지만 그렇지 않은 두 입력

OpenConnect는 초기 HTTPS 경로를 --usergroup으로 노출하며, 매뉴얼 페이지는 그 경로를 담은 전체 URL을 같은 요청을 다르게 쓴 것으로 취급합니다. --authgroup은 별개의 옵션으로, 로그인 양식 안에서 게이트웨이가 제시하는 목록에서 항목을 고릅니다. 일부 프로토콜은 그 항목을 그룹이라 부르고, 다른 프로토콜은 도메인이나 게이트웨이라 부르며, 바로 그 지점에서 두 플래그가 혼동됩니다.

서비스가 정당하게 둘 다 필요할 수 있습니다. 경로가 올바른 포털로 데려다주더라도 양식은 그 안의 그룹 중에서 고르라고 요구할 수 있습니다. 포털 이름을 그룹 이름으로 주거나 그 반대로 하면, 값이 문법적으로는 유효하고 의미적으로는 틀렸기 때문에 수락된 것처럼 보였다가 권한 부여에 실패합니다.

운영자에게 진입 경로, 양식에서의 선택, 그리고 둘 다 필요한지 여부를 각자의 줄로 요청하세요. 레이블이 비슷하게 들린다고 해서 하나에서 다른 하나를 추론하지 마세요.

경로를 잘라내면 결과가 달라지는 이유

호스트와 포트만 받아들이는 클라이언트도 자주 연결되므로 증상이 뚜렷한 실패인 경우는 드뭅니다. 대신 잘못된 로그인 페이지, 빈 그룹 목록, 운영자가 게시한 것과 더 이상 일치하지 않는 인증서 이름, 또는 원하는 서비스로 가는 경로 없이 올라오는 터널을 얻습니다. 각각은 서로 다른 계층에 있으며, 호스트 이름으로 문서화된 필드에 더 긴 문자열을 붙여 넣어 고쳐지는 것은 하나도 없습니다. 그중 둘은 둘 다 그저 계속되지 않는 로그인 양식으로 도착하기 때문에 외부에서 구별조차 되지 않습니다.

호스트 이름을 IP 주소로 바꾸는 것은 종종 이 문제와 함께 다니는 별개의 실수입니다. 이름 기반 서비스 선택과 인증서 검증은 모두 이름에 의존하므로, 숫자 주소는 경로 형식 문제를 TLS 오류로 바꿀 수 있습니다.

브라우저 주소는 경로보다 더 많은 것을 담습니다. 세션 식별자, 리디렉션 대상, 언어 접두사, 임시 로그인 매개변수가 모두 주소 표시줄에 나타나며, 어느 것도 저장된 클라이언트 프로필에 속하지 않습니다.

다른 무엇이든 편집하기 전에 진입점을 확인하세요

받은 경로의 헤더를 읽으세요. curl -sS -o /dev/null -D - https://vpn.example.net/partners 같은 요청은 리디렉션을 따르지 않고 상태 줄과 모든 Location 헤더를 출력합니다. 이름이 있는 로그인 엔드포인트를 가리키는 302는 경로가 존재함을 확인하고 어디로 가는지 보여 주며, 404는 운영자의 주소가 낡았음을 뜻합니다.

그다음 승인된 클라이언트에서 예를 들어 openconnect --usergroup=partners vpn.example.net으로 같은 진입점을 재현하고 어떤 양식이 나타나는지 보세요. 양식이 올바른데도 터널이 여전히 실패한다면, 경로는 문제가 아니었고 다음 정류장은 정책이나 라우팅입니다.

티켓에 호스트 이름, 포트, 프로토콜, 진입 경로, 양식 선택을 다섯 개의 별도 필드로 기록하세요. 그 목록이 다음 엔지니어로 하여금 도달할 수 없는 서버, TLS 거부, 거부된 선택, 필요한 경로 없이 올라온 터널을 구별하게 해 줍니다.