SSTP trên Linux thất bại trước khi đăng nhập? Kiểm tra các thành phần thời gian chạy

Bạn cài đặt tiện ích SSTP, nút radio xuất hiện trong trình soạn thảo mạng, bạn điền cổng và tên người dùng, và hồ sơ thất bại với lỗi chung trước khi nó kịp hỏi mật khẩu. Không có gì bất thường trong trình tự đó, và không có gì trong đó chứng minh phần mềm đường hầm đã được cài đặt. Một kết nối SSTP được lắp ráp từ các phần được cung cấp riêng: tiện ích VPN mà NetworkManager có thể khởi chạy, chương trình khách SSTP sở hữu phiên TLS và PPP, tiến trình nền PPP bên dưới, và kho bí mật mà kết nối được phép đọc.

Mục menu thêm gì và không thêm gì

Tiện ích đóng góp mô tả dịch vụ cho NetworkManager biết cách khởi chạy nó, và trên hầu hết bản phân phối là một trình soạn thảo nhỏ vẽ biểu mẫu. Đó là toàn bộ phạm vi của mục menu. Chương trình khách đến từ một gói nguồn khác, và README của chính tiện ích nói thẳng sự tách biệt đó: đây là tiện ích, không phải ứng dụng khách.

Sau đó ứng dụng khách cần PPP, vì SSTP mang một phiên PPP bên trong kết nối TLS. Không có pppd đường hầm có thể hoàn tất bắt tay TLS và vẫn chết ở khung điều khiển đầu tiên, điều này trông giống sự cố thông tin đăng nhập nhưng không phải. Trên Debian và Ubuntu các phần đến dưới dạng network-manager-sstp, sstp-client và ppp, và chỉ cài phần đầu là lý do phổ biến nhất khiến biểu mẫu chấp nhận mọi trường nhưng kết nối không bao giờ hoàn tất.

Việc chọn màn hình thêm một sự tách biệt nữa. Plasma sửa hồ sơ qua plasma-nm, cần thành phần SSTP riêng và đọc cùng mô tả dịch vụ, nên một trình soạn thảo không có mục SSTP và một CLI tạo hồ sơ tốt là nửa trình soạn thảo bị thiếu, không phải môi trường chạy hỏng.

Đọc giai đoạn thất bại đầu tiên trước khi cài lại bất cứ thứ gì

Một lần thử SSTP thất bại đi qua các giai đoạn theo thứ tự cố định, và giai đoạn thất bại cho bạn biết nên xem thành phần nào.

Khởi chạy tiện ích là giai đoạn đầu, và thất bại ở đó tạo ra thông báo về dịch vụ VPN chứ không phải về máy chủ. Tiếp theo là kết nối TCP tới cổng 443; từ chối hoặc hết thời gian ở đây là sự cố khả năng tiếp cận, không phải TLS. Rồi bắt tay TLS và kiểm tra danh tính máy chủ, sau đó thương lượng PPP và xác thực tài khoản, và cuối cùng là cấp phát địa chỉ và tuyến đường. Theo dõi journalctl -f -u NetworkManager khi bạn kích hoạt hồ sơ một lần, và đọc dòng cụ thể đầu tiên thay vì dòng chung cuối cùng.

Thứ tự đó giải thích một cách đọc sai phổ biến. Khiếu nại về chứng chỉ được báo trước khi bất kỳ thông tin đăng nhập nào được gửi, nên đổi mật khẩu không thể giúp ích; từ chối xác thực PPP đến sau một lần bắt tay thành công, nên thay chứng chỉ cũng không giúp ích. Giữ lỗi đầu tiên và giai đoạn của nó, và bạn có chẩn đoán chứ không phải triệu chứng.

Tin cậy chứng chỉ và đăng nhập tài khoản là hai cổng riêng

Bắt tay xác nhận máy chủ là máy bạn muốn đến, dùng nhà phát hành và tên bạn đã cấu hình. Chỉ sau đó tầng PPP mới cung cấp tên người dùng và mật khẩu của bạn cho phương thức xác thực của cổng. Vậy là hai kiểm tra độc lập, được đánh giá theo thứ tự cố định, với cài đặt riêng cho từng cái. Không gì gõ vào trường mật khẩu có thể ảnh hưởng đến cái đầu tiên.

Hồ sơ tin nhầm nhà phát hành thất bại ở cổng đầu tiên với lỗi danh tính. Hồ sơ tin đúng nhưng lưu mật khẩu cũ thất bại ở cổng thứ hai với từ chối xác thực. Cả hai đều trông như VPN không kết nối được, và không cái nào được sửa bằng liều thuốc của cái kia.

Lấy nhà phát hành và tên máy chủ mong đợi từ người vận hành cổng thay vì đoán giá trị mặc định của trình soạn thảo, và ghi lại phương thức xác thực họ yêu cầu. Nếu tổ chức cần một phương thức mà tiện ích không thể diễn đạt, câu trả lời trung thực là một ứng dụng khách đã được phê duyệt có thể làm được, không phải hồ sơ đã tắt kiểm tra để lỗi biến mất.

Để một chủ sở hữu giữ hồ sơ và bí mật

Khi hồ sơ tồn tại, hãy kích hoạt nó qua NetworkManager và để trình quản lý đó sở hữu các tuyến đường và thay đổi trình phân giải phát sinh. Khởi chạy ứng dụng khách SSTP độc lập thứ hai trong khi NetworkManager đã điều khiển kết nối cho bạn hai bộ tuyến đường, hai cấu hình DNS và một phiên gỡ lỗi không có nguồn sự thật duy nhất.

Bí mật cũng có chủ sở hữu. Kết nối được đánh dấu dùng cho toàn hệ thống lưu thông tin đăng nhập khác với kết nối giới hạn trong phiên người dùng của bạn, và hồ sơ tạo thủ công trong tệp khóa có thể không đọc được bởi tác nhân bí mật vốn mong cung cấp mật khẩu tương tác. Kiểm tra hồ sơ mong đợi ngữ cảnh nào trước khi gõ lại mật khẩu vốn không bao giờ là vấn đề. Kích hoạt cùng hồ sơ từ terminal bằng nmcli là phép thử nhanh nhất, vì lời nhắc không bao giờ xuất hiện cho bạn biết tác nhân vốn không có gì để cung cấp.

Kiểm tra đường hầm, tuyến đường và trình phân giải riêng biệt

Chỉ báo đã kết nối chỉ khẳng định rằng liên kết đã lên. Kiểm tra đích bạn thực sự cần, tuyến đường mang nó và trình phân giải đang dùng, từng cái một; mỗi cái có thể sai trong khi hai cái kia ổn.

Với một lần thử thất bại, hãy ghi lại phiên bản của từng thành phần và văn bản lỗi đã làm sạch. Chia sẻ những thứ đó, không phải toàn bộ hồ sơ, vì hồ sơ có thể chứa bí mật chia sẻ trước và thông tin đăng nhập đã lưu của bạn.

Cuối cùng, ngắt kết nối và kết nối lại, sau đó khởi động lại một lần. Nếu hồ sơ chỉ hoạt động ở lần thử đầu, vấn đề nằm ở việc xử lý bí mật hoặc quyền sở hữu tuyến đường, và cả hai đều rẻ hơn để sửa bây giờ so với giữa ngày làm việc.