Lỗi PPTP 800 so với 812 và mất kết nối sau một phút

Ba thông báo lỗi từ một máy khách PPTP thường mô tả ba sự cố khác nhau. Lỗi 800 nghĩa là đường hầm chưa bao giờ được tạo, lỗi 812 nghĩa là máy chủ từ chối phương thức xác thực, và mất kết nối sau một phút là bộ hẹn giờ keepalive quyết định rằng một đầu bên kia khỏe mạnh đã biến mất. Mỗi giai đoạn thất bại vì lý do của riêng nó, nên mỗi giai đoạn cần kiểm tra riêng.

Lỗi 800 nghĩa là đường hầm chưa bao giờ được tạo

Windows đưa ra lỗi 800 khi nó hoàn toàn không thể dựng đường hầm, và đoạn văn về máy chủ không thể truy cập hoặc tham số bảo mật không phù hợp là bản tóm tắt chứ không phải chẩn đoán. PPTP cần hai thứ riêng biệt từ mạng trước khi bất kỳ thông tin đăng nhập nào được xem xét. TCP 1723 mang kênh điều khiển, và giao thức IP 47, tức GRE, mang tải trọng đã được đóng gói.

Hãy kiểm tra con đường bên ngoài đó từ bên ngoài LAN của chính bạn, vì một kết nối hoạt động trong văn phòng không chứng minh được gì về biên:

$ nc -vz vpn.example.net 1723
Connection to vpn.example.net 1723 port [tcp/*] succeeded!
$ sudo tcpdump -ni eth0 proto gre
tcpdump: listening on eth0, link-type EN10MB

Nếu 1723 trả lời và bản ghi vẫn trống trong khi máy khách cố kết nối, đường đi đang bỏ giao thức 47. Một bộ định tuyến có 1723 được chuyển tiếp nhưng tắt passthrough PPTP tạo ra đúng mẫu đó: bắt tay TCP hoàn tất, sau đó các gói GRE biến mất, nên lỗi trông giống vấn đề thông tin đăng nhập dù không có lần đăng nhập nào được thử.

Hướng chuyển tiếp tới địa chỉ LAN hiện tại của máy chủ, bật passthrough PPTP ở nơi bộ định tuyến cung cấp, và thử lại từ cùng điểm bên ngoài. Khi GRE bị lọc ở phía trên và bạn không thể thay đổi điều đó, SSTP qua TCP 443 hoặc L2TP/IPsec qua UDP 500 và 4500 có cơ hội tốt hơn bất kỳ thay đổi nào bạn có thể làm ở phía Windows.

Lỗi 812 là việc máy chủ từ chối phương thức xác thực của bạn

Lỗi 812 quay lại sau khi đường hầm đã lên, vì thế nó có cảm giác như vấn đề mật khẩu. Máy chủ từ chối phương thức xác thực đã thương lượng cho kết nối, không nhất thiết là chính mật khẩu. Trên máy khách, mở mục VPN, vào thẻ bảo mật, đặt loại thành Point-to-Point Tunneling Protocol, chọn danh sách giao thức rõ ràng và đánh dấu Microsoft CHAP phiên bản 2.

Bạn có thể đọc cài đặt hiện tại mà không cần nhấp qua hộp thoại:

$ Get-VpnConnection -Name "Office" | Select-Object -ExpandProperty AuthenticationMethod
MsChapv2

Một máy chủ yêu cầu MS-CHAP v2 sẽ từ chối máy khách bị để trên PAP hoặc trên loại tự động thương lượng thứ gì đó yếu hơn, và lỗi đến trước khi bất kỳ mật khẩu người dùng nào được đánh giá. Định dạng tài khoản là nửa còn lại của cùng sự từ chối đó. Trong một trường hợp, Windows gửi danh tính tài khoản Microsoft có dạng MicrosoftAccount\[email protected] trong khi máy chủ muốn tài khoản cục bộ hoặc miền. Việc gõ SERVERNAME\username báo cho Windows biết kho tài khoản nào cần tra cứu và xóa lỗi. Hãy nhập tên bằng tay thay vì để thông tin đăng nhập đã lưu lặp lại định dạng trước đó.

Mất kết nối sau một phút là một quyết định keepalive

Khi đường hầm kết nối, cho một ít lưu lượng đi qua rồi ngắt kết nối, hãy xem hành vi phản hồi LCP của máy chủ trước khi chạm vào máy khách. Tiến trình nền định kỳ yêu cầu đầu bên kia xác nhận nó vẫn ở đó. Nếu quá ít câu trả lời đến trong ngân sách đã cấu hình, phiên bị phá bỏ dù người dùng vẫn còn một liên kết hoạt động.

Trên máy chủ Linux pptpd, các giá trị đó sống trong /etc/ppp/options.pptpd, và cách sửa thông thường là mở rộng ngân sách chứ không phải rút ngắn khoảng thời gian:

# /etc/ppp/options.pptpd
lcp-echo-failure 30
lcp-echo-interval 5
# then
sudo systemctl restart pptpd

Ba mươi lần trượt trong khoảng năm giây tha thứ cho một lần khựng ngắn thay vì tuyên bố đầu bên kia đã đi. Giảm số đếm xuống một hoặc hai biến jitter thông thường trên một đường đã dịch thành ngắt kết nối khoảng mỗi phút. Nếu máy chủ của bạn là Windows RRAS chứ không phải pptpd, hãy xem thay vào đó thời gian chờ phiên PPP và chính sách ngắt kết nối khi không hoạt động. Những thứ đó sống ở nơi khác, và việc sửa một tệp pppd không tồn tại sẽ không thay đổi gì.

Các mạng con chồng lấn làm hỏng đường dữ liệu

Một đường hầm PPTP có thể xác thực sạch sẽ và vẫn không đến được đâu khi cả hai trang dùng cùng một dải riêng, ví dụ 192.168.1.0/24 ở văn phòng và ở nhà. Máy khách không thể cho biết một địa chỉ nhất định trỏ tới máy chủ nào, và một số ngăn xếp từ chối cài đặt tuyến đường hoàn toàn thay vì chọn một.

Coi đó là lỗi thiết kế và đánh số lại một bên, hoặc cấp cho máy khách một dải truy cập được dịch có chủ ý. Gỡ lỗi máy khách PPTP không thể sửa không gian địa chỉ tồn tại hai lần, và triệu chứng sẽ tiếp tục trông như mất kết nối ngẫu nhiên.

Bắt đầu từ giai đoạn đã thất bại: GRE cho 800, phương thức và chuỗi tài khoản cho 812, cài đặt phản hồi cho một đường hầm chết theo lịch.