Đường hầm VPN không bao giờ kết nối: gói tin thực sự dừng ở đâu

Máy khách cứ thử lại, nhật ký dừng trước khi bắt tay hoàn tất, và máy chủ không ghi nhận được gì cả. Mẫu đó hướng sự chú ý khỏi thông tin đăng nhập sang đường đi: có gì đó giữa hai đầu từ chối mang giao thức mà đường hầm cần. Xác định nơi gói tin dừng lại trước khi chạm vào bất kỳ cấu hình nào, vì giao thức bị lọc và mật khẩu sai tạo ra cùng một lỗi thân thiện ở hầu hết máy khách. Các bài kiểm tra được sắp theo chi phí, rẻ nhất trước.

Chứng minh lưu lượng dừng ở đâu

Bắt gói đồng thời trên giao diện ra của máy khách và trên máy chủ. So sánh thứ đã đi với thứ đã đến, và ghi lại hướng mà sự khác biệt xuất hiện.

Không có gì ở máy chủ nghĩa là đường đi hoặc NAT đầu tiên đang loại bỏ lưu lượng, còn các lần đến không có phản hồi chỉ ra tường lửa trên máy chủ hoặc tuyến quay về không tồn tại. Bộ định tuyến thường kết thúc đường hầm hiếm khi giữ nhật ký hữu ích, nên bản bắt gói trở thành bản ghi. Ghi lại cổng đích và số giao thức, vì cả hai lỗi trông giống nhau trong hộp thoại máy khách.

PPTP chết nếu thiếu giao thức 47

PPTP mang điều khiển trên TCP 1723 và dữ liệu bên trong GRE, thứ này là giao thức IP 47 chứ không phải số cổng. Chỉ chuyển tiếp 1723 tạo ra kết quả kinh điển: kết nối xác thực rồi im lặng, vì không có quy tắc nào cho giao thức mang tải trọng. Máy khách không thể phân biệt điều đó với mật khẩu bị từ chối, nên bản bắt gói phải đến trước các thay đổi cấu hình.

Passthrough chạy ngược hướng với chuyển tiếp vào, và phần sụn dùng cùng một nhãn cho cả hai đủ thường xuyên để làm mọi người bối rối. Trên máy khách Linux, tường lửa cục bộ có thể loại bỏ GRE từ rất lâu trước khi bộ định tuyến tham gia, nên giao thức 47 cần quy tắc riêng và trợ lý conntrack phải được nạp. ufw của Ubuntu giữ các quy tắc đó trong tệp before, vì quy tắc allow thông thường không thể diễn đạt số giao thức. Sau đó hãy nạp lại tường lửa thay vì khởi động lại máy.

# /etc/ufw/before.rules, inside *filter
-A ufw-before-input -p gre -j ACCEPT
sudo ufw allow 1723/tcp
sudo modprobe nf_conntrack_pptp
sudo conntrack -L | grep gre

L2TP và IPsec sau hai lớp NAT

L2TP bên trong IPsec cần UDP 500 cho trao đổi khóa, UDP 4500 khi phát hiện NAT, và ESP như giao thức 50. Mỗi thứ được lọc độc lập, nên một quy tắc cho phép một cái không chứng minh gì về hai cái còn lại. Hai bộ định tuyến nối tiếp dịch mỗi gói hai lần, và hai đầu không còn đồng ý về những gì đã thương lượng.

Cầu nối modem bên ngoài, hoặc tắt NAT trên bộ định tuyến bên trong, để địa chỉ công cộng đến được thiết bị kết thúc đường hầm. Ở nơi không thể làm cả hai, đường hầm phải được khởi tạo từ bên trong ranh giới NAT kép, không phải kết thúc ở đó.

Mạng nhà mạng và chia sẻ địa chỉ

Địa chỉ WAN nằm trong 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 hoặc 100.64.0.0/10 nghĩa là bộ định tuyến không có địa chỉ công cộng và không chuyển tiếp vào nào từ internet có thể đến được nó. NAT cấp nhà mạng còn lọc cả những giao thức nó không mong đợi, và GRE thường xuyên là nạn nhân trên các liên kết di động. Hãy so sánh địa chỉ WAN trên chính bộ định tuyến, không phải địa chỉ mà một trang tra cứu báo cho máy khách phía sau nó.

Chạy cùng bộ định tuyến trên một đường dây có dây tách một phát hiện về nhà mạng khỏi lỗi cấu hình chỉ với một bài kiểm tra. Ở nơi nhà mạng từ chối giao thức, các lựa chọn còn lại là một phương thức vận chuyển khác trên 443 hoặc một đường hầm khởi tạo từ bên trong.

Đọc danh sách trình lắng nghe trước khi đóng cổng

Một lần quét cổng đáng lo thường chỉ là bộ tính năng được giao ở trạng thái bật. Kiểm kê các trình lắng nghe, gắn mỗi socket với một tính năng, rồi tắt tính năng thay vì chặn cổng, để hai góc nhìn không tách rời nhau.

ss -lntup
systemctl list-units --type=service --state=running | grep -i vpn
nc -vz 203.0.113.10 1723
nc -vzu 203.0.113.10 4500

Các giá trị mặc định của SoftEther là ví dụ tốt: TCP 443, 992 và 5555, với các tính năng L2TP/IPsec và đường hầm DNS thêm socket riêng. Tắt những tính năng đó sẽ gỡ bỏ các trình lắng nghe thay vì giấu chúng, và bài kiểm tra từ một máy chủ bên ngoài cho biết nhà mạng có để cổng đi qua hay không. Một trình lắng nghe trả lời cục bộ vẫn có thể bị đóng ở phía trên, nên hãy so sánh địa chỉ WAN của chính bộ định tuyến với những gì một dịch vụ bên ngoài báo cáo.