Bạn có nên áp dụng SNAT cho chuyển tiếp cổng vào một mạng con VPN?

Chuyển tiếp một cổng đến máy chủ nằm sau ứng dụng VPN của chính router thất bại theo cách trông giống sự cố tường lửa, vì yêu cầu rõ ràng đến nơi. Dịch vụ ghi lại kết nối, ứng dụng chờ, và không có gì quay lại. Dịch địa chỉ đích đã làm xong việc của nó; gói phản hồi chính là phần bị mất. Một quy tắc NAT nguồn chọn lọc trên router khắc phục điều này, và phần thú vị là quyết định quy tắc đó có thể hẹp đến mức nào.

Vì sao phản hồi đi theo con đường khác

Chuyển tiếp cổng viết lại nơi gói tin đi đến, không bao giờ viết lại nơi nó xuất phát. Địa chỉ của ứng dụng internet vẫn nằm trong trường nguồn suốt đường hầm, nên dịch vụ từ xa thấy một người lạ và trả lời theo cách duy nhất nó biết: qua cổng mặc định của chính nó. Cổng đó là bộ tập trung VPN ở phía bên kia, nơi không có tuyến quay lại một địa chỉ công cộng bất kỳ.

Xem bản ghi trên giao diện đường hầm và sự bất đối xứng là rõ ràng: gói yêu cầu đi ra, không có gì đi vào. Chuỗi chuyển tiếp cho phép luồng và đường hầm đã mang nó, nên việc bỏ gói xảy ra sau khi máy chủ từ xa đã chọn xong đường về.

Một quy tắc nguồn đủ hẹp để tin cậy

Biến router thành nguồn mà máy chủ từ xa trả lời. Trong bố cục này địa chỉ WAN là 203.0.113.24, LAN là 192.168.88.0/24, địa chỉ đường hầm của router là 172.20.5.1, và dịch vụ trả lời tại 172.20.5.40:8443. Quy tắc bên dưới khớp với gói sau khi dịch địa chỉ đích, vì vậy nó nêu địa chỉ đã dịch chứ không phải địa chỉ công cộng. Không có gì trong đó phụ thuộc vào địa chỉ của ứng dụng, và đó chính là điểm mấu chốt.

iptables -t nat -A POSTROUTING -o tun0 -p tcp -d 172.20.5.40 --dport 8443 -j SNAT --to-source 172.20.5.1

Mọi điều kiện khớp trong dòng đó tồn tại để giữ việc viết lại chỉ trong một dịch vụ trên một đường hầm. Bỏ giao diện hoặc cổng đi và bạn viết lại nhiều lưu lượng hơn mức sự cố đòi hỏi, và đó là cách một bản sửa có mục tiêu trở thành câu đố cho người tiếp theo.

Khi nào một lớp mặt nạ toàn bộ là lựa chọn trung thực

Nếu router chuyển tiếp nhiều dịch vụ vào cùng một mạng con VPN, quy tắc cho từng dịch vụ trở thành danh sách không ai duy trì. Che giấu mọi thứ rời giao diện đường hầm thì đơn giản và dễ đoán hơn, với cái giá là ẩn ứng dụng gốc khỏi mọi máy chủ ở phía bên kia. Hãy chọn cách đó khi nhật ký ở đó không dùng để quy trách nhiệm; giữ quy tắc hẹp khi chúng được dùng.

Hai lựa chọn cũng thất bại theo cách khác nhau. Quy tắc hẹp bị thiếu làm hỏng một dịch vụ; một lớp mặt nạ rộng khớp quá nhiều có thể âm thầm viết lại lưu lượng vốn đã hoạt động, kể cả các kết nối ra của chính router.

Kiểm tra bộ đếm trước khi công bố

Những quy tắc không bao giờ khớp trông giống hệt những quy tắc đang hoạt động cho đến khi bạn đếm gói. Đọc lại bảng với bộ đếm byte trước khi bất kỳ ứng dụng nào kết nối, sau đó kết nối từ một mạng không phải LAN và đọc lại. Hai lần đọc chính là điều biến phỏng đoán thành sự thật. Chỉ công bố chuyển tiếp sau khi lần thứ hai thay đổi.

iptables -t nat -L POSTROUTING -v -n --line-numbers

Bộ đếm bằng không trên quy tắc nguồn sau một kết nối thật nghĩa là điều kiện khớp sai, thường là do đích hoặc cổng không khớp với gói sau khi dịch. Nếu bộ đếm tăng nhưng ứng dụng vẫn hết thời gian chờ, đường về đã được sửa và thứ khác đang bỏ phản hồi, nên hãy xem chính sách chuyển tiếp ở phía bên kia tiếp theo. Truy cập kiểu kẹp tóc từ bên trong LAN là vấn đề riêng và cần quy tắc riêng, không phải một phiên bản rộng hơn của quy tắc này.