서버 잠금 프로필이 TLS 프록시 뒤에서 실패합니다: 어느 세대입니까?

같은 날 같은 포털을 통해 한 사용자는 연결되고 다른 사용자는 연결되지 않습니다. 둘 다 서버 잠금 프로필을 가지고 있고, 둘 다 같은 Access Server 빌드에 있으며, 유일한 차이는 프로필이 생성된 시점입니다. 이것은 알아볼 가치가 있는 패턴입니다, 왜냐하면 "서버 잠금"은 연결 순서가 아니라 정책을 가리키기 때문입니다. Access Server는 그 산출물의 두 세대를 출시했고, TLS 리버스 프록시는 그중 한 경로 앞에만 있습니다. 어느 분기에 있는지는 세 가지 조건이 결정합니다.

두 세대, 두 가지 연결 순서

2.8까지 적용되는 이전 설계에서 가져온 파일은 유사 프로필입니다. OpenVPN Connect는 이를 사용해 HTTPS를 통해 Access Server 웹 API에 인증하고, 임시 사용자 잠금 프로필과 세션 토큰을 받은 뒤에야 VPN을 설정합니다. 두 전송이 순서대로 실행되며, 첫 번째는 평범한 웹 요청입니다.

2.9와 함께 도입된 형식은 그 연결별 부트스트랩을 수행하지 않습니다. 이는 호환되는 OpenVPN 클라이언트가 사용할 수 있는 네이티브 프로필이며, OpenVPN Connect 전용이 아닙니다. 다운로드하거나 URL로 가져오는 데 여전히 HTTPS가 관련될 수 있지만, 그것은 게시 단계이지 연결별 임시 프로필 가져오기가 아닙니다.

업그레이드가 이미 발급된 프로필을 반드시 다시 쓰지는 않으므로, 현재 서버 버전이 여전히 오래된 산출물을 배포할 수 있습니다. 서버 빌드는 무엇이 가능한지를 알려 주며, 이 사용자가 무엇을 가져왔는지는 알려 주지 않습니다.

분기를 고르는 세 가지 조건

첫 번째 조건은 산출물의 세대입니다. 파일을 요청하고, 어떻게 생성되었는지 확인하고, 가져온 클라이언트 버전을 기록하십시오. 파일에서 세대를 확인할 수 없다면, 테스트 계정용으로 새로 발급한 프로필이 서버가 오늘 무엇을 생성하는지 알려 줄 것이며, 이는 실패한 사용자가 가진 정보와 다른 정보입니다.

두 번째는 프런트 엔드가 실제로 무엇을 종료하는지입니다. TLS를 오프로드하는 일곱 번째 계층의 HTTP 리버스 프록시는 네 번째 계층 TCP 포워더와 같은 객체가 아니며, UDP 포워더도 마찬가지입니다. 포트 443에서 Access Server의 일반적인 구성은 OpenVPN TCP 데몬이 브라우저 트래픽을 인식해 웹 서비스로 넘기게 하므로, 무관한 HTTPS 종단 장치를 앞에 두어도 그 데몬의 프로토콜 처리가 유지되지 않습니다. 443이라는 번호를 공유한다고 두 설계가 동등해지지는 않습니다.

세 번째는 실패가 어디에서 발생하는지입니다. VPN 이전의 실패와 제어 채널의 실패는 "연결 중"이라고만 말하는 클라이언트에서는 비슷해 보이지만, 증거를 남기는 위치가 다릅니다. 이전 형식이 관련되어 있다면 부트스트랩이 후보입니다. 새 형식이 관련되어 있다면 웹 액세스 로그가 비어 있는 것이 예상되며 어느 방향으로도 아무것도 증명하지 않습니다.

산출물이 오래된 경우: 부트스트랩이 먼저 실패합니다

클라이언트의 최종 상태가 아니라 실제 오류를 읽으십시오. 흥미로운 필드는 HTTPS 오류, 클라이언트가 기대한 서버 ID, 요청이 향한 목적지, 인증서 검증이 완료되었는지 여부입니다. 그다음 서버 측 웹 서비스와 프록시 로그와 대조하십시오.

