Lớp nào của hồ sơ L2TP thực sự hỏng

Đi xuống theo chồng lớp thay vì lướt ngang trang cài đặt: Thương lượng IPsec, rồi điều khiển L2TP, rồi xác thực PPP, rồi gán địa chỉ và DNS. Mỗi lớp có chữ ký lỗi riêng và nguyên nhân khả dĩ riêng. Một hồ sơ thất bại ở bước xác thực người dùng đã vượt qua ba lần kiểm tra mà một hồ sơ hết thời gian trước đó không bao giờ tới được. Chính thứ tự này là điều cần xác lập trước tiên.

Cùng một tên giao thức che giấu bốn cuộc trò chuyện khác nhau.

Gọi tên lớp trước khi thay đổi cài đặt

Thiết lập IPsec thất bại cho thấy vấn đề ở bí mật chia sẻ, thuật toán hoặc danh tính phía đối diện. Nếu sau đó điều khiển L2TP thất bại thì đó là chính lớp đường hầm, một vấn đề hẹp hơn. Lỗi xác thực PPP chỉ ra tài khoản hoặc phương thức xác thực. Lỗi địa chỉ hoặc DNS sau khi xác thực nghĩa là phần truyền tải đã hoạt động còn việc trao đổi cấu hình thì không.

Ghi lại phiên bản ứng dụng khách, phiên bản hệ điều hành và cấu hình đã được nhà cung cấp ghi thành tài liệu. Thiếu ba thứ đó, mọi thay đổi chỉ là phỏng đoán có thể vô tình sửa một thứ khác.

So sánh hồ sơ với ứng dụng khách hiện tại

Một hồ sơ đã lưu có thể chứa bí mật chia sẻ, tùy chọn xác thực hoặc điểm cuối mà ứng dụng khách hiện tại không còn chấp nhận. Một số nền tảng đã rút hoặc loại bỏ hoàn toàn hỗ trợ L2TP/IPsec, và ứng dụng khách đã cập nhật có thể từ bỏ hành vi IKE cũ mà không có bất kỳ thay đổi nào trên máy chủ. Hãy so sánh giá trị đã lưu với yêu cầu hiện hành được nhà cung cấp ghi thành tài liệu, không phải với thứ đã chạy được một năm trước. Khoảng cách giữa hai tài liệu đó thường là nơi chứa câu trả lời.

Bí mật được lưu đệm hoặc tài khoản đã đổi tên thường chỉ cần một lần cập nhật hồ sơ thông thường, và cả hai đều đáng kiểm tra trước khi thiết kế lại bất cứ thứ gì. Đó là những bản sửa rẻ tiền, và chúng cần được loại trừ trước mọi việc mang tính kiến trúc.

Tùy chọn cũ không trở lại chỉ vì được bật

Tắt kiểm chứng không sửa được vấn đề chuỗi tin cậy, và bật một thuật toán chỉ vì có bài đăng diễn đàn nhắc đến nó không chứng minh được gì về điều máy chủ chấp nhận. Các đề xuất IKE yếu thường bị gỡ khỏi ứng dụng khách vì lý do chính đáng, và bật lại một trong số đó tạo ra kết nối tệ hơn kết nối đã hỏng. Đường hầm yếu hơn không phải là sửa chữa, mà là vấn đề mới với cùng triệu chứng. Câu hỏi đúng là nhà cung cấp hiện hỗ trợ điều gì.

Bản sửa bằng cách bật tất cả thay đổi nhiều hơn hẳn sự cố thật và khiến bạn không thể nói điều gì đã sửa nó.

Trình bày việc chuyển đổi như một dự án

Nếu việc triển khai không còn hỗ trợ ứng dụng khách cần thiết, hãy lên kế hoạch thay thế cùng nhà cung cấp thay vì giữ lại một ngoại lệ không được ghi thành tài liệu. Chuyển theo yêu cầu truy cập, danh tính, bản ghi DNS và tuyến đường, vì chỉ một lần bắt tay mới không tạo lại bất kỳ quyền nào trong số đó. Đó là những phần mà một kết nối đang chạy âm thầm dựa vào. Giữ hồ sơ cũ an toàn cho đến khi việc khôi phục được xác nhận, sau đó thu hồi thông tin đăng nhập cũ ở đúng nơi chúng thực sự được quản lý. Để chúng nguyên chỗ chính là cách một con đường cũ vẫn dùng được rất lâu sau khi mọi người tin rằng nó đã đóng.

Chuyển đổi cũng là lúc ghi lại hồ sơ dùng để làm gì. Nếu không, người tiếp theo sẽ thừa hưởng một kết nối đang chạy mà không có lời giải thích nào.

Kiểm tra lớp, phiên bản ứng dụng khách và yêu cầu hiện hành của nhà cung cấp. Sau đó quyết định đây là sửa chữa hay thay thế.