L2TP kết nối được nhưng thương lượng PPP thất bại: giai đoạn nào?

Đường hầm IPsec được thiết lập, máy khách hiển thị một đối tác được bảo vệ, rồi kết nối chết trước khi bất cứ thứ gì đến được mạng con riêng. Khoảng trống đó là PPP đang làm việc của chính nó: tùy chọn liên kết, xác thực người dùng và cấp phát địa chỉ đều diễn ra sau khi đường hầm mã hóa đã tồn tại. Không có gì trong một lần trao đổi giai đoạn một thành công cung cấp mật khẩu hay địa chỉ bên trong. Đọc các giai đoạn theo thứ tự và lỗi thường tự gọi tên mình.

Đường hầm chỉ là lớp đầu tiên

L2TP mang khung PPP bên trong một đường hầm được IPsec bảo vệ, nghĩa là hai cuộc thương lượng độc lập phải thành công trước khi một gói tin có thể được định tuyến. Phía ngoài chứng minh hai đầu đồng ý về khóa và danh tính. Phía trong quyết định tham số liên kết, liệu người dùng có được xác thực và máy khách nhận địa chỉ nào.

Một lỗi bên trong PPP trông như đường hầm hỏng ở mọi máy khách chỉ hiển thị một đèn trạng thái. Nếu coi đó là sự cố đường hầm, ta sẽ đi đến việc tạo lại khóa, khởi động lại dịch vụ và cuối cùng là thay một bí mật chia sẻ chưa bao giờ sai. Sự phân biệt hữu ích thì rẻ: nếu trao đổi với đối tác đã xong và máy khách đã chuyển sang nhắc tên người dùng hoặc giai đoạn xác thực, đường hầm vẫn tốt. Mọi thứ sau điểm đó thuộc về PPP.

Đọc giai đoạn cuối cùng thành công

Đi xuôi nhật ký và dừng ở giai đoạn đầu tiên chưa hoàn tất. LCP đến trước, rồi xác thực, rồi IPCP cho các tham số IPv4.

sudo journalctl -u xl2tpd -b --no-pager | tail -n 40
sudo journalctl -b --no-pager | grep -i -E 'pppd|lcp|chap|ipcp'
ip -4 address show ppp0

Hết thời gian LCP nghĩa là hai đầu chưa bao giờ thống nhất về các tùy chọn liên kết cơ bản, đó là hồ sơ không khớp hoặc giao thức bên trong bị chặn, không phải mật khẩu tồi. Việc từ chối xác thực rõ ràng là trường hợp ngược lại: liên kết đã lên và một bên từ chối thông tin đăng nhập. Hết thời gian IPCP sau khi xác thực thành công chỉ ra nhóm địa chỉ hoặc chính sách máy chủ. Mỗi trường hợp có chủ sở hữu khác nhau và cách sửa khác nhau, vì thế giai đoạn quan trọng hơn văn bản lỗi cuối cùng.

Giữ đoạn trích nhật ký cùng tên giai đoạn trong phiếu. Một cái đuôi được dán mà không có ranh giới giai đoạn mời người đọc sau đoán mò, và đoán mò ở đây tốn một giờ.

Thỏa thuận giữa máy khách và máy chủ

Hai đầu phải chấp nhận cùng một phương thức xác thực, và một hồ sơ đã lưu có thể yêu cầu phương thức mà máy chủ đã ngừng dùng vào quý trước. Các triển khai được quản lý cũng che phía máy chủ, nơi lý do từ chối thường được ghi cho người dùng chứ không phải thiết bị.

Bật một phương thức được hỗ trợ thay vì mọi tùy chọn cũ, vì máy khách đưa ra năm phương thức sẽ che mất phương thức nào đã hỏng. Hỏi quản trị viên về chính sách phía máy chủ và lý do từ chối chính xác, việc này không đòi hỏi ai phải công bố mật khẩu. Một phương thức cũ được bật để cứu một máy khách thường lan sang mọi hồ sơ sao chép tệp đó.

Kiểm tra địa chỉ, không phải đăng nhập

Đăng nhập xong chưa phải là phiên dùng được. IPCP thương lượng địa chỉ bên trong, và một nhóm địa chỉ cạn hoặc chính sách từ chối máy khách vẫn có thể để lại một đường hầm đã kết nối mà không có gì để định tuyến.

ip -4 address show ppp0
ip route get 10.52.9.1
ping -c 2 10.52.9.1

Kiểm tra địa chỉ bên trong trước, rồi đến tuyến và trình phân giải cho tài nguyên bạn thực sự cần. Địa chỉ bên trong không phải cửa ra công cộng mà một trang web báo cáo, và nhầm lẫn hai thứ đó khiến người ta đi tìm một rò rỉ không tồn tại. Thử tài nguyên riêng bằng địa chỉ trước khi thử bằng tên, để lỗi DNS không bị hiểu nhầm là lỗi định tuyến.

Viết giai đoạn, phương thức và địa chỉ vào một ghi chú rồi ghi ngày. Nếu cùng tài khoản lại hỏng sau một tháng, ghi chú đó là khác biệt giữa một lần kiểm tra năm phút và một cuộc điều tra mới. Hỏng ở các giai đoạn khác nhau là những sự cố khác nhau, kể cả khi máy khách chỉ hiển thị một hộp thoại.