VPN trên router hay chuyển tiếp cổng: bên nào thắng?

Router tự kết thúc VPN, và một quy tắc chuyển tiếp cũ vẫn gửi cùng cổng UDP đến một máy trong LAN. Chỉ một trong hai có thể là điểm cuối thật sự, và nhân hệ điều hành không phân xử giữa chúng. Việc dịch đích viết lại gói tin trước khi dịch vụ cục bộ được hỏi đến, nên tiến trình VPN chờ lưu lượng đã được gửi đi nơi khác. Nhiệm vụ là quyết định ai sở hữu cổng, rồi làm các quy tắc khớp nhau.

Một cổng, hai chủ sở hữu được tuyên bố

Máy chủ VPN chạy bên trong router cần một quyền vào hướng tới socket của chính nó. Mục NAT đích cho cùng cổng đó lại dẫn đến nơi hoàn toàn khác: một địa chỉ LAN và một quyết định chuyển tiếp. Đó là những điểm cuối khác nhau với nhật ký khác nhau và kiểu lỗi khác nhau. Dấu hiệu thường thấy là một họ địa chỉ hoạt động còn họ kia thì không, vì mục còn sót lại được viết cho một họ duy nhất và chưa bao giờ được xem lại.

Ghi lại yêu sách trước khi sửa: họ, địa chỉ ngoài, giao vận, cổng và đích đã dịch.

Việc dịch chạy trước kiểm tra cục bộ

NAT đích thay đổi đích của gói tin ở giai đoạn trước định tuyến, trước khi nhân hệ điều hành chọn giữa giao hàng cục bộ và chuyển tiếp. Khi đích là một máy trong LAN, gói tin đi theo đường chuyển tiếp. Các quy tắc vào cho socket của chính router không bao giờ được xem xét, đó là lý do nhật ký VPN trống trong khi máy khách chờ.

Intended local entry:
WAN UDP 1194 -> router local socket -> input path

Conflicting old entry:
WAN UDP 1194 -> DNAT 192.168.50.10:1194 -> forward path

Thứ tự đó chính là toàn bộ cơ chế, và giao diện thiết bị che nó sau các ô kiểm mà không thay đổi nó. Chủ sở hữu đích vẫn quyết định gói tin đi theo đường nào.

Nếu máy trong LAN là điểm cuối dự định, việc chuyển tiếp là đúng và router không nên cũng lắng nghe trên cổng đó.

Giữ một ánh xạ và xóa cái kia

Liệt kê các mục NAT cho cổng và họ đó rồi chọn kẻ sống sót:

sudo iptables -t nat -S | grep 1194
sudo ss -lunp | grep :1194

Một mục TCP cùng số không liên quan đến lỗi UDP, và coi chúng là một đối tượng sẽ dẫn đến xóa nhầm quy tắc. Khi socket cục bộ nên thắng, chủ sở hữu ánh xạ xung đột sẽ xóa hoặc viết lại đúng mục đó, và quyền vào cho cổng của chính router vẫn giữ nguyên. Các chuyển tiếp không liên quan, đường quản trị và một bản sao bộ quy tắc đều phải sống sót qua thay đổi.

Nếu VPN sống trên một máy riêng, chuyển tiếp là đối tượng đúng. Một dịch vụ trong container hoặc máy ảo có thể cần cổng được công bố ngay cả khi chiếc hộp được gọi là router, nên hãy lần theo socket và không gian tên của nó, không phải nhãn trên vỏ.

Xác nhận chủ sở hữu từ bên ngoài

Kiểm tra từng họ riêng, vì một kết nối IPv6 kết thúc trên router không nói gì về kết nối IPv4 mà một quy tắc cũ chuyển hướng. Đọc nhật ký của dịch vụ nhận để xem điểm cuối nào đã trả lời, và coi thông báo thành công của máy khách là bằng chứng yếu. Cần một luồng mới cho một bài kiểm tra có ý nghĩa. Gửi một đầu dò từ máy ngoài bằng nc -zvu 203.0.113.7 1194 và đọc nhật ký của bên thắng bằng journalctl -u openvpn@server -n 20. Trình lắng nghe của router tự ghi lại kết nối, còn máy trong LAN ghi nó vào dịch vụ của riêng mình.

Theo dõi kết nối giữ các luồng hiện có trên ánh xạ ban đầu, nên một phiên đã thiết lập có thể sống lâu hơn quy tắc bạn vừa sửa.

Khi điểm cuối dự định trả lời bằng các kiểm tra danh tính thông thường, hãy kiểm tra một tài nguyên riêng sau đường hầm. Chạm tới trình lắng nghe bên ngoài chỉ là bước đầu; định tuyến bên trong và ủy quyền ứng dụng là những kết quả riêng.