Tunneling chia tách của PPTP không hoạt động: sửa đường GRE trước

Hãy xem một kết nối PPTP khởi lên và thật dễ tin rằng phần khó đã xong: máy khách xác thực, một adapter ppp0 hoặc WAN Miniport xuất hiện và cửa sổ trạng thái chuyển sang màu xanh. Sau đó yêu cầu đầu tiên tới một máy chủ nội bộ hết thời gian, và hồ sơ bị đổ lỗi. Trên thực tế có hai tầng độc lập cần xử lý: vận chuyển bên ngoài mang TCP 1723 và GRE, và chính sách bên trong quyết định đích nào dùng giao diện PPP. Trạng thái xanh chỉ chứng minh tầng đầu đã thương lượng; về tầng thứ hai nó không nói gì.

Theo dõi máy khách từ hồ sơ đến socket điều khiển

Mở nhật ký máy khách và tìm điểm nó liên hệ với máy chủ. PPTP trước tiên mở kết nối TCP tới cổng 1723 và thương lượng tham số tunnel qua kênh đó. Nếu bước này thất bại, mọi thứ sau đó không còn quan trọng, và lỗi thường nêu địa chỉ máy chủ hoặc thời gian chờ.

Xác nhận kết nối điều khiển trên đường truyền trước khi chạm vào bất kỳ tuyến nào. Trên máy khách hoặc cổng gương, bắt TCP 1723 cho một lần thử kết nối:

sudo tcpdump -ni any 'tcp port 1723' -c 20

Một bắt tay hoàn tất và phiên được thiết lập nghĩa là kênh điều khiển bên ngoài hoạt động. Một SYN không bao giờ nhận SYN-ACK chỉ ra tường lửa, địa chỉ máy chủ sai hoặc nhà cung cấp lọc cổng. Bắt tay xong rồi bị đặt lại ngay thường có nghĩa là máy chủ từ chối thông tin đăng nhập hoặc loại tunnel.

GRE là giao thức thứ hai, không phải cổng

PPTP mang tải trọng PPP bên trong GRE mở rộng, giao thức IP 47, thứ không có số cổng để router theo dõi. Đó là lý do một quy tắc cho phép TCP 1723 vẫn có thể để tunnel không có đường dữ liệu. Thiết bị NAT có trạng thái cần hiểu ID cuộc gọi bên trong GRE để ánh xạ phản hồi trở lại, và nhiều thiết bị không làm được. Đặc tả PPTP giữ kênh điều khiển và tải trọng GRE thành các phần riêng biệt, và kế hoạch kiểm thử của bạn cũng phải như vậy.

Theo dõi giao thức 47 trong cùng bản bắt, sau đó so sánh thứ đi ra với thứ quay về:

sudo tcpdump -ni any 'proto gre' -c 20

Các gói đi ra mà không có phản hồi, trong khi TCP 1723 vẫn khỏe, là dấu hiệu kinh điển của GRE bị chặn. Chuyển tiếp PPTP trên router tiêu dùng là tính năng của đúng phần firmware đó, nên một mạng khách sạn hoạt động không chứng minh gì về mạng tiếp theo. Nếu router không cung cấp chuyển tiếp và bạn không thể thay đổi nó, vấn đề là lựa chọn giao thức, không phải bảng tuyến.

Chứng minh tunnel di chuyển một gói

Khi GRE chảy, thương lượng PPP gán địa chỉ cho giao diện máy khách. Hãy đọc việc gán địa chỉ thay vì giả định:

ip -4 addr show ppp0

Ping địa chỉ đối tác được hiển thị là đích của liên kết điểm-điểm. Phản hồi ở giai đoạn này chứng minh đường đóng gói hoạt động từ đầu đến cuối và máy chủ trả lời bên trong tunnel. Nếu đối tác trả lời nhưng máy chủ nội bộ thì không, vận chuyển bên ngoài vẫn tốt và lỗi đã chuyển vào trong.

Làm điều này trước khi thêm bất kỳ tuyến chia tách nào. Thay đổi tuyến thực hiện khi vận chuyển đang hỏng tạo ra biến thứ hai và che khuất biến thứ nhất.

Viết chính sách chia tách, bao gồm DNS

Định tuyến chia tách là một danh sách quyết định, không phải ô đánh dấu. Mỗi tiền tố riêng phải đi qua tunnel cần một tuyến qua giao diện PPP, và mỗi tiền tố phải ở lại cục bộ phải không có trong đó. Một tuyến cho mạng con ứng dụng mà thiếu tuyến tương ứng tới trình phân giải riêng của nó là cách phổ biến để tạo ra sự cố trông như ứng dụng bị hỏng.

Kiểm tra quyết định mà kernel đưa ra cho một địa chỉ trong mỗi loại:

ip route get 10.20.5.10
ip route get 203.0.113.25

Cái đầu phải nêu ppp0, cái thứ hai là gateway thông thường. Nếu cả hai nêu cùng một giao diện, chính sách hoàn toàn không chia tách. Thêm địa chỉ của chính máy chủ DNS vào danh sách tunnel, nếu không phân giải tên cho máy chủ nội bộ đi ra qua trình phân giải cục bộ và không trả về gì hữu ích.

Kiểm tra lặp lại được trong năm bước

Chạy các tầng theo thứ tự và dừng ở tầng đầu tiên thất bại: kênh điều khiển, khả năng thấy GRE, phản hồi từ đối tác PPP, tuyến chia tách cho một địa chỉ nội bộ và một yêu cầu ứng dụng qua tunnel. Mỗi bước có lệnh riêng, nên lỗi có thể quy về nguyên nhân thay vì bí ẩn.

Một phiên bản gọn cho máy khách Linux trông như sau:

sudo tcpdump -ni any 'tcp port 1723 or proto gre' -c 40
ip -4 addr show ppp0
ping -c 3 192.0.2.1
ip route get 10.20.5.10

Trên Windows áp dụng cùng thứ tự với route print và trạng thái adapter hiển thị trong máy khách. PPTP là giao thức cũ, và nếu máy chủ cung cấp SSTP hoặc IKEv2, việc chuyển sang thường là cách dùng thời gian tốt hơn so với tinh chỉnh một đường phụ thuộc vào việc giao thức 47 đi qua từng chặng. Hãy kiểm tra chứng chỉ và hợp đồng xác thực của phương án thay thế thay vì sao chép hồ sơ cũ vào bản phát hành mới.