PSK của L2TP/IPsec bị từ chối: xem hộp thoại trước, rồi đến các tệp

Bạn dán khóa chia sẻ trước từ tin nhắn của quản trị viên vào hộp thoại NetworkManager, đánh dấu ô để hiện nó, và nó khớp từng ký tự. Kết nối vẫn kết thúc bằng lỗi xác thực trước khi đường hầm được dựng lên. Lần đầu gặp chuyện này, tôi tưởng khóa sai; hóa ra không phải. Hai thứ khác quyết định điều daemon thực sự đọc: tệp bí mật mà plugin ghi cho kết nối đó, và việc giá trị có đi qua hộp thoại mà không đổi hay không.

Lộ trình dưới đây lần theo khóa từ trường nhập đến tệp, và chính thứ tự đó cho biết nó đã mất ở đâu. Hãy làm trên máy bị lỗi, không phải máy đang chạy tốt, vì khác biệt giữa hai máy thường là cách bố trí tệp chứ không phải khóa.

Bắt đầu từ hộp thoại, nhưng đừng tin trường nhập

Mở thẻ IPsec của kết nối và gõ lại khóa thay vì dán. Một khóa sao chép từ tin nhắn chat, từ PDF hay từ trình quản lý mật khẩu có thể đến kèm một lần xuống dòng ở cuối mà trường nhập không hiển thị, còn các ký tự nhìn thấy vẫn trông đúng.

Bấm nút hiện mật khẩu và nhìn vào cuối chuỗi, không nhìn giữa. Nếu con trỏ để lại một dòng trống dưới văn bản, hãy xóa nó đi và gõ lại ký tự cuối. Chỉ riêng bản sửa đó đã giải quyết một phần đáng ngạc nhiên của những báo cáo kiểu này, và tốn ít công hơn việc đọc bất kỳ nhật ký nào.

Nếu khóa đến từ hệ thống ticket có ngắt dòng dài, hãy yêu cầu qua một kênh không ngắt dòng. So sánh độ dài với quản trị viên thay vì nhìn hai chuỗi cạnh nhau; một ký tự mất ở điểm ngắt dòng là vô hình trong phông chữ tỷ lệ.

Lần theo khóa vào trong /etc/ipsec.d

Plugin không bao giờ trao PSK cho daemon IPsec như một đối số trên dòng lệnh. Thay vào đó nó lưu giá trị trong một tệp bí mật và sắp xếp để daemon đưa tệp đó vào, bằng cách thêm một dòng include vào /etc/ipsec.secrets nếu chưa có. Thứ mà hộp thoại giữ chỉ là đầu vào cho tệp được tạo ra, không phải giá trị đang dùng.

Hãy liệt kê những gì đang có trước khi thay đổi bất cứ thứ gì:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

Các bản phát hành cũ của plugin ghi một tệp cho mỗi kết nối, đặt tên theo UUID của kết nối, ví dụ /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. Xóa một hồ sơ trong applet không xóa tệp đó một cách đáng tin cậy. Nếu một tệp cũ từ máy chủ trước vẫn còn trên đĩa và vẫn được đưa vào, daemon có thể chọn một bí mật thuộc về hồ sơ bạn không còn dùng, và kết nối thất bại trong khi trường nhìn thấy vẫn đúng.

Hiểu điều thay đổi trong 1.2.12 đã làm với việc nâng cấp

Phiên bản plugin 1.2.12 đã thay các tệp bí mật theo từng kết nối bằng một tệp dùng chung duy nhất, /etc/ipsec.d/ipsec.nm-l2tp.secrets. Việc nâng cấp không dọn các tệp cũ theo UUID, và dòng include /etc/ipsec.d/*.secrets sẵn có vẫn đưa chúng vào. Phiên bản 1.2.16 đã đổi cách xử lý đề xuất mặc định, không phải cách bố trí bí mật.

Lịch sử đó giải thích vì sao hai máy có hồ sơ trông giống nhau lại cư xử khác nhau. Khóa thì giống hệt; tập tệp mà daemon đưa vào thì không. Khi gỡ một tệp mồ côi, hãy chuyển nó sang một bên thay vì xóa, xác nhận kết nối rồi mới xóa khi trạng thái chạy được đã ghi lại. Đổi tên giúp giữ giá trị cũ có thể khôi phục nếu hóa ra lỗi nằm ở chỗ khác.

Tách riêng những ký tự mà định dạng lưu trữ không chứa được

Tài liệu strongSwan về chuỗi bí mật chia sẻ nói rằng giá trị không được chứa ký tự xuống dòng hay dấu ngoặc kép. Một khóa dán từ tài liệu có thể mang một trong hai mà trong hộp thoại bình thường không thấy khác biệt gì.

Từ 1.2.12, giá trị được lưu không còn là văn bản thuần. Plugin mã hóa PSK bằng base64 trước khi nó đến tệp, và ghi chú phát hành nêu chính cách mã hóa đó là lý do dấu ngoặc kép nay được chấp nhận trong khóa. Vì vậy dấu ngoặc kép gõ vào trường là biểu diễn được; điều đó không đúng với mọi ký tự điều khiển.

Độ dài là một ràng buộc khác. Không có mức tối thiểu phổ quát cho phần mềm L2TP/IPsec: một số ứng dụng khách nhận khóa ngắn hơn hai mươi ký tự và một số cổng lại áp đặt mức tối thiểu. Nếu một khóa ngắn bị từ chối, quy tắc đó thuộc về chính sách máy chủ hoặc bước kiểm tra của ứng dụng khách ấy, và nâng thứ gì đó ở máy cục bộ sẽ không thay đổi được.

Đọc xem tầng xác thực nào đã thất bại

Chạy ipsec --version trước, vì strongSwan và Libreswan dùng tên tệp và cú pháp khác nhau, và lời khuyên cho cái này có thể làm hỏng cái kia. Sau đó đọc giai đoạn thất bại từ thông báo của ứng dụng khách hoặc nhật ký của daemon: phàn nàn về khóa chia sẻ trước là sự kiện khác với việc tên người dùng và mật khẩu bị từ chối.

PSK xác thực hai đầu của đường hầm. Tên người dùng và mật khẩu xác thực con người bên trong L2TP, và PPP xử lý chúng sau khi liên kết IPsec đã lên. PSK đúng mà tài khoản sai vẫn thất bại, và đổi tài khoản sẽ không sửa được một khóa mà daemon chưa bao giờ đọc đúng.

Khi đóng ticket, hãy ghi lại cả bốn điều: phiên bản plugin, tệp bí mật đang dùng, khóa được gõ lại hay dán, và tầng được nêu trong lỗi. Khi đó ai lặp lại lộ trình này về sau có thể nhảy thẳng tới khác biệt giữa máy chạy được và máy thất bại.