Truy cập /24 từ xa qua đường hầm: NETMAP, DNAT hay định tuyến?

Bạn có thể đến một mạng con sau điểm cuối đường hầm theo ba cách, và một phút thu thập dữ kiện thường loại bỏ hai. Các dữ kiện là liệu máy chủ ở đó có phải phân biệt người dùng, liệu có ai ở đó sẽ bao giờ kết nối về dải của bạn, và ai có thể sửa bộ định tuyến ở đầu xa. Trả lời ba câu đó và thiết kế tự chọn. Phần còn lại giả định bạn vận hành điểm cuối và có thể sửa tường lửa của nó.

Ba lựa chọn, và mỗi lựa chọn thực sự thay đổi điều gì

Ánh xạ tiền tố, DNAT theo máy chủ và tiền tố được định tuyến đều di chuyển gói tin giữa cùng hai dải, nhưng chúng thay đổi những thứ khác nhau. Ánh xạ tạo ra một dải bí danh và ghi lại địa chỉ bằng số học trong khi bay. Quy tắc theo máy chủ cũng ghi lại, chỉ là mỗi đích được đặt tên thủ công. Tiền tố được định tuyến không ghi lại gì: gói tin giữ địa chỉ thật và cả hai đầu đồng ý về nơi những địa chỉ đó sống.

Bắt đầu loại bỏ từ phía xa, nơi các ràng buộc khó thay đổi nhất. Nếu máy chủ ở đó ghi địa chỉ máy khách vào nhật ký, kiểm tra chúng với danh sách cho phép hoặc chuyển cho hệ thống khác, việc dịch nguồn phá hủy định danh duy nhất của nó. Nếu phía xa cũng phải kết nối vào trong, việc dịch hoàn toàn bị loại, vì ở đó không ai biết bí danh tồn tại. Chỉ khi phía xa chỉ trả lời yêu cầu thì các lựa chọn rẻ hơn mới an toàn.

Các cặp tiền tố, và vì sao kích thước phải khớp

NETMAP là đích của bảng nat làm việc trên một cặp tiền tố có cùng độ dài. Bên trong nó không có bảng theo từng địa chỉ: nó bóc tiền tố, giữ các bit máy chủ và gắn lại vào tiền tố mới, vì thế /24 ánh xạ sang /24 và không bao giờ sang /25. Vị trí quyết định hướng: khớp đích trong PREROUTING ghi lại gói tin đi đâu, và khớp nguồn trong POSTROUTING ghi lại nó đến từ đâu.

Một máy chủ ở 192.168.2.17 hiện ra với máy khách của bạn là 10.50.1.17, và octet cuối không phải đồ trang trí — đó là cùng một số ở cả hai phía. Thêm ngày mai một máy chủ ở 192.168.2.40 và bí danh của nó là 10.50.1.40, không có quy tắc nào phải sửa.

Máy khách vẫn cần một tuyến cho dải bí danh trỏ về hộp của bạn, trừ khi bí danh nằm trong mạng con họ đã đến được. Cổng không cần tuyến cho bí danh, vì việc dịch đích chạy trong PREROUTING, trước khi tra tuyến. Chuyển tiếp cũng phải bật, nếu không nhân sẽ bỏ gói sau khi ghi lại. Ba lệnh dưới đây là toàn bộ thiết lập trên một cổng kiểu Debian với máy khách trên br0, bí danh trên 10.50.1.0/24 và đường hầm trên tun0.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -i br0 -d 10.50.1.0/24 -j NETMAP --to 192.168.2.0/24
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Câu trả lời phải tự tìm đường về

Ghi lại đích chỉ quyết định gói tin được giao ở đâu. Máy chủ phía xa vẫn phải trả lời một địa chỉ mà nó đến được, và có hai cách sắp xếp điều đó. Dịch nguồn để câu trả lời quay về hộp của bạn, hoặc để nguyên nguồn và cho phía xa một tuyến cho dải máy khách.

