Thiếu PPTP passthrough: sửa lỗi 807 của VPN trên Windows

Chuyển tiếp TCP 1723 thường chỉ dọn được phần đầu của PPTP và để phần còn lại hỏng, nên Windows vẫn trả về lỗi 807 khi thử kết nối. Phản xạ tiếp theo là thêm quy tắc cho cổng 47, và chính bước đó làm mất cả một buổi chiều: GRE là số giao thức trong tiêu đề IP, không phải cổng mà bảng chuyển tiếp có thể khớp. Cho đến khi bộ định tuyến cho giao thức 47 đi qua và gắn nó với cùng cuộc gọi, đường hầm không thể khởi động. Các phần dưới đây tách hai kênh, rồi kiểm tra từng kênh một.

Bảng cổng không có hàng cho số giao thức

PPTP dùng hai cuộc trò chuyện thất bại theo cách khác nhau. Cuộc trò chuyện trên TCP 1723 bắt đầu cuộc gọi, truyền thông tin liên kết và xé nó khi người dùng ngắt kết nối. Phía tải trọng chạy bên trong GRE, thứ mà tiêu đề IP gắn nhãn số giao thức 47, và bên trong đường hầm đó PPP thương lượng liên kết trong khi MS-CHAPv2 kiểm tra thông tin đăng nhập.

Vì GRE không mang tiêu đề vận chuyển, nó không lộ ra cổng nào, nên một quy tắc viết cho cổng không có gì để khớp. Bộ định tuyến chuyển tiếp 1723 tạo một ánh xạ cho phiên TCP đó và dừng ở đó. Phần sụn phụ trách nửa sau gọi tính năng này là PPTP passthrough hoặc PPTP ALG, và một số phần sụn không cung cấp cái nào và không bao giờ nhắc đến khoảng trống này. Nhãn trên hộp kiểm ít quan trọng hơn việc giao thức 47 có được nhận ra hay không.

Windows báo gì khi đường dữ liệu chết

Lỗi 807 nói rằng không thể hoàn tất kết nối, trên thực tế nghĩa là cuộc gọi đã tới máy chủ nhưng kênh dữ liệu không lên. Đó là phán quyết về vận chuyển, không phải về tài khoản. Lỗi 691 là lỗi chỉ vào thông tin đăng nhập hoặc sự không khớp giao thức xác thực, nên nó đưa bạn đến nơi hoàn toàn khác.

Hãy làm việc trên phần vận chuyển trước khi chạm vào mật khẩu. Thay thông tin đăng nhập để đuổi theo 807 để nguyên lỗi thật và khiến lần thử sau khó đọc hơn.

Vì sao máy khách thứ hai phá đường hầm đang chạy

Không có cổng để phân biệt, thiết bị NAT không thể tách hai máy khách PPTP như cách nó tách hai phiên HTTPS. Vì vậy nhiều thiết bị tiêu dùng chỉ cho phép một cuộc gọi PPTP và theo dõi nó theo địa chỉ nguồn. Một máy tính xách tay chạy một mình ngừng hoàn tất khi máy thứ hai gọi ra, và từ phía máy khách lỗi trông có vẻ ngẫu nhiên. Kiểu đó thuộc về phần sụn, và không thay đổi hồ sơ nào làm nó khác đi.

Xem bảng kết nối trong khi cả hai máy khách gọi. Nếu chỉ máy chủ đầu tiên từng giữ ánh xạ, bộ định tuyến đã chạm giới hạn của những gì nó hỗ trợ và không cài đặt phía máy khách nào làm nó nhúc nhích.

Chứng minh nửa nào đang hỏng

Xác nhận TCP 1723 đến trước khi thay đổi bất cứ thứ gì trên bộ định tuyến, vì câu trả lời đó quyết định nửa nào bạn đang kiểm tra. Chạy chúng từ máy khách Windows với tên máy chủ của chính bạn. Lệnh đầu in ra liệu cổng có trả lời, lệnh thứ hai quay số không có hộp thoại, điều này khiến các lần thử lặp lại so sánh được.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Kết quả đúng trong phép thử cổng nghĩa là kênh điều khiển đang mở và GRE là nghi phạm còn lại. Kết quả sai nghĩa là định tuyến, bộ lọc hoặc chuyển tiếp bị hỏng, và không thay đổi GRE nào cứu được. Phía dữ liệu phải được theo dõi ở nơi có thể thấy, ở đầu máy chủ hoặc ở bộ định tuyến.

tcpdump -ni any proto 47

Tương đương trong Wireshark là bộ lọc hiển thị ip proto 47, dễ đưa cho người không quen shell hơn. GRE đến mà không có gì rời đi để trả lời nghĩa là đường về cần được sửa.

Điều gì thực sự sửa lỗi

Ở nơi bộ định tuyến để lộ cài đặt, hãy bật PPTP passthrough, hoặc cho phép giao thức 47 một cách rõ ràng trên phần sụn chấp nhận quy tắc. Trên RouterOS, quy tắc forward khớp trực tiếp với giao thức, điều mà chuyển tiếp dựa trên cổng không bao giờ làm được. Phần sụn tiêu dùng thường giấu quyết định đó sau một hộp kiểm, đôi khi nằm dưới cài đặt bảo mật thay vì dưới chuyển tiếp cổng. Nếu không có điều khiển như vậy, không gì phía máy khách bù đắp được.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Thay PPTP là phương án khác và thường rẻ hơn. Một bộ định tuyến tự kết thúc VPN tránh NAT kép cho các máy khách đến, và một giao thức mà NAT dựa trên cổng đã xử lý thì không cần passthrough chút nào: OpenVPN qua UDP, SSTP qua TCP 443, hoặc L2TP/IPsec với NAT-T bọc ESP trong UDP 4500. PPTP cũng phụ thuộc vào MS-CHAPv2, mà những điểm yếu được ghi nhận khiến nó thành lựa chọn kém cho triển khai mới ngay cả sau khi lỗi đã hết.

Ghi lại quy tắc nào tạo ra khác biệt, vì cùng site đó sẽ gặp cùng giới hạn khi người dùng thứ hai yêu cầu truy cập. Bản sửa ở mức giao thức thuộc về ghi chú mạng, nơi kỹ sư tiếp theo sẽ xem.