Bộ định tuyến báo một địa chỉ WAN bắt đầu bằng 100.72, tên DNS động phân giải sang một địa chỉ công cộng khác, và máy chủ VPN trên bộ định tuyến đó không bao giờ hoàn tất bắt tay từ bên ngoài. Chuyển tiếp cổng đã được cấu hình, dịch vụ đang chạy, và thử nghiệm từ LAN vẫn hoạt động. Không có gì trong nhật ký bộ định tuyến trông giống lỗi. Tổ hợp đó là NAT cấp nhà mạng, và không quy tắc tường lửa nào có thể mở cổng trên một địa chỉ mà ISP nắm giữ.

Xác nhận địa chỉ dùng chung mất hai phút và tránh được một tuần thay đổi cấu hình.

Những dấu hiệu chỉ ra NAT của nhà mạng

So sánh địa chỉ WAN trên trang trạng thái của bộ định tuyến với địa chỉ mà một tra cứu bên ngoài báo. Địa chỉ WAN trong 100.64.0.0/10 là dấu hiệu thường gặp, và các dải riêng 10/8, 172.16/12 và 192.168/16 cũng có nghĩa như vậy. Nếu traceroute lặp lại cùng một chặng công cộng, hoặc một chặng sớm trả lời bằng địa chỉ riêng, thì có một bộ dịch khác nằm giữa bộ định tuyến và internet. Một số ISP chỉ liệt kê địa chỉ được cấp trong cổng khách hàng, nên hãy xuất giá trị đó cùng với traceroute.

Đổi giao thức hoặc cổng không giúp ích, vì vấn đề là khả năng tiếp cận vào chứ không phải cổng bị đóng.

Vì sao chuyển tiếp và DNS động không thể sửa được

Một quy tắc chuyển tiếp cổng ánh xạ một cổng trên giao diện WAN của bộ định tuyến, nhưng lưu lượng vào không bao giờ đến giao diện đó: ISP dịch nó trước và chỉ chuyển tiếp những gì bảng của họ cho phép. Công bố địa chỉ dùng chung trong DNS động hướng khách hàng đến một cổng của ISP mà nhiều thuê bao sử dụng, nên tên vẫn phân giải được nhưng bắt tay vẫn thất bại. Các thử nghiệm hairpin thành công vì bộ định tuyến trả lời quy tắc của chính nó từ bên trong, và UPnP có đúng cùng điểm mù.

Cấu hình lại máy khách cũng không giúp được, vì lỗi xảy ra trước khi bất kỳ cài đặt máy khách nào được đọc.

Chuyển tiếp qua VPS với tuyến đường rõ ràng

Đặt một địa chỉ công cộng phía trước bằng cách thuê VPS nhỏ nhất có thể chở lưu lượng, rồi để bộ định tuyến trong nhà quay ra kết nối tới đó. UDP đi ra từ mạng trong nhà đi qua NAT của nhà mạng, nên đường hầm được thiết lập từ bên trong và VPS trở thành điểm cuối có thể tiếp cận. Phía trong nhà trở thành máy khách với địa chỉ đường hầm cố định, không phải máy chủ.

Trên VPS, thêm một mục thư mục riêng cho máy khách để máy chủ biết peer nào sở hữu mạng con trong nhà, và thêm tuyến nhân khớp.

# /etc/openvpn/server/ccd/home-site.conf
ifconfig-push 10.8.0.10 255.255.255.0
iroute 192.168.50.0 255.255.255.0

# server.conf
client-config-dir /etc/openvpn/server/ccd
route 192.168.50.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"

Dòng iroute cho OpenVPN biết máy khách nào nhận lưu lượng cho mạng con trong nhà; dòng route đưa mạng con đó vào bảng nhân của VPS để gói tin vào được đường hầm. Với dịch vụ đã công bố, thêm quy tắc NAT đích chuyển cổng công cộng đến 10.8.0.10 và bật net.ipv4.ip_forward.

Kiểm tra đường đi từ bên ngoài

Xác minh từng chặng ở phía công cộng, vì một đường hầm thành công không chứng minh dịch vụ có thể tiếp cận. Trạng thái lắng nghe và bắt gói trên VPS phân biệt 'không có gì đến' với 'đến rồi bị bỏ'.

ss -lunp | grep 1194
tcpdump -ni any udp port 1194
nft list ruleset | grep -A4 dnat

# from a phone on mobile data, not the home Wi-Fi
nc -vz -u 203.0.113.10 1194

Nếu bắt gói thấy gói từ điện thoại nhưng không có phản hồi, điểm dừng tiếp theo là cấu hình máy chủ hoặc tường lửa. Nếu bắt gói không thấy gì, máy khách vẫn đang phân giải hoặc gửi đến địa chỉ sai.

Các lựa chọn thay thế đáng định giá trước

Một địa chỉ IPv4 riêng từ ISP là giải pháp ngắn nhất và thường là một khoản phí hàng tháng nhỏ. IPv6 gốc loại bỏ việc dịch ở cả hai đầu khi VPN, mạng máy khách và bản ghi DNS đều hỗ trợ. Một lớp phủ mesh với bộ định tuyến mạng con trong mạng trong nhà đạt được cùng kiểu chuyển tiếp mà không cần VPS, nhưng phải trả giá bằng việc phụ thuộc vào dịch vụ điều phối.

Chọn chuyển tiếp khi yêu cầu là truy cập vào ổn định và mọi quy tắc phải nằm trong tầm kiểm soát của bạn. Chọn địa chỉ ISP khi ngân sách cho phép và mục tiêu chỉ là thôi nghĩ về nó.

Bài viết liên quan