Giai đoạn VPN nào đã thất bại: IPsec, điều khiển L2TP hay xác thực PPP
Tìm giai đoạn thành công cuối cùng và chỉ sửa lớp đó: IPsec, kênh điều khiển L2TP, xác thực PPP hoặc cấp địa chỉ.
Bạn đổi mật khẩu và không có gì nhúc nhích, vì lỗi chưa bao giờ nằm ở PPP. L2TP/IPsec báo một lỗi kết nối cho năm lần bàn giao hoàn toàn khác nhau, và mỗi lần bàn giao có cách sửa riêng. Hãy làm ngược lại: tìm giai đoạn thành công cuối cùng và chỉ thay đổi những gì đến sau đó. Thứ tự dưới đây cũng quyết định bạn thu thập bằng chứng nào trước.
Trả lời bốn câu hỏi theo thứ tự
Buộc một lần thử mới, vì một số máy khách tiếp tục hiển thị lỗi trước đó cho đến khi hồ sơ được ngắt và kết nối lại. Sau đó trả lời: có liên kết bảo mật IPsec không, kết nối điều khiển L2TP và cuộc gọi có xuất hiện không, PPP có đi đến phán quyết xác thực không, và IPCP có cấp địa chỉ cho máy khách không? Không đầu tiên là giai đoạn bạn sửa. Mọi thứ sau đó chưa được kiểm tra, nên một tên người dùng bị từ chối không chứng minh gì khi chưa từng có liên kết.
Đồng bộ đồng hồ ở hai đầu trước khi so sánh. Lần thử lại đã dọn sạch IPsec và thất bại ở PPP trông như một lỗi duy nhất khi máy khách chỉ hiển thị thông báo cuối cùng và nhật ký máy chủ vẫn giữ lần thử trước. Đọc theo dấu thời gian, không theo dòng ồn ào nhất.
Khi chỉ có ảnh chụp màn hình của người dùng, hãy dựa vào cách tách rẻ nhất: khóa chia sẻ trước sai và xl2tpd không bao giờ trả lời tạo ra cùng văn bản trong hộp thoại Windows, nhưng một cái cần bí mật thay đổi ở cả hai đầu và cái kia cần daemon được khởi động hoặc quy tắc tường lửa trên chính máy chủ. Thiết bị ở giữa không thể bỏ 1701 bên trong sau khi IPsec chế độ vận chuyển đã bọc nó, nên đừng tìm bộ lọc đường đi không tồn tại.
Mỗi lớp thực sự sở hữu gì
IPsec bảo vệ gói giữa hai đối tác; L2TP mang phiên PPP bên trong đường dẫn được bảo vệ đó, vì vậy RFC 3193 quy định chế độ vận chuyển thay vì đường hầm riêng. Nhãn máy khách nói L2TP, nên đường hầm và đăng nhập có vẻ như một cơ chế. Không phải: kết nối điều khiển L2TP xác thực các đầu đường hầm nơi triển khai bật nó, và PPP xác thực người dùng riêng bằng CHAP, PAP hoặc MS-CHAPv2 theo chính sách máy chủ.
Cách tách này giải thích hai bí mật mà người ta liên tục nhầm lẫn. Khóa chia sẻ trước xác thực các đối tác IPsec. Tên người dùng và mật khẩu nhận diện người dùng với PPP. Gõ lại bí mật chia sẻ của Windows trên hồ sơ xác thực bằng chứng chỉ không thay đổi gì ở giai đoạn thất bại, và sửa mật khẩu PPP không thể cung cấp kênh được bảo vệ còn thiếu. Sự tiết chế tương tự áp dụng cho kiểm tra danh tính: đừng tắt danh tính đối tác hoặc xác thực chứng chỉ để có đường hầm, vì khi đó thứ kết nối là đường dẫn, không phải đối tác.
Xác thực cũng không phải kết thúc của PPP. Sau khi người dùng được chấp nhận, IPCP thương lượng địa chỉ máy khách và các tùy chọn DNS và WINS mà máy chủ sẵn sàng cấp. Máy khách có thể qua CHAP hoặc MS-CHAPv2 mà vẫn không có địa chỉ, đó là lỗi bên trong PPP chứ không phải vấn đề định tuyến. L2TP trơn không có IPsec vẫn hợp lệ và không được bảo vệ, nên một kết nối thành công không bao giờ chứng minh lưu lượng được bảo vệ; hãy kiểm tra máy chủ yêu cầu gì, không phải nhãn máy khách.
Quyết định từ giai đoạn thiếu đầu tiên
Đọc bảng theo mục thiếu đầu tiên, từ trái sang phải. Cột bên phải là công việc duy nhất đáng làm lúc đó; mọi thứ bên trái nó đã được chứng minh, và kiểm tra lại sẽ đốt cửa sổ gián đoạn mà không thêm thông tin.
| First thing missing | What it means | Change this |
|---|---|---|
| No IKE reply on 500 or 4500 | The path or the listener never answered | Firewall, NAT-T forwarding, server listener |
| IKE runs, no IPsec association | Identity, key, or proposal mismatch | Proposal and PFS set, pre-shared key, local and remote ID |
| Association up, no L2TP control connection | Inner signalling never reached xl2tpd | UDP 1701, tunnel and session sections, NAT encapsulation |
| Control connection up, PPP auth refused | The user or method was rejected | Credential format, allowed auth method, account policy |
| PPP auth accepted, no address assigned | IPCP never completed | Address pool in xl2tpd.conf, ms-dns and ms-wins in options.xl2tpd |
| Address assigned, applications fail | The inner path is wrong | Routes, DNS, MTU or MSS, server forwarding |
Ba hàng đáng được cảnh báo. Hàng 1701 là nơi máy khách Windows sau NAT thường hạ cánh: liên kết hoàn tất, rồi không có gì đến, và nguyên nhân là đóng gói chứ không phải mật khẩu tồi. Hàng IPCP là hàng bị đọc nhầm thành vấn đề tuyến, vì Windows bọc địa chỉ thiếu vào lỗi 720 và biểu tượng khay chỉ nói kết nối thất bại; lỗi đó nằm sau xác thực và trước định tuyến. Hàng cuối hoàn toàn không phải lỗi IPsec, dù biểu tượng nói đã ngắt.
Lệnh phân tách các lớp
Trên máy chủ Linux chạy strongSwan, swanctl --list-sas liệt kê các liên kết đã thiết lập kèm danh tính đối tác, và ipsec statusall bao gồm các máy chủ strongSwan và libreswan cũ hơn. Bên dưới, ip xfrm state hiển thị các liên kết thực của nhân, trong khi ss -lunp | grep 1701 chứng minh xl2tpd được gắn ở đâu. Chạy xl2tpd -D ở nền trước để thấy kết nối điều khiển và cuộc gọi xuất hiện, và bật gỡ lỗi pppd trong /etc/ppp/options.xl2tpd để thấy phương thức được đề nghị và câu trả lời.
Khi nhật ký cho thấy xác thực thành công, câu hỏi tiếp theo là IPCP đã hoàn tất chưa. Kiểm tra xem ip range trong phần [lns default] của /etc/xl2tpd/xl2tpd.conf còn địa chỉ trống không, và /etc/ppp/options.xl2tpd có thực sự mang ms-dns và ms-wins nếu máy khách mong đợi. Nhóm cạn và tùy chọn DNS thiếu trông khác nhau trên dây: cái đầu để máy khách không địa chỉ và có 720, cái sau cho địa chỉ nhưng không có bộ phân giải, nên tên thất bại trong khi ping tới địa chỉ thô vẫn chạy. Không cái nào sửa được bằng cách gõ lại mật khẩu.
Trên máy khách, plugin L2TP của NetworkManager ghi cuộc trò chuyện pppd vào nhật ký, nên journalctl -u NetworkManager -b thường tách đường hầm lên, xác thực bị từ chối khỏi không có đường hầm nào. Trên Windows, Get-VpnConnection báo cáo cài đặt xác thực thực của hồ sơ, và các sự kiện RasClient dưới Application trong Event Viewer nêu tên thành phần thất bại. Khi hộp thoại quá mơ hồ, hãy bật netsh ras set tracing * enable.
Việc bắt gói cần một lưu ý. Với IPsec chế độ vận chuyển, UDP 1701 bên trong được mã hóa, nên bắt gói trên giao diện ngoài hiển thị ESP, hoặc UDP 4500 dưới NAT-T, và không có L2TP. Thiếu 1701 trong bản bắt gói là điều dự kiến và không phải bằng chứng cổng bị chặn; hãy xem bộ đếm ESP hoặc 4500 có nhúc nhích không.
NAT, MTU và tuyến: nơi ngăn xếp đánh lừa bạn
NAT phá vỡ giả định trước khi bất cứ điều gì được xác thực. ESP là giao thức IP riêng, nên thiết bị dịch bỏ nó trừ khi các đối tác đóng gói; chính UDP 4500 cung cấp điều đó. Trên máy chủ Windows tự đứng sau router gia đình hoặc cổng NAT đám mây, giai đoạn IPsec thất bại với lỗi 789 cho đến khi AssumeUDPEncapsulationContextOnSendRule được đặt thành 2 dưới khóa PolicyAgent và máy khởi động lại, và lỗi vẫn không thể phân biệt với cổng đóng. Máy khách sau NAT dễ hơn: khi máy chủ có địa chỉ công cộng, NAT-T trên UDP 4500 mang chúng và giá trị đó không tham gia.
Khi PPP đã lên, MTU có lỗ đen mô phỏng đường hầm chết: gói nhỏ đi qua, bắt tay TLS hoặc tải trang bị treo, và máy khách có thể vẫn hiển thị đã kết nối. Hạ MTU giao diện hoặc siết MSS ở cổng trước khi đổ lỗi cho máy chủ. Định tuyến đường hầm chia tách là kẻ giả mạo khác; một mạng con được đẩy với mặt nạ sai để đường hầm khỏe mạnh và một ứng dụng không thể đến. Tên máy chủ riêng thêm bước của nó: nếu truy vấn đi ra qua bộ phân giải cục bộ, tên không được phân giải trước khi bất kỳ tuyến nào được kiểm tra.
Danh sách kiểm tra trước khi chạm vào thông tin đăng nhập
Làm danh sách theo thứ tự và dừng ở mục thất bại đầu tiên. Mỗi bước đều rẻ, và mỗi bước loại trừ cả một lớp chỉnh sửa.
- Xác nhận liên kết tồn tại ở cả hai đầu, khớp theo danh tính đối tác chứ không theo nhãn đã kết nối.
- Xác nhận UDP 1701 đến được xl2tpd; liên kết không có cuộc gọi chính là lỗi của bạn.
- Đọc phán quyết của PPP và, nếu đã xác thực, kết quả IPCP, trước khi cho rằng mật khẩu sai.
- Chỉ bây giờ hãy nhập lại thông tin đăng nhập theo định dạng máy chủ mong đợi, vì tiền tố miền thay đổi tài khoản.
- Nếu vẫn thất bại, hãy bắt gói ở cả hai đầu với dấu thời gian căn chỉnh và so sánh từng giai đoạn.
Dừng ở bước hai nghĩa là vấn đề đường dẫn hoặc đóng gói, và không chỉnh sửa mật khẩu nào làm nó nhúc nhích. Dừng ở bước ba nghĩa là nhật ký đã nêu tên phương thức hoặc nhóm địa chỉ cần sửa. Dù thế nào, thay đổi tiếp theo là thứ bạn có thể biện minh, và bạn ngừng xoay vòng qua các cài đặt chưa bao giờ tham gia.