Khi nào NAT bên trong VPN site-to-site xứng đáng có chỗ đứng

Hai site đều dùng cùng một dải riêng, và đường hầm dựng lên trong khi không có gì hữu ích đi qua nó. Dịch địa chỉ là câu trả lời thông thường, và đó là một câu trả lời thật: trình bày một dải khác cho phía xa có thể giải quyết chồng lấn hoặc một đường trả về mà mạng kia không thể định tuyến. Phần bị bỏ qua là việc dịch địa chỉ thay đổi các địa chỉ mà mọi quyết định sau đó nhìn thấy. Hãy coi đây là một quyết định thiết kế được ghi lại với ánh xạ bằng văn bản, không phải một quy tắc được thêm vào cho đến khi ping thành công.

Quyết định địa chỉ nào bị viết lại

Dịch nguồn thay đổi những gì dịch vụ từ xa và nhật ký của nó nhìn thấy là máy khách, nên một máy chủ nhánh trở thành địa chỉ cổng khi đến. Dịch đích hoặc tiền tố thay vào đó trình bày một địa chỉ thay thế cho một tài nguyên từ xa. Một số triển khai cần dịch phối hợp ở cả hai phía để tách hai mạng vốn giống hệt nhau, và chính sự kết hợp này là nơi phần lớn nhầm lẫn bắt đầu.

Ghi lại nguồn trước khi dịch, đích theo cách ứng dụng gọi nó, và cặp địa chỉ mà mỗi cổng khớp vào. Ba cột là đủ, và cột thứ ba là cột mà mọi người bỏ qua.

Thứ tự của các bộ chọn cũng quan trọng. Việc chọn và dịch chính sách IPsec diễn ra ở các giai đoạn xác định, nên một bộ chọn được viết cho địa chỉ trước khi dịch có thể không bao giờ khớp với gói tin ở giai đoạn bạn giả định. Hãy kiểm tra chính sách đã cài đặt thay vì chính sách bạn định cài, vì hai thứ này khác nhau đúng vào lúc một thành phần chấp nhận quy tắc và thành phần khác bỏ qua nó:

ip xfrm policy show
ip xfrm state show
nft list ruleset | grep -A4 nat

Theo dõi tải trọng và đường trả về

Một máy chủ ghi lại nguồn đã dịch thay vì máy chủ nhánh riêng lẻ sẽ phá vỡ mọi quy tắc hoặc báo cáo gắn với địa chỉ gốc. Trước khi thay đổi ánh xạ, hãy tìm hiểu xem có gì ở hạ nguồn đưa ra quyết định từ trường đó: danh sách truy cập, báo cáo kiểm toán, giới hạn tốc độ, kiểm tra giấy phép. Mỗi thứ trong số đó là một nơi mà việc dịch địa chỉ xuất hiện sau này như một lỗi không giải thích được.

Các giao thức mang địa chỉ bên trong tải trọng cần lập kế hoạch riêng, vì việc viết lại tiêu đề bên ngoài không chạm vào tham chiếu bên trong. FTP chủ động, SIP và một số sản phẩm truy cập từ xa là những trường hợp kinh điển, và một thiết kế bỏ qua chúng sẽ hoạt động với lưu lượng web và thất bại với ứng dụng quan trọng.

Lưu lượng trả về phụ thuộc vào ánh xạ có trạng thái. Chuyển đổi cổng dự phòng có thể làm mất trạng thái đó, định tuyến không đối xứng có thể đi vòng qua nó, và khởi động lại có thể xóa nó trong khi các phiên vẫn mở ở phía xa. Vì vậy một yêu cầu đến đích và một phiên hoàn tất là hai kết quả chấp nhận khác nhau.

Cân nhắc so với việc đánh số lại một site

Đánh số lại một site xung đột loại bỏ hoàn toàn ánh xạ và để lại một kế hoạch địa chỉ có thể đọc mà không cần bảng dịch. Việc này tốn kém về vận hành: bản ghi DNS, gán tĩnh, quy tắc tường lửa và mọi địa chỉ được ghi lại đều phải thay đổi cùng lúc. Chi phí đến một lần, trong một cửa sổ đã lên kế hoạch, với trạng thái cuối rõ ràng. Thứ bạn mua là khả năng đọc một bản ghi gói tin nhiều năm sau mà không cần bảng tra cứu.

Việc dịch địa chỉ tránh hầu hết các thay đổi cục bộ và tạo ra một ánh xạ phải được duy trì trong DNS, tài liệu và xử lý sự cố mãi mãi. Chi phí đến liên tục, dưới hình thức mỗi kỹ sư tương lai phải học rằng một tiền tố có nghĩa khác bên trong đường hầm.

Đối với một kết nối tạm thời hoặc một mạng đối tác mà bạn không kiểm soát, chi phí liên tục thường đáng giá. Đối với hai site bạn sở hữu và sẽ sở hữu trong nhiều năm, đánh số lại thường là quyết định rẻ hơn khi việc di chuyển được tính một cách trung thực.

Chứng minh cả hai chiều bằng một phiên thật

Hãy kiểm tra một phiên ứng dụng thay vì một đầu dò duy nhất. Một yêu cầu phản hồi thành công chứng minh rằng một chiều của một giao thức hoạt động, và nó hoàn toàn tương thích với một đường trả về thất bại với bất cứ thứ gì có trạng thái. Dùng dịch vụ đã thúc đẩy thiết kế, và đọc nhật ký của nó ở đầu xa để xem nó đã ghi lại địa chỉ nguồn nào.

tcpdump -ni any host 10.40.9.20 and port 443
conntrack -L | grep 10.40.9.20
ip route get 10.40.9.20

Sau đó xác nhận rằng chỉ những dịch vụ dự định mới truy cập được qua ánh xạ. Việc dịch địa chỉ thay đổi cách đánh địa chỉ và không làm gì cho việc ủy quyền, nên chính sách tường lửa vẫn quyết định điều gì được phép. Một thiết kế dựa vào một tiền tố đã dịch mơ hồ làm kiểm soát truy cập thì hoàn toàn không có kiểm soát truy cập.

Ghi lại ánh xạ, phiên đã kiểm tra và các địa chỉ mà mỗi bên quan sát được. Người tiếp theo gỡ lỗi đường hầm này cần ba sự thật đó hơn là tệp cấu hình.