Công bố dịch vụ LAN trên chính địa chỉ của cổng VPN

Việc trình bày một thiết bị LAN trên một trong các địa chỉ đường hầm của chính cổng chỉ cần một dòng NAT. Kết nối vẫn thất bại, vì thiết bị trả lời không biết rằng địa chỉ của máy khách có thể tiếp cận qua cổng đó. Lần theo gói tin từ máy khách vào trong, rồi lần theo phản hồi ngược ra ngoài, và nửa còn thiếu sẽ trở nên rõ ràng.

Bắt đầu từ góc nhìn của máy khách

Máy khách trong ví dụ này nằm trong nhóm VPN 10.62.0.0/24 và kết nối tới 10.62.0.1 trên cổng 8080. Địa chỉ đó thuộc về chính cổng, nên gói tin đến nhân của cổng chứ không đến một đồng đẳng khác. Phía sau cổng, LAN là 172.21.4.0/24. Cổng giữ 172.21.4.10 và thiết bị thực sự phục vụ HTTP là 172.21.4.40.

Một địa chỉ thuộc về đồng đẳng VPN khác không thể thay thế cho địa chỉ dịch vụ của cổng. Nếu máy khách kết nối tới địa chỉ của một đồng đẳng, không có quy tắc nào của cổng tham gia, và toàn bộ phần trình bày này là trường hợp sai.

Giới hạn phạm vi dịch địa chỉ đích một cách có chủ đích

Phiên bản hẹp trình bày một cổng và chỉ viết lại đích. Gói tin giữ nguyên giao thức và nguồn, và đó là điều khiến phần còn lại của hành trình trở nên thú vị.

iptables -t nat -A PREROUTING -i tun0 -s 10.62.0.0/24 -d 10.62.0.1 -p tcp --dport 8080 -j DNAT --to-destination 172.21.4.40:80

Một quy tắc không có tiêu chí về giao thức và cổng là phiên bản rộng: nó giữ nguyên cổng mà máy khách đã chọn và chỉ thay đổi địa chỉ. Điều đó hợp lý khi cần trình bày toàn bộ máy chủ, và sai khi ý định là một dịch vụ duy nhất. Đọc lại quy tắc và xác nhận tên giao diện. Quy tắc DNAT trên sai giao diện không khớp với gì cả, điều này tạo ra cùng thời gian chờ như một quy tắc thiếu và lãng phí một giờ để nhìn vào thiết bị.

Hãy để ranh giới chuyển tiếp đồng ý

Dịch thay đổi phần đầu, nhưng không cấp quyền. Với chính sách bỏ mặc định, luồng được chuyển tiếp cần sự chấp nhận riêng của nó, và chiều quay lại cần quy tắc kết nối đã thiết lập mà chính sách của bạn có lẽ đã có.

iptables -A FORWARD -i tun0 -o lan0 -d 172.21.4.40 -p tcp --dport 80 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Chấp nhận vô điều kiện cho mọi luồng DNAT rộng hơn thiết kế này và cũng sẽ cho phép các ánh xạ do người khác thêm vào sau này. Nêu tên đích và cổng, và để phần còn lại đóng. Nếu bộ đếm trên quy tắc chuyển tiếp vẫn bằng không trong khi bộ đếm NAT tăng, gói tin đang bị bỏ trước quy tắc của bạn. Đọc thứ tự chuỗi thay vì thêm một bản sao thứ hai.

Thiết bị phải trả lời bằng cách nào đó

Sau khi dịch, thiết bị thấy một nguồn trong 10.62.0.0/24. Phản hồi của nó đi tới cổng mặc định, đó là bộ định tuyến LAN chứ không phải cổng VPN, trừ khi có gì đó nói khác. Hai cách sắp xếp khắc phục điều này và chúng không tương đương. Một tuyến trên thiết bị hoặc trên bộ định tuyến LAN gửi 10.62.0.0/24 tới 172.21.4.10 trong khi giữ nguyên nguồn của máy khách. Dịch nguồn có giới hạn thay vào đó giấu máy khách sau địa chỉ LAN của cổng.

ip route add 10.62.0.0/24 via 172.21.4.10 dev eth1
iptables -t nat -A POSTROUTING -s 10.62.0.0/24 -d 172.21.4.40 -o lan0 -p tcp --dport 80 -j SNAT --to-source 172.21.4.10

Chọn theo nhu cầu của dịch vụ. Chính sách theo từng máy khách và nhật ký có ý nghĩa muốn dạng được định tuyến; một thiết bị không thể được cấp tuyến, hoặc một dịch vụ đơn giản là phải thấy địa chỉ LAN, chỉ về dạng đã dịch. Đừng với tới một quy tắc masquerade toàn cục để làm cho một phản hồi hoạt động. Nó giấu mọi máy khách khỏi mọi đích và âm thầm phá vỡ các chính sách phụ thuộc vào địa chỉ nguồn.

Đừng kiểm thử từ chính cổng

Một yêu cầu được tạo trên cổng tới 10.62.0.1 đi ra qua chuỗi OUTPUT, không qua PREROUTING đến. Sự thất bại hay thành công của nó không nói gì về quy tắc hướng tới máy khách, và đó là cách người ta kết luận rằng một quy tắc đang hoạt động bị hỏng.

conntrack -L | grep 172.21.4.40
tcpdump -ni any 'port 8080 or port 80'

Chạy một yêu cầu máy khách thật và đọc cả hai. Mục conntrack cho thấy phép dịch đã áp dụng, và các bản bắt gói cho thấy yêu cầu có đi qua LAN không và có phản hồi quay lại phía đường hầm không. Dùng một kết nối mới sau khi thay đổi quy tắc, vì trạng thái hiện có giữ ánh xạ trước đó và sẽ tiếp tục thất bại theo cách cũ. Sau đó xác nhận toàn bộ cuộc trò chuyện: địa chỉ thiết bị, quyền chuyển tiếp và tuyến phản hồi đều mô tả cùng một luồng.