Định tuyến giữa các LAN riêng trước khi thêm một NAT nữa
Không gian địa chỉ chồng lấn, tuyến quay về bị thiếu hoặc transit không đáng tin quyết định lựa chọn giữa định tuyến, NAT và đường hầm. Kiểm tra ba điều đó trước khi sửa tường lửa.
Hai tường lửa nội bộ, một phân đoạn transit riêng và một yêu cầu cho phép vài máy chủ trong mỗi LAN nói chuyện với máy chủ ở LAN kia. Phản xạ thường là dựng một VPN hoặc thêm lớp NAT thứ hai, và cả hai phản xạ đều tốn kém hơn mức vấn đề đáng có. Định tuyến thông thường là đủ khi ba điều kiện cùng đúng: các dải địa chỉ không chồng lấn, cả hai bên có thể gửi trả lưu lượng về LAN kia và phân đoạn transit đã đủ đáng tin cho dữ liệu. Kiểm tra ba điều này trước khi thiết kế bất cứ thứ gì, vì mỗi điều đều thay đổi câu trả lời.
Ba điều kiện quyết định thiết kế
Điều kiện đầu tiên là không gian địa chỉ. Nếu cả hai LAN dùng cùng một khối RFC 1918, định tuyến không thể phân biệt chúng và việc dịch địa chỉ trở thành không thể tránh khỏi thay vì tùy chọn. Điều thứ hai là đường quay về: một tuyến từ A đến B là vô ích nếu B cũng không biết cách đến LAN của A, và hiểu biết bất đối xứng là lý do phổ biến nhất khiến một thiết kế có định tuyến âm thầm bỏ rơi các phản hồi.
Điều thứ ba là sự tin cậy. Định tuyến di chuyển gói tin; nó không bảo vệ gói tin. Một phân đoạn transit riêng trong cùng một tòa nhà khác với việc bàn giao cho nhà cung cấp hoặc một liên kết băng qua xương sống khuôn viên dùng chung. Nếu phân đoạn không đáng tin, câu trả lời là một đường hầm giữa hai tường lửa, và kế hoạch định tuyến bên dưới vẫn áp dụng bên trong nó.
Thiết kế đơn giản chỉ thắng khi cả ba cùng chỉ về một hướng. Khi một điều kiện thất bại, hãy sửa đúng điều kiện đó một cách rõ ràng thay vì che nó bằng dịch địa chỉ, vì NAT che giấu sự cố thay vì giải quyết nó.
Xây dựng kế hoạch tuyến trên mạng transit
Cấp cho mỗi tường lửa một địa chỉ trên phân đoạn dùng chung và thêm một tuyến cụ thể cho mỗi LAN từ xa. Không có gì khác trong cấu hình hiện tại phải di chuyển, và đặc biệt tuyến mặc định ra internet phải ở đúng chỗ của nó. Thay một tuyến mặc định bằng tường lửa đối tác sẽ gửi mọi đích không liên quan qua transit, đó là thay đổi lớn hơn nhiều so với yêu cầu. Tài liệu của pfSense về định tuyến tĩnh mô tả cùng mô hình tuyến cộng cổng cho nền tảng đó, và điều khiển tương đương có trên bất kỳ tường lửa nào bạn thực sự chạy.
| Firewall | Remote LAN | Next hop on the transit |
|---|---|---|
| A | 10.40.0.0/24 | 192.0.2.20 |
| B | 10.30.0.0/24 | 192.0.2.10 |
Tường lửa A phục vụ 10.30.0.0/24 và tường lửa B phục vụ 10.40.0.0/24, với hai địa chỉ transit nằm trong 192.0.2.0/24. Mỗi máy chủ LAN giữ tường lửa cục bộ làm cổng của mình, vì vậy trạng thái mới duy nhất là một tuyến ở mỗi bên. Trên tường lửa chạy Linux, cùng kế hoạch trông như thế này, và việc chuyển tiếp phải được bật, nếu không tuyến sẽ được phân giải trong khi gói tin bị loại bỏ.
sysctl -w net.ipv4.ip_forward=1 ip route add 10.40.0.0/24 via 192.0.2.20 dev eth1 ip route get 10.40.0.15 traceroute -n 10.40.0.15
Giữ lọc tách khỏi dịch địa chỉ
Định tuyến và chính sách là hai cơ chế kiểm soát khác nhau, và chính cơ chế thứ hai là nơi phần lớn thiết kế có định tuyến thất bại. Cho phép các nguồn, đích và dịch vụ cụ thể tại biên vào mà gói tin thực sự đi qua, và nhớ rằng nhãn giao diện như WAN chỉ là tên, không phải tuyên bố về sự tin cậy. Một cổng transit mang lưu lượng riêng vẫn có thể đang bật chặn địa chỉ riêng theo mặc định.
Sau đó xem việc dịch địa chỉ đi ra trước khi kết luận rằng không có NAT. Các quy tắc đi ra tự động có thể viết lại lưu lượng chưa bao giờ được dự định dịch, và điều đó phá hủy địa chỉ nguồn mà bên kia cần cho chính sách và nhật ký của mình. Xác nhận rằng các luồng được chọn giữ nguyên địa chỉ gốc, và để yên các quy tắc dịch internet cho lưu lượng vẫn còn cần chúng.
iptables -t nat -S POSTROUTING iptables -t nat -L POSTROUTING -n -v tcpdump -ni eth1 -c 5 host 10.40.0.15
Khi NAT là câu trả lời trung thực
Dịch địa chỉ giành được chỗ đứng khi các dải địa chỉ thực sự chồng lấn và không thể đánh số lại, hoặc khi chính sách yêu cầu một bên chỉ thấy một địa chỉ thay vì một mạng con. Trong những trường hợp đó, ánh xạ một-một hoặc giới hạn theo cổng có chủ đích là một quyết định thiết kế với hậu quả đã biết, không phải một cách làm lối tắt.
Hậu quả cần nói to là bên kia không còn có thể thấy hoặc lọc từng nguồn riêng lẻ. Nhật ký thu gọn về địa chỉ dịch, chính sách theo từng máy chủ ngừng hoạt động, và việc khắc phục sự cố trở thành cuộc truy tìm máy chủ nội bộ nào đã giữ một luồng tại một thời điểm. Nếu không điều nào trong số đó quan trọng với lưu lượng đang xét, NAT là ổn.
Khi chính transit là giả định sai
Nếu phân đoạn dùng chung đi qua nhà cung cấp, một ma trận chuyển mạch dùng chung hoặc bất kỳ đường nào mà bên khác có thể đọc lưu lượng, chỉ định tuyến không phải là câu trả lời đầy đủ. Một đường hầm giữa hai tường lửa cho bạn tính bí mật và xác thực đối tác, và bảng tuyến bên trong nó chính là bảng bạn sẽ viết trên transit.
Hãy quyết định điều đó từ câu hỏi về sự tin cậy ở phần đầu, không phải từ thói quen cho rằng VPN an toàn hơn. Một đường hầm trên phân đoạn vốn đã riêng tư thêm chi phí vận hành và thêm một kiểu hỏng hóc mà không có lợi ích gì, trong khi định tuyến trên phân đoạn không đáng tin đánh đổi tính bí mật lấy sự đơn giản mà bạn không thể chi trả. Ghi lại điều kiện nào trong ba điều kiện đã dẫn dắt lựa chọn, và kỹ sư tiếp theo sẽ không phải tranh luận lại.