LCP bị đầu kia chấm dứt trên PPTP: bật MPPE trước

Liên kết xác thực thành công, máy khách báo đã kết nối, và một giây sau nhật ký đóng lại với dòng LCP bị đầu kia chấm dứt. Dòng đó đến từ quá trình thương lượng PPP bên trong đường hầm GRE, nghĩa là phần vận chuyển đã hoạt động và hai đầu không thống nhất về các tùy chọn liên kết. Mật khẩu và địa chỉ máy chủ thường vô can ở đây. Chính sách mã hóa là thứ đầu tiên cần so sánh, và trên Linux tệp đầu kia của pppd là nơi đầu tiên cần xem.

Lỗi LCP nói gì về giai đoạn PPP

PPTP bọc PPP bên trong GRE: kết nối điều khiển TCP 1723 thiết lập cuộc gọi, GRE mang tải trọng, rồi LCP thương lượng các tùy chọn như giao thức xác thực, nén và MPPE. Đầu kia chấm dứt LCP khi một tùy chọn bắt buộc không được chấp nhận ở phía họ. Nhật ký trong đó trao đổi CHAP hoặc MSCHAPv2 hoàn tất và LCP kết thúc ngay sau đó là từ chối chính sách, không phải lỗi khả năng tiếp cận. Nếu đường hầm không hề tới được thương lượng, hãy kiểm tra pppd và plugin của nó trước khi đọc dòng LCP.

Hai điều kiện tiên quyết dễ bị bỏ sót. Tệp nhị phân pppd phải tồn tại, và plugin PPTP được nêu trong tệp đầu kia phải được cài đặt; một gói thiếu sẽ kết thúc cuộc gọi trước khi bất kỳ tùy chọn nào được bàn tới.

Bật MPPE ở phía yêu cầu nó

Quyết định thật sự là đầu nào nắm chính sách mã hóa. Máy khách có thể đề nghị MPPE, yêu cầu hoặc từ chối, và máy chủ cũng chọn như vậy. Khi cả hai cùng yêu cầu, liên kết dựng lên; khi một bên yêu cầu còn bên kia từ chối, LCP kết thúc.

pty "pptp vpn.example.net --nolaunchpppd"
name alice
remotename PPTP
require-mppe-128

Nạp mô-đun bằng modprobe ppp_mppe trước khi quay số, vì require-mppe-128 sẽ thất bại nếu thiếu nó. Trên Windows, điều khiển tương đương là tab bảo mật của mục VPN, nơi phải yêu cầu máy khách đòi mã hóa thay vì chấp nhận bất cứ thứ gì máy chủ đưa ra. Nếu máy chủ vẫn chấm dứt LCP, hãy hỏi người vận hành xem MPPE là bắt buộc, tùy chọn hay bị tắt, vì máy khách không thể thương lượng một sự bảo vệ mà máy chủ từ chối. Tắt mã hóa để thông báo biến mất là hướng sai: nó bỏ đi sự bảo vệ duy nhất mà giao thức này có.

Lưu tệp đầu kia đang hoạt động trước khi sửa nó. Một dòng require-mppe gõ sai tái tạo đúng lỗi LCP chung đó và đưa bạn về điểm xuất phát.

Đọc nhật ký của chính pppd thay vì applet

Applet trên màn hình chỉ hiện việc ngắt kết nối và giấu lý do, nên hãy đọc tường trình của daemon về một lần thử. Trên hệ thống systemd thông báo đi vào journal; cấu hình cũ hơn ghi vào các tệp nhật ký truyền thống.

journalctl --since "10 min ago" | grep -i -E "pppd|lcp|mppe"
tail -n 50 /var/log/syslog

Tìm trong một cửa sổ quanh một cuộc gọi duy nhất thay vì cả ngày kết nối lại, để tùy chọn bị từ chối dễ thấy. pppd thường nêu tên tùy chọn và câu trả lời của đầu kia, điều đó cho biết nên đổi đề xuất của mình hay đề nghị phía máy chủ nới yêu cầu. Giữ các lần thử có dấu thời gian, vì so sánh hai nhật ký chỉ hữu ích khi bạn biết dòng nào thuộc cuộc gọi nào. Khi không thấy trao đổi LCP nào cả, lỗi nằm sớm hơn trong chuỗi và MPPE không phải nghi phạm.

Giữ bản sửa qua các lần kết nối lại: tên hook và MTU

Khi liên kết đã đứng vững, hai chi tiết quyết định nó có sống qua lần kết nối lại hay không. Hook nằm trong /etc/ppp/ip-up.d và /etc/network/if-up.d, và run-parts xử lý cả hai thư mục, với bộ lọc tên tệp từ chối mọi thứ có dấu chấm. Vì vậy script tên set-pptp.sh bị bỏ qua, còn set-pptp được thực thi. Kiểm tra tên trước khi gỡ lỗi nội dung script, rồi đặt MTU nhỏ hơn từ bên trong hook đó để mỗi giao diện ppp mới kế thừa mà không cần lệnh thủ công.

run-parts --test /etc/ppp/ip-up.d
ip link set dev ppp0 mtu 1200

Để kết thúc phiên có chủ đích, hãy nhắm vào pid mà pppd đã ghi lại thay vì khớp mẫu tên tiến trình, vì giết mọi thứ chứa ppp cũng xé bỏ những liên kết không liên quan. PPTP đã lỗi thời và MS-CHAPv2 yếu, nên hãy coi những kiểm tra này là bảo trì cho một liên kết cần tiếp tục hoạt động, không phải lý do để triển khai PPTP ở bất kỳ đâu mới.