L2TP/IPsec không hoạt động: tách riêng IPsec, xác thực đường hầm hay đăng nhập PPP

Ba thứ được xác thực bên trong một kết nối L2TP/IPsec, và chỉ một trong số đó liên quan đến người quay số. IPsec chứng minh hai đầu của đường hầm, kết nối điều khiển L2TP có thể chứng minh lại các đối tác bằng bí mật riêng của nó, và sau đó PPP chứng minh tài khoản người dùng bên trong phiên. Lỗi ở bất kỳ giai đoạn nào đều trông như lỗi đăng nhập chung trong hộp thoại máy khách và trông hoàn toàn khác trong nhật ký máy chủ. Đi qua các giai đoạn theo thứ tự và dừng ở giai đoạn đầu tiên hỏng, vì mọi giai đoạn bên dưới một giai đoạn chưa được kiểm tra cũng chưa được kiểm tra.

Ba giai đoạn xác thực, ba danh tính khác nhau

IPsec chứng minh ai sở hữu hai đầu, bằng khóa chia sẻ trước hoặc chứng chỉ. Danh tính đó thuộc về máy móc hoặc cổng, không bao giờ thuộc về con người trước bàn phím. Khi các đối tác không thể thống nhất ở giai đoạn này, không có gói L2TP nào được trao đổi.

Kết nối điều khiển L2TP có thể thêm một trao đổi thách thức-phản hồi thứ hai, riêng biệt, được điều khiển bởi một bí mật chung mà cả hai đầu phải có.

RFC 2661 làm cho việc xác thực kết nối điều khiển đó thành tùy chọn, điều này giải thích tại sao cùng một sai lầm lại tạo ra các triệu chứng khác nhau trên hai máy chủ. Một triển khai chưa bao giờ cấu hình bí mật đường hầm sẽ bỏ qua giai đoạn này hoàn toàn; triển khai chỉ cấu hình ở một bên sẽ hỏng trước khi PPP được chào mời. Sau đó PPP xác thực người dùng bằng PAP, CHAP hoặc MSCHAPv2 và giao tên cho kho tài khoản có thể là cục bộ, trong chap-secrets hoặc trên RADIUS. Mật khẩu sai tại thời điểm đó vẫn để bạn với một đường hầm đang hoạt động và một phiên bị hỏng.

Đọc điểm dừng trước khi sửa cấu hình

Bắt đầu với ipsec --version để biết đầu ra trạng thái thuộc về strongSwan hay Libreswan. Sau đó đọc nhật ký máy chủ, không phải hộp thoại máy khách, vì máy chủ ghi lại giai đoạn nào đã từ chối.

Một dòng thường giải quyết phiếu: phàn nàn về IKE hoặc đề xuất là giai đoạn một, thông báo về kết nối điều khiển là giai đoạn hai, và việc từ chối phương thức PPP hoặc tài khoản là giai đoạn ba. Sao chép dòng đó vào phiếu kèm dấu thời gian. Đoán từ phía máy khách sẽ lãng phí bằng chứng duy nhất mà bạn đã có.

Giữ vật liệu khóa và mật khẩu ra ngoài phần dán đó; tên giai đoạn định hướng công việc, và một khóa chia sẻ trước bị rò rỉ sẽ mở lại phiếu với hậu quả tồi tệ hơn.

Giai đoạn một: IPsec có liên kết không?

Chạy ipsec statusall trên strongSwan hoặc ipsec whack --status trên Libreswan và tìm một liên kết con đã thiết lập với bộ đếm khác không. ip xfrm state hiển thị góc nhìn của nhân trên cả hai. Một cặp SA đã cài đặt với bộ đếm tăng lên nghĩa là giai đoạn một đã xong và bạn có thể đi tiếp.

Hoàn toàn không có liên kết chỉ ra địa chỉ đối tác, tập đề xuất hoặc khóa chia sẻ trước, và đôi khi chỉ ra một thiết bị ghi lại UDP 500 nhưng bỏ UDP 4500. Một liên kết được thiết lập rồi biến mất sau vài giây thường là sự không khớp về thời gian sống giữa hai đầu chứ không phải vấn đề thông tin đăng nhập. Kiểm tra xem cả hai bên có liệt kê cùng các đề xuất mã hóa và băm trước khi gõ lại bất cứ thứ gì. Nếu không, sẽ không khóa nào hoạt động được.

Dừng lại khi liên kết còn thiếu. Sửa tùy chọn PPP tại thời điểm đó không thay đổi gì và che giấu lỗi thật khỏi người tiếp theo.

Giai đoạn hai: kết nối điều khiển L2TP đã xác thực chưa?

Khi IPsec đã lên, theo dõi daemon L2TP để tìm kết nối điều khiển đạt trạng thái đã thiết lập, vì PPP không thể bắt đầu trước đó. Việc từ chối trên kết nối điều khiển nghĩa là bí mật đường hầm khác nhau giữa hai đầu, hoặc một đầu yêu cầu một bí mật mà đầu kia không bao giờ gửi. Máy khách thường hiển thị một trường duy nhất có nhãn shared secret, và trường đó thường thuộc về IPsec chứ không phải L2TP. Điền vào đó không cấu hình bí mật đường hầm, và xóa nó không vô hiệu hóa.

Nếu không bên nào cấu hình bí mật đường hầm, hãy bỏ qua giai đoạn này và coi lỗi kết nối điều khiển là vấn đề khả năng tiếp cận. Xác nhận rằng UDP 1701 đến được daemon và cả hai đầu đồng ý về cùng một kiểu đóng gói. Một quy tắc tường lửa viết cho một trong hai điều kiện đó là nguyên nhân phổ biến của kết nối chỉ mở một nửa.

Chỉ phiên bắt đầu đàm phán PPP mới thực sự vượt qua giai đoạn đường hầm.

Giai đoạn ba: PPP có đang từ chối tài khoản không?

Lỗi PPP trông khác từ bên ngoài: đường hầm đã thiết lập, phiên bắt đầu, và daemon ghi lại lỗi phương thức xác thực hoặc từ chối tài khoản. Đọc phương thức được nêu trong thông báo đó. PAP và CHAP hỏng vì những lý do khác nhau, và một máy chủ từ chối một phương thức sẽ từ chối máy khách chỉ cung cấp phương thức đó.

Trên máy chủ Linux, kiểm tra tệp tùy chọn mà daemon chuyển cho PPP, thường là /etc/ppp/options.xl2tpd, và xác nhận phương thức nào được chấp nhận và tài khoản được phân giải ở đâu. Một tên tồn tại trong RADIUS nhưng không có trong tệp bí mật cục bộ sẽ hỏng sạch sẽ và trông giống mật khẩu sai. Sau đó kiểm tra rằng máy khách cung cấp một phương thức mà máy chủ chấp nhận, không phải một phương thức mạnh hơn mà máy chủ từ chối đàm phán. Thay đổi khóa chia sẻ trước để sửa giai đoạn này lãng phí cả buổi chiều và không thay đổi gì.

Khi phiên cuối cùng đứng lên, việc gán địa chỉ, DNS và các tuyến vẫn chưa được kiểm tra, và mỗi thứ hỏng một cách lặng lẽ theo cách của nó. Giữ ba lớp riêng biệt trong ghi chú của bạn: khóa đúng với tài khoản sai luôn hỏng, và sửa một lớp không bao giờ sửa lớp khác.