Masquerade ở chiều ra là đường ngắn hơn: một quy tắc trong POSTROUTING và phía xa thấy địa chỉ đường hầm của bạn, nên nó không cần tuyến riêng. Cái giá là mọi người dùng dồn vào một địa chỉ, và nhật ký theo người dùng không còn ý nghĩa. Để nguyên nguồn giữ được thông tin đó, nhưng khi đó trang phía xa phải gửi trả câu trả lời cho dải máy khách qua đường hầm.OpenVPN máy chủ thì đó là một push "route 10.50.9.0 255.255.255.0", cộng thêm một route 192.168.2.0 255.255.255.0 dòng.

Thất bại đắt giá là làm một nửa mỗi thứ. Nếu bạn masquerade một phần lưu lượng trong khi phía xa cũng mang tuyến về cho lưu lượng khác, câu trả lời đến trên một giao diện nơi mục theo dõi kết nối chưa từng được thấy. Máy khách báo hết thời gian cho một yêu cầu mà máy chủ ghi nhận là đã phục vụ. Cả hai chiều của một luồng phải đi qua cùng một thực thể netfilter: một cổng dịch, không phải hai tường lửa nối tiếp.

conntrack -L -d 10.50.1.17
iptables -t nat -L PREROUTING -v -n

Đọc mục theo cả hai chiều: tuple gốc giữ bí danh của bạn ở đích, còn tuple trả lời mang địa chỉ thật. Nếu thiếu tuple trả lời, vấn đề là đường về, không phải quy tắc. Nếu bộ đếm PREROUTING chưa từng nhích, gói tin chưa từng đến hook đó.

Xung đột và phép tra cứu chạy trước

Hai dải khác nhau có thể xung đột, và cả hai lỗi đều trông như đường hầm hỏng chứ không phải quy tắc tồi. Bí danh bạn tạo ra phải không được dùng trên toàn bộ đường đi, và dải xa thật không được đã tồn tại trên mạng của bạn. Bản trùng tạo ra lưu lượng chập chờn đến sai máy chủ, khó chẩn đoán hơn một kết nối bị từ chối. Hỏi bảng định tuyến trước khi thêm quy tắc.

Trên cổng, ip route get 192.168.2.17 phải nêu tên thiết bị đường hầm; một bridge cục bộ nghĩa là dải xa bị che khuất và không có quy tắc nat nào sửa được. Nếu mạng của bạn đã dùng 192.168.2.0/24, hãy đánh số lại trang phía xa thay vì chồng ánh xạ lên xung đột.

Thử từ một máy khách thật, rồi giữ lại

Thử từ một máy sẽ thực sự dùng bí danh, không phải từ cổng, vì lưu lượng sinh ra cục bộ không bao giờ đi qua PREROUTING theo cùng cách. Mở một kết nối đến một máy chủ có bí danh và xem bộ đếm cùng mục conntrack xuất hiện cùng nhau, rồi đóng lại và xác nhận mục đó biến mất. Một mục cũ chỉ vào kết nối nửa mở, thường có nghĩa là câu trả lời chưa bao giờ quay về.

curl -sv http://10.50.1.17/ -o /dev/null
ss -tn dst 10.50.1.17
conntrack -L -d 10.50.1.17

Hai hoặc ba kết nối thành công chứng minh số học, nhưng không nói gì về độ bền hay về kỹ sư tiếp theo. Lưu quy tắc ở nơi tiến trình khởi động đọc chúng, trên Debian và Ubuntu nghĩa là iptables-save > /etc/iptables/rules.v4 với netfilter-persistent được bật. Một ánh xạ biến mất khi khởi động lại còn tệ hơn không có, vì sự cố đến mà không có thay đổi gần đây để đổ lỗi.

Để lại một ghi chú bên cạnh các quy tắc: dải bí danh, dải thật, lý do của cặp và bên nào được khởi tạo. Ghi chú đó tách một thiết kế khỏi một đống quy tắc không ai dám xóa. Nó cũng giải quyết câu hỏi sau này, khi trang phía xa thêm một máy chủ và một địa chỉ không ai cấu hình đã trả lời. Nếu ghi chú nói phía xa cần tuyến về, người tiếp theo biết rằng xóa quy tắc masquerade sẽ phá kết nối. Tài liệu ở đây rẻ; khám phá lại sự phụ thuộc NAT lúc ba giờ sáng thì không.