NAT cho LAN qua tun0 trên cổng VPN OpenBSD

Hai kỹ sư với cùng một cổng OpenBSD thường đưa cho bạn hai bộ quy tắc khác nhau để tới một mạng từ xa, và cả hai đều có thể bảo vệ được. Lựa chọn giữa dịch nguồn và tuyến quay về hoàn toàn không phải là câu hỏi về cú pháp. Tất cả phụ thuộc vào điều phía bên kia đã biết về 192.168.88.0/24 và điều bạn cần giữ lại trong nhật ký. Sai ở đây thì dòng nat-to sẽ trông hoàn toàn đúng trong khi các phản hồi biến mất vào cổng mặc định phía xa.

Định tuyến và ghi lại trả lời những câu hỏi khác nhau

Bảng định tuyến quyết định rằng 172.20.0.0/16 có thể tới được qua tun0, và quyết định đó được đưa ra trước khi bất kỳ phép dịch pf nào được hỏi tới. Sau đó dịch nguồn thay đổi phần đầu gói tin để phía xa thấy địa chỉ tunnel của cổng thay vì một máy chủ LAN. Không cơ chế nào thay thế cơ chế kia: quy tắc nat không thể tạo ra tuyến, và tuyến không thể thuyết phục một router phía xa chưa từng nghe về mạng con riêng của bạn. Khi phía bên kia không có đường quay về, các phản hồi bị loại bỏ hoặc chuyển tới cổng mặc định của nó, và không mức chỉnh quy tắc nào sửa được điều đó.

Nói đơn giản, chuyển tiếp trả lời lưu lượng đi đâu, còn dịch trả lời nó trông như đến từ đâu. Giữ cả hai trong những chiếc hộp tinh thần riêng khi bạn thiết kế bộ quy tắc.

Ba điều kiện quyết định

Hỏi ba câu theo thứ tự và thiết kế thường tự chọn lấy. Mạng từ xa có tuyến tĩnh trỏ tới địa chỉ tunnel cho 192.168.88.0/24 không, hay quản trị viên của nó kiểm soát các router trên đường đó? Nếu có, hãy để địa chỉ LAN đi nguyên vẹn và bỏ hẳn việc dịch. Bạn có cần nhìn thấy từng máy khách ở phía xa không, dù cho chính sách truy cập hay cho dấu vết kiểm toán? Nếu cần, giữ nguồn đáng với công sức định tuyến. Địa chỉ tunnel có đủ ổn định để ghi vào một tuyến từ xa không, hay nó thay đổi giữa các lần kết nối lại?

Nếu bất kỳ câu trả lời nào là không hoặc không rõ, nat-to là lựa chọn thực dụng, và cũng là lựa chọn có thể đảo ngược. Một quy tắc dịch được gỡ trong một dòng khi phía bên kia thêm một tuyến đúng đắn. Một tuyến quay về chưa từng được cài sẽ khiến bạn tốn một luồng hỗ trợ mỗi lần ai đó hỏi vì sao tunnel chỉ chạy một chiều.

Đặt đoạn cấu hình để pf thực sự đánh giá nó

Đoạn dưới đây giả định LAN là 192.168.88.0/24, mạng từ xa là 172.20.0.0/16 và giao diện tunnel là tun0. Không có gì trong đó chọn bước nhảy tiếp theo. Nó chỉ ghi lại nguồn trên các gói tin đã rời đi qua tunnel.

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

Hai chi tiết trong dòng đầu tiên đó mang phần lớn trọng lượng. Dấu ngoặc quanh tun0 bảo pf đọc địa chỉ giao diện mỗi lần nó dựng một mục trạng thái, điều này quan trọng khi tunnel được đánh số lại sau khi kết nối lại. Từ match nghĩa là quy tắc ghi lại rồi rơi xuống tiếp, nên một quy tắc pass riêng vẫn phải cho luồng đi qua. Giao diện được nêu trong dòng match cũng phải là giao diện mà bảng định tuyến chọn, nếu không pf sẽ đánh giá quy tắc trên một đường ra khác với đường gói tin thực sự đi.

Đừng quên phía nhân. Chuyển tiếp IPv4 phải được bật, và các quy tắc pass có trạng thái cho tunnel và LAN phải tồn tại trước khi tất cả điều này có ý nghĩa. Mục PF NAT trong FAQ của OpenBSD là tài liệu tham chiếu đúng cho thứ tự từ khóa ở đây.

Xác minh bộ quy tắc trước khi tin vào lưu lượng

Trước tiên kiểm tra cú pháp bằng pfctl -nf /etc/pf.conf, lệnh này phân tích tệp mà không nạp nó. Sau đó nạp chính sách và đọc lại những gì nhân thực sự giữ, vì một quy tắc được phân tích sạch vẫn có thể bị che khuất hoặc gắn vào giao diện sai. pfctl -sn in các quy tắc dịch ở dạng đã nạp, và pfctl -sr in các quy tắc lọc theo thứ tự đánh giá.

Tiếp theo hãy quan sát dây. Trên cổng, tcpdump -ni tun0 'host 172.20.0.10' cho biết địa chỉ nguồn rời tunnel là địa chỉ tunnel hay máy chủ LAN. Một lệnh netstat -rn -f inet nhanh xác nhận đích được phân giải tới giao diện nào. Khi lưu lượng bắt đầu chảy, pfctl -ss liệt kê các mục trạng thái; nếu một luồng không tạo trạng thái, gói tin đó chưa bao giờ khớp với quy tắc tạo ra nó.

Nếu phía tunnel trông đúng mà phản hồi vẫn không tới, hãy ngừng sửa pf. Lỗi còn lại nằm trên router phía xa, nơi phản hồi được gửi tới một địa chỉ riêng mà phía đó không thể với tới.

Khi việc dịch tốn kém hơn mức nó tiết kiệm

Dịch che giấu máy khách, và đôi khi đó chính là sự đánh đổi sai. Các mạng con chồng lấn là một trường hợp: nếu phía bên kia cũng dùng 192.168.88.0/24 bên trong, việc trình bày máy chủ LAN như cổng sẽ làm xung đột tệ hơn chứ không tốt hơn. Các chính sách IPsec chọn lưu lượng theo cặp địa chỉ là trường hợp khác, vì cơ sở dữ liệu chính sách bảo mật được đối chiếu trước khi dịch và không bao giờ thấy gói tin đã ghi lại của bạn. Bất kỳ triển khai nào tính phí, giới hạn hay kiểm toán theo người dùng cũng mất đi danh tính mà nó cần ngay khi nguồn thu về một địa chỉ.

Các dẫn xuất pf di động là một cái bẫy riêng. Những sản phẩm tự sinh tệp quy tắc của mình kỳ vọng NAT được cấu hình qua giao diện của chúng, và các đoạn sửa tay sẽ bị ghi đè ở lần nạp lại kế tiếp. Các bộ quy tắc sao chép từ hướng dẫn viết trước khi có từ khóa match sẽ không nạp trên nhân hiện tại, nên hãy chuyển cú pháp và đọc lỗi thay vì đoán.

Quy tắc quyết định sống sót khi tiếp xúc với mạng thật thì ngắn: hãy cài một tuyến quay về khi bạn có thể, hãy dịch khi bạn không thể, và ghi lại điều kiện nào trong ba điều kiện đã khiến bạn chọn như vậy. Ghi chú đó tiết kiệm cho người tiếp theo cả một buổi chiều.