Linux에서 로그인 전에 SSTP가 실패하나요? 런타임 구성 요소를 확인하세요

SSTP 플러그인을 설치하면 네트워크 편집기에 라디오 버튼이 나타나고, 게이트웨이와 사용자 이름을 채우면 프로필이 비밀번호를 묻기도 전에 일반 오류로 실패합니다. 이 순서에 특별한 점은 없으며, 터널 소프트웨어가 설치되었다는 증거도 아닙니다. SSTP 연결은 따로 배포되는 부품으로 조립됩니다. NetworkManager가 실행할 수 있는 VPN 플러그인, TLS와 PPP 세션을 소유하는 SSTP 클라이언트 프로그램, 그 아래의 PPP 데몬, 그리고 연결이 읽도록 허용된 비밀 저장소입니다.

메뉴 항목이 더하는 것과 더하지 않는 것

플러그인은 NetworkManager에 실행 방법을 알려 주는 서비스 설명과, 대부분의 배포판에서 양식을 그리는 작은 편집기를 제공합니다. 메뉴 항목의 범위는 이것이 전부입니다. 클라이언트 프로그램은 다른 소스 패키지에서 오며, 플러그인 자체의 README도 그 분담을 분명히 밝힙니다. 이것은 플러그인이지 클라이언트가 아닙니다.

그다음 클라이언트에는 PPP가 필요합니다. SSTP는 TLS 연결 안에 PPP 세션을 실어 나르기 때문입니다. pppd 없이는 터널이 TLS 핸드셰이크를 마치고도 첫 제어 프레임에서 죽을 수 있으며, 이는 자격 증명 문제처럼 보이지만 그렇지 않습니다. Debian과 Ubuntu에서는 부품이 network-manager-sstp, sstp-client, ppp으로 제공되며, 첫 번째만 설치하는 것이 양식이 모든 필드를 받아들이는데 연결은 끝나지 않는 가장 흔한 이유입니다.

데스크톱 선택은 분리를 하나 더 추가합니다. Plasma는 plasma-nm으로 프로필을 편집하며, 이는 자체 SSTP 구성 요소를 필요로 하고 같은 서비스 설명을 읽습니다. 따라서 SSTP 항목이 없는 편집기와 프로필을 잘 만드는 CLI는 망가진 런타임이 아니라 편집기의 절반이 빠진 것입니다.

무엇이든 다시 설치하기 전에 첫 실패 단계를 읽으세요

실패한 SSTP 시도는 정해진 순서로 단계를 거치며, 실패한 단계가 어느 구성 요소를 볼지 알려 줍니다.

플러그인 실행이 첫 단계이며, 여기서의 실패는 서버가 아니라 VPN 서비스에 관한 메시지를 냅니다. 다음은 포트 443으로의 TCP 연결입니다. 여기서 거부나 시간 초과는 도달 가능성 문제이지 TLS 문제가 아닙니다. 그다음 TLS 핸드셰이크와 서버 ID 확인, 그다음 PPP 협상과 계정 인증, 마지막으로 주소 할당과 경로입니다. 프로필을 한 번 활성화하는 동안 journalctl -f -u NetworkManager을 지켜보고, 마지막 일반 줄이 아니라 첫 번째 구체적인 줄을 읽으세요.

이 순서는 흔한 오독을 설명합니다. 인증서 불만은 자격 증명이 전송되기 전에 보고되므로 비밀번호를 바꿔도 도움이 되지 않습니다. PPP 인증 거부는 핸드셰이크가 성공한 뒤에 오므로 인증서를 바꿔도 도움이 되지 않습니다. 첫 오류와 그 단계를 남기면 증상이 아니라 진단을 얻게 됩니다.

인증서 신뢰와 계정 로그인은 별개의 관문

핸드셰이크는 설정한 발급자와 이름을 사용해 서버가 의도한 서버인지 검증합니다. 그 뒤에야 PPP 계층이 사용자 이름과 비밀번호를 게이트웨이의 인증 방식에 제시합니다. 즉 두 개의 독립적인 확인이 정해진 순서로 평가되며 각각 별도의 설정을 가집니다. 비밀번호 필드에 입력한 무엇도 첫 번째 확인에 영향을 줄 수 없습니다.

잘못된 발급자를 신뢰하는 프로필은 첫 관문에서 ID 오류로 실패합니다. 올바르게 신뢰하지만 오래된 비밀번호를 저장한 프로필은 두 번째 관문에서 인증 거부로 실패합니다. 둘 다 연결되지 않는 VPN처럼 보이며, 어느 쪽도 다른 쪽의 처방으로 고쳐지지 않습니다.

편집기의 기본값을 추측하지 말고 게이트웨이를 운영하는 사람에게 예상 발급자와 서버 이름을 받고, 그들이 요구하는 인증 방식을 기록하세요. 조직이 플러그인이 표현할 수 없는 방식을 필요로 한다면 정직한 답은 그것을 할 수 있는 승인된 클라이언트이지, 오류를 없애려고 검증을 끈 프로필이 아닙니다.

프로필과 비밀의 주인을 하나로 두세요

프로필이 생기면 NetworkManager로 활성화하고, 그 결과 생기는 경로와 리졸버 변경도 그 관리자가 소유하게 하세요. NetworkManager가 이미 연결을 운영하는데 두 번째 독립 SSTP 클라이언트를 시작하면 두 세트의 경로, 두 개의 DNS 구성, 단일 진실 원천이 없는 디버깅 세션이 생깁니다.

비밀에도 소유자가 있습니다. 시스템 전체 사용으로 표시된 연결은 사용자 세션으로 제한된 연결과 자격 증명을 다르게 저장하며, 키 파일에 손으로 만든 프로필은 비밀번호를 대화식으로 제공하려는 비밀 에이전트가 읽지 못할 수 있습니다. 문제가 된 적 없는 비밀번호를 다시 입력하기 전에 프로필이 어떤 컨텍스트를 기대하는지 확인하세요. 같은 프로필을 터미널에서 nmcli로 활성화하는 것이 가장 빠른 테스트입니다. 절대 나타나지 않는 프롬프트는 에이전트가 이미 제공할 것이 없었다고 알려 줍니다.

터널, 경로, 리졸버를 따로 확인하세요

연결됨 표시는 링크가 올라왔다는 것만 주장합니다. 실제로 필요한 목적지, 그것을 전달하는 경로, 사용 중인 리졸버를 하나씩 확인하세요. 각각이 틀릴 수 있으면서 나머지 둘은 정상일 수 있습니다.

실패한 시도에서는 각 구성 요소의 버전과 정리된 오류 텍스트를 기록하세요. 전체 프로필이 아니라 그것들을 공유하세요. 프로필에는 미리 공유된 비밀과 저장된 자격 증명이 들어 있을 수 있습니다.

마지막으로 연결을 끊고 다시 연결한 뒤 한 번 재부팅하세요. 프로필이 첫 시도에서만 작동한다면 문제는 비밀 처리나 경로 소유권에 있으며, 둘 다 근무일 중간보다 지금 고치는 편이 저렴합니다.