Lỗi ghi GRE trên pptpd không phải vấn đề mật khẩu

Lỗi ghi GRE trong nhật ký, và phản xạ đầu tiên là đặt lại mật khẩu của người dùng. Phản xạ đó gần như luôn sai. Những thông báo này mô tả đường đi của dữ liệu, không phải việc kiểm tra thông tin xác thực: máy khách có thể đã xác thực thành công và sau đó bị kẹt ở giai đoạn đăng ký trên mạng. Hai thông báo khác nhau chỉ ra hai lỗi khác nhau, và không lỗi nào được giải quyết bằng mật khẩu mới.

Hai thông báo, hai lỗi khác nhau

Lỗi đọc nghĩa là các gói GRE không bao giờ đến được daemon, hoặc bị bỏ đi trên đường vào. Kết nối điều khiển có thể trông hoàn toàn khỏe mạnh trong khi không có gì đi qua đường dữ liệu. Xác thực là điều duy nhất đã chứng minh được là hoạt động.

Lỗi ghi thường có nghĩa là phiên đã thương lượng một thứ mà nhân hệ điều hành hoặc máy khách không thể dùng. Kênh điều khiển đã hoàn tất, và các tùy chọn được thỏa thuận trong trao đổi đó không khớp với những gì các điểm cuối thực sự có thể làm. Đó là sự bất đồng cấu hình, không phải sự kiện xác thực.

Đọc xem trong hai lỗi cái nào xuất hiện trước khi thay đổi bất cứ điều gì. Chúng dẫn bạn đến các tầng khác nhau, và việc coi chúng là một triệu chứng là lý do cùng một máy chủ bị vá hai lần vì những lý do không liên quan. Dòng nhật ký là chẩn đoán miễn phí duy nhất bạn có.

Giao thức 47 không phải cổng 47

PPTP dùng TCP 1723 để thiết lập cuộc gọi và GRE để mang tải trọng. GRE là giao thức IP 47, không phải số cổng, nên một quy tắc tường lửa mở cổng 47 không cho phép điều gì hữu ích.

Bộ định tuyến trên đường đi cần tính năng passthrough PPTP hoặc sự cho phép GRE rõ ràng. Không có nó, bắt tay TCP hoàn tất và đường hầm không bao giờ mang gói nào, điều này tạo ra đúng lỗi đọc ở trên. Các quy tắc cổng 47 trong tường lửa là buổi chiều bị lãng phí nhiều nhất trong giao thức này.

Quan sát cả hai hướng cùng lúc trên máy chủ thay vì đoán bên nào bỏ lưu lượng: tcpdump -ni any port 1723 or proto gre.

Nếu 1723 cho thấy việc thiết lập cuộc gọi trong khi GRE im lặng, chặn nằm phía trên máy chủ. Nếu GRE đến mà daemon vẫn thất bại, vấn đề là cục bộ và các tùy chọn là nơi tiếp theo cần xem.

Cho phép GRE ở nơi máy chủ thực sự chuyển tiếp

Chèn một quy tắc forward cho GRE là phép thử hợp lý trên máy chủ chuyển tiếp lưu lượng đường hầm, và đó không phải chính sách. Một quy tắc thử nghiệm chấp nhận mọi thứ của một giao thức là chẩn đoán, không phải thiết kế. Để nó đủ lâu để học được điều gì đó, rồi thay bằng quy tắc giới hạn.

Thêm một quy tắc input cho các gói được gửi đến chính máy chủ, vì chuỗi forward không thấy chúng. Sau đó xem bộ đếm của quy tắc trước và sau khi thử kết nối, điều này cho biết các gói có đến hay không.

Làm cho quy tắc tồn tại lâu dài qua dịch vụ tường lửa của bản phân phối thay vì chạy lại sau mỗi lần khởi động lại. Trên máy chủ nftables, khớp ip protocol gre ở cả chuỗi input và forward.

Xác nhận rằng mô-đun ppp_generic cũng đã được nạp, và kiểm tra xem theo dõi kết nối có bỏ hướng trả về không. Cả hai đều tạo ra lỗi trông giống vấn đề tường lửa mà không phải. Một mô-đun nhân bị thiếu trông đúng như giao thức bị chặn cho đến khi bạn kiểm tra.

Khớp các tùy chọn với máy khách mà bạn thực sự có

Bản sửa từ báo cáo kia nằm trong /etc/ppp/pptpd-options, nơi công thức từ chối PAP, CHAP và MSCHAP, chú thích các dòng require tương ứng và giữ MPPE có trạng thái. Công thức đó được viết cho một hỗn hợp máy khách, và sao chép mù quáng sẽ phá vỡ trường hợp thông thường. Hãy đọc các dòng từ chối như một tuyên bố về việc tác giả có những máy khách nào, không phải như một khuyến nghị.

Máy khách Windows thường cần MS-CHAPv2 với MPPE-128. Giữ các yêu cầu đó và chỉ gỡ những tùy chọn mà máy khách thực sự không thể thương lượng.

# keep encryption; drop only what this client cannot negotiate
refuse-pap
refuse-chap
refuse-mschap
mppe-stateful
require-mschap-v2
require-mppe-128

Tắt mã hóa để một kết nối thành công là hạ cấp, không phải sửa chữa. Hãy thử biến thể như vậy trên một liên kết phòng thí nghiệm, rồi khôi phục mã hóa trước khi dịch vụ gặp máy khách thật. Kết nối hoạt động không an toàn còn tệ hơn kết nối thất bại một cách trung thực.

Đọc số lỗi của máy khách

Mã số của máy khách thu hẹp giai đoạn nhanh hơn nhật ký máy chủ. Hãy đọc nó trước khi đọc bất cứ thứ gì khác. 691 nghĩa là thông tin xác thực bị từ chối, 721 nghĩa là máy chủ không bao giờ trả lời, và 619 nghĩa là kết nối bị ngắt. Hai phút với con số tiết kiệm một giờ với cấu hình.

So sánh mã đó với nhật ký máy chủ trước khi chỉnh sửa bất cứ điều gì, và thử lại với cùng máy khách sau mỗi thay đổi. Nếu không, lỗi thứ hai ẩn sau lỗi thứ nhất và bản sửa có vẻ không hiệu quả.

Khi đăng nhập thành công và không có lưu lượng nào di chuyển, GRE vẫn là nghi phạm. Đó là lúc quay lại bản ghi bắt gói thay vì kho thông tin xác thực.