PPTP trong Docker xác thực được nhưng không mang lưu lượng

Máy khách xác thực, PPP thương lượng một địa chỉ, rồi không gì chuyển động. Ping thất bại, trình duyệt thất bại, và container trông như đã kết nối suốt thời gian. Kiểu mẫu đó không phải vấn đề bảng định tuyến, vì các vấn đề định tuyến thường phá cả kết nối điều khiển. Đây là đường đi của tải trọng, và trong PPTP tải trọng là một giao thức khác với giao thức vừa thành công.

Năm kiểm tra, theo thứ tự tiết kiệm nhiều thời gian nhất.

Kiểm tra 1: tách kênh điều khiển khỏi tải trọng

PPTP xác thực qua TCP 1723 rồi mang tải trọng PPP bên trong GRE, giao thức IP 47. GRE không phải TCP cũng không phải UDP, nên mọi quy tắc chuyển tiếp cổng điều khiển không nói gì về nó. Một NAT hoặc tường lửa cho 1723 đi qua có thể bỏ rơi giao thức 47 mà không phàn nàn, và phiên vẫn nửa xây dựng theo cách trông giống thành công.

Nếu đăng nhập chạy được và không có gói nào quay lại, hãy giả định GRE trước rồi chứng minh sau.

Kiểm tra 2: xác nhận trình trợ giúp trong nhân của máy chủ

Theo dõi kết nối không thể liên kết một kết nối điều khiển TCP với một luồng GRE mà không có trình trợ giúp. Mô-đun là nf_conntrack_pptp, nó sống trong nhân của máy chủ, và nạp nó bên trong ảnh container không đạt được gì vì mô-đun áp dụng cho toàn bộ máy chủ. lsmod | grep nf_conntrack_pptp trên máy chủ Docker chính là kiểm tra. Nếu thiếu, modprobe nf_conntrack_pptp nạp nó cho nhân đang chạy và không nói gì về lần khởi động tiếp theo, nên hãy thêm nó vào cấu hình máy chủ.

Mô-đun biến mất khi khởi động lại sẽ thành cùng một phiếu vào tháng sau.

Kiểm tra 3: đọc chính sách nhân vô hiệu hóa nó

Ngay cả khi mô-đun có mặt, các nhân từ 4.7 đặt net.netfilter.nf_conntrack_helper mặc định là 0, điều này tắt việc gán trình trợ giúp tự động cho mọi giao thức. Chính mặc định đó là lý do một mô-đun được cài đúng vẫn không làm gì: mã có đó và chính sách nói không dùng. sysctl net.netfilter.nf_conntrack_helper báo giá trị hiện tại, và đặt nó thành 1 khi chạy làm trình trợ giúp có sẵn trở lại. Giữ giá trị qua cấu hình sysctl của máy chủ nếu thiết kế cho phép.

Gán tự động cho phép lưu lượng tạo kỳ vọng một cách ngầm định, và đó chính là lý do mặc định đã thay đổi. Giới hạn nó cho máy chủ tin cậy, hoặc dùng một quy tắc rõ ràng nhắm vào trình trợ giúp.

Kiểm tra 4: xem đường đi của container riêng ra

Một trình trợ giúp đã nạp không tạo ra tuyến đường. Container cần một đường đến máy chủ PPTP, và chuyển tiếp trên máy chủ phải cho phép GRE theo cả hai chiều: iptables -L FORWARD -v -n cho thấy giao thức 47 có được chấp nhận và các bộ đếm có nhúc nhích không. Các quy tắc masquerade của Docker dịch TCP và UDP, không dịch giao thức 47, nên một container có cầu có thể cần chấp nhận forward rõ ràng và, trên một số máy chủ, quy tắc dịch riêng. Cũng xác nhận rằng container có hỗ trợ thiết bị PPP mà ảnh của nó mong đợi.

Đọc các bộ đếm thay vì văn bản của quy tắc. Một quy tắc tồn tại mà không khớp với gì là đồ trang trí.

Kiểm tra 5: chứng minh GRE được theo dõi, rồi quyết định về PPTP

Khi máy khách đang chạy, đọc bảng theo dõi. Một mục điều khiển PPTP đã thiết lập cộng với một mục GRE liên quan nghĩa là trình trợ giúp đang liên kết các luồng và lỗi còn lại ở chỗ khác. Một mục điều khiển không có mục GRE nghĩa là tải trọng bị bỏ hoặc không được theo dõi, điều này đưa bạn trở lại kiểm tra 2 và 3.

Bản thân PPTP đã lỗi thời và MS-CHAPv2 yếu. Nếu máy chủ cũng cung cấp L2TP/IPsec, IKEv2 hoặc WireGuard, chuyển sang một trong số đó loại bỏ toàn bộ lớp vấn đề này.

Ở nơi PPTP phải ở lại, chạy máy khách trên máy chủ thay vì bên trong container loại bỏ một lớp NAT và lọc, điều thường là quyết định rẻ hơn.