Hai site, một subnet: tạo chế độ xem bí danh cho mỗi site

Hai site khách hàng đều chạy 192.168.50.0/24, và một kỹ sư từ xa cần truy cập một máy in tại cùng một địa chỉ ở mỗi site. Không mẹo định tuyến nào tự nó giải quyết được sự mơ hồ đó. Mỗi site cần một chế độ xem địa chỉ riêng, và cổng kết nối phải chọn site từ chế độ xem đó trước khi chuyển tiếp bất cứ thứ gì.

Kế hoạch có bốn phần: tiền tố bí danh, cả hai chiều dịch, chính sách lớp phủ và tên. Mỗi phần phải khớp với các phần còn lại.

Chọn một tiền tố bí danh cho mỗi site

Gán cho mỗi site một tiền tố bí danh trọn vẹn mà không thuộc về ai khác trong môi trường. Một kế hoạch hai site có thể ánh xạ 192.168.50.0/24 của site A sang 172.21.10.0/24 và LAN giống hệt của site B sang 172.21.20.0/24. Kiểm tra các ứng viên với từng mạng tham gia, bao gồm VPC đám mây và các nhóm VPN khác. Không gian địa chỉ riêng được mọi tổ chức chia sẻ, nên việc một dải thuộc RFC 1918 không nói lên điều gì về việc nó còn trống ở đây.

Công bố bí danh, không phải subnet gốc, cho người dùng từ xa. Dải gốc vẫn là sự thật cục bộ.

Dịch theo cả hai chiều

Dịch theo cả hai chiều. Ánh xạ đích viết lại địa chỉ bí danh thành địa chỉ gốc tại site sở hữu. Ánh xạ nguồn viết lại người gọi từ xa thành bí danh mà các site khác có thể phân biệt.

Ánh xạ tĩnh một-một mang tính xác định, nhưng điều đó không làm cho việc triển khai trở nên phi trạng thái. Dịch ngược có thể phụ thuộc vào trạng thái kết nối, và chuyển đổi dự phòng hoặc các đường không đối xứng có thể phá vỡ một kế hoạch bỏ qua điều đó. Tài liệu của nền tảng quyết định trường hợp nào áp dụng.

Giai đoạn chính xác mà chính sách, bộ chọn và tuyến áp dụng khác nhau giữa IPsec dựa trên chính sách, đường hầm dựa trên tuyến và các sản phẩm khác. Hãy thiết kế cho loại bạn vận hành.

Đưa kế hoạch qua lớp phủ

Trong một hub, gán mỗi tiền tố bí danh cho đường dẫn site sở hữu nó và chỉ cho phép lưu lượng trung chuyển mà nhiệm vụ cần. Trong một mesh, mọi peer liên quan cần cùng tiền tố và kiến thức chính sách. Việc thêm đường hầm không tự nó sửa được địa chỉ mơ hồ.

Công bố toàn bộ subnet rộng hơn công bố một dịch vụ. Nếu chỉ cần vài máy hoặc cổng, hãy giữ quy tắc truy cập hẹp hơn ánh xạ.

Dịch tiêu đề không viết lại tải trọng ứng dụng. Chuyển hướng, địa chỉ nhúng trong tệp cấu hình và quyền dựa trên nguồn đều vẫn có thể mang địa chỉ gốc. Hãy kiểm tra đường dẫn ứng dụng, không chỉ ping. Một phản hồi ICMP hoạt động chứng minh ánh xạ tồn tại và không nói gì về việc ứng dụng có chấp nhận bí danh hay không.

Sửa các tên mà mỗi người gọi nhìn thấy

Cấp cho tên bảo trì những câu trả lời khớp với chế độ xem của người gọi. Nếu kỹ sư từ xa phân giải một tên máy chủ, nó phải trả về địa chỉ bí danh cho site đó, không phải dải gốc dùng chung.

Kiểm tra chế độ xem DNS cho từng site trước cửa sổ bảo trì đầu tiên. Một tên phân giải thành subnet gốc sẽ đưa người gọi trở lại sự mơ hồ mà kế hoạch phải loại bỏ.

Ghi lại và xác minh cho từng site

Chấp nhận từng site riêng biệt từ một người gọi thật và xác nhận máy nào đã trả lời. Ghi lại cùng nhau địa chỉ gốc, bí danh, cổng sở hữu và dịch vụ được phép.

Bản kiểm kê đó là thứ bảo toàn sự khác biệt khi site thứ ba đến với cùng LAN mặc định. Hướng dẫn IPsec NAT dựa trên chính sách ghi lại một mô hình dịch cụ thể; đó không phải hợp đồng cho mọi nền tảng.