브라우저가 로그인 페이지에 도달하는 것은 이 클라이언트의 API 인증이 성공했다는 증거가 아닙니다. 서로 다른 요청이며, 인증서 기대가 다르고 호스트 이름도 다른 경우가 많습니다. 포털이 올바르게 제공되는데도 클라이언트가 실패한다면, 불일치는 부트스트랩 경로에 있으며 사용자의 비밀번호에 있지 않습니다.

TLS 검증을 끄거나 인증 정책을 느슨하게 하여 비교를 통과시키지 마십시오. 그것은 진단 가능한 구성 불일치를 동작하지만 검증되지 않은 경로로 바꾸며, 바로 그 변경이 임시 테스트를 영구적인 구멍으로 만듭니다. Access Server의 연결 프로필 문서 는 두 세대와 임시 프로필 흐름을 설명하며, 프록시를 탓하기 전에 확인해야 할 참고 자료입니다.

산출물이 새로운 경우: 대신 제어 채널을 읽으십시오

2.9 스타일 프로필에서는 클라이언트가 네이티브 VPN 엔드포인트로 곧바로 갑니다. 프로필의 엔드포인트, 사용 중인 전송, 제어 채널 오류를 조사하십시오. 클라이언트가 HTTP 요청을 전혀 보내지 않는다면 그것은 설계와 일치하며 증상이 아닙니다.

여기서 프록시 질문의 형태도 바뀝니다. HTTPS 오프로드는 결코 보지 못하는 TCP 전용 스트림을 깨뜨릴 수 없지만, 프로필을 게시하는 다운로드는 여전히 깨뜨릴 수 있고, TCP 전용 포워더는 UDP를 전혀 나르지 않습니다. 프런트 엔드가 무관하다고 결론 내리기 전에 프로필이 어떤 전송을 요구하는지 확인하십시오.

단일 스트림에 대한 TLS 패스스루는 좁은 구성입니다. UDP 전달을 제공하지 않고, 443에서 데몬 자체의 서비스 전달 동작을 재현하지 않습니다. 프런트 엔드가 그중 하나를 한다면 조치가 다르므로 어느 것인지 밝히십시오.

좁게 유지되는 조치

가장 침습적이지 않은 점검은 테스트 계정용으로 지원되는 새 프로필을 생성하고 동일한 인증 요구 사항으로 의도한 네이티브 엔드포인트를 통해 연결하는 것입니다. 그것이 작동하고 보관한 이전 프로필이 작동하지 않는다면, 한 단계로 산출물을 서버와 프록시로부터 분리한 것입니다.

사용자 잠금 프로필의 배포 는 실패할 수 있는 임시 프로필 교환이 없으므로 레거시 부트스트랩 의존성을 완전히 제거합니다. 의도한 사용자에게 발급해야 하며 관리자로부터 복사해서는 안 되고, 클라이언트가 권한을 가지는 범위를 바꾸므로 우회 수단이 아니라 정책 결정으로 다루십시오.

그다음 게시 레이아웃을 고쳐 다운로드와 포털 사용을 위한 웹 경로, 그리고 프로필이 기대하는 전송상의 네이티브 VPN 경로라는 필요한 모든 경로가 존재하게 하십시오. 프록시의 역할은 한 계층에 머물게 하십시오. 작동하는 사용자 잠금 터널은 그 경로가 작동함을 증명하지만, 모든 프록시 구성이 모든 세대를 지원함을 증명하지는 않으며, 오래된 부트스트랩 실패가 새 형식을 비난하지도 않습니다.

• 프록시를 건드리기 전에 산출물의 세대를 확인하십시오.
• 실패가 터널 이전에 발생하는지 내부에서 발생하는지 판별하십시오.
• 프런트 엔드가 무엇을 종료하는지(HTTP, TCP 스트림 또는 UDP) 확인하십시오.
• 정책을 바꾸지 않은 채 새로 발급한 프로필을 네이티브 엔드포인트에 대해 시험하십시오.