Lập kế hoạch subnet trước VPN site: đánh số lại hoặc dịch địa chỉ

Hai văn phòng cùng dùng 192.168.1.0/24 vì không ai lập kế hoạch khác, và người ta trông đợi tunnel sẽ giải quyết. Nó không thể: router không thể làm cho cùng một địa chỉ riêng tư mang nghĩa hai nơi khác nhau. Công việc ngăn chặn điều đó diễn ra trước khi tham số tunnel đầu tiên được nhập.

Kiểm kê từng dải, kể cả những dải bạn đã quên

Thu thập các LAN, phân đoạn máy chủ, nhóm máy khách truy cập từ xa, dải VPC trên đám mây và mọi mạng container hoặc lớp phủ mà máy chủ phải đến được. Nhóm máy khách là thứ người ta hay quên, và chúng chồng lấn với dải văn phòng thường xuyên đến bất ngờ vì cả hai đều được chọn từ cùng một giá trị mặc định. Bao gồm mạng quản trị và mọi phân đoạn ngoài băng.

Ghi lại chủ sở hữu, cổng, mục đích và việc tiền tố có phải đến được từ site kia hay không. Một tiền tố không bao giờ cần đi qua tunnel không cần phải duy nhất, và biết điều đó giảm công việc đánh số lại.

Làm IPv6 riêng, vì kế hoạch và các chồng lấn của nó độc lập.

So sánh tiền tố, không phải địa chỉ quen thuộc

Hai mạng có địa chỉ máy chủ khác nhau vẫn có thể chồng lấn, vì chồng lấn là thuộc tính của mặt nạ chứ không phải của những con số người ta nhớ. 10.20.0.0/16 chứa 10.20.30.0/24 dù có ai nói to điều đó hay không. Hãy so sánh các cặp tiền tố đầy đủ, và kiểm tra các tổng hợp với những mạng nhỏ hơn bên trong chúng. Đó là lý do việc kiểm tra thuộc về một bảng tính chứ không phải đầu của ai đó.

Cùng phép kiểm tra đó áp dụng cho nhóm máy khách của chính VPN và cho mọi dải dịch địa chỉ bạn định đưa vào, vì một dải dịch bị đụng độ còn tệ hơn chồng lấn ban đầu.

Một bảng tiền tố kèm mặt nạ là đủ; một sơ đồ không có mặt nạ thì không.

Quyết định cái gì thực sự phải đi qua

Một site có thể có ba mươi subnet trong khi một mạng dịch vụ cần truy cập từ xa. Hãy bắt đầu từ yêu cầu đó và chỉ quảng bá những gì nó cần, vì quảng bá nhỏ hơn và quy tắc truy cập khớp sẽ dễ rà soát hơn và khó bị nới rộng do sơ suất. Quảng bá mọi dải riêng tư đang dùng là thói quen biến tunnel thành cầu. Quảng bá càng hẹp thì bán kính ảnh hưởng của một sai sót tương lai càng nhỏ.

DNS riêng phải trả về địa chỉ mà các máy khách dự định có thể đến được, nên một cái tên trỏ tới dải không được quảng bá hoặc chồng lấn vẫn hỏng kể cả khi tra cứu thành công.

Viết danh sách truy cập trước khi cấu hình tunnel, không phải sau khi nó thất bại.

Đánh số lại hoặc dịch, và biết chi phí

Đánh số lại một mạng thường là giải pháp rõ ràng nhất về lâu dài, và nó chạm tới đặt trước, thiết bị, DNS, quy tắc tường lửa và mọi thứ có địa chỉ nằm cứng trong cấu hình. Dịch một dải truy cập là lựa chọn thay thế khi việc đánh số lại không thực tế, và nó tốn danh tính nguồn cộng với một lớp giao thức nhúng địa chỉ trong tải trọng. Chọn một và hoàn tất, vì một mạng đánh số lại dở dang còn tệ hơn cả hai phương án.

Dù chọn cách nào, hãy ghi lại cả địa chỉ gốc và địa chỉ được trình bày, vì mọi cuộc trò chuyện xử lý sự cố sau này đều cần cả hai.

Một giải pháp không có đường về không phải là giải pháp.

Dùng ma trận tuyến làm bài kiểm tra chấp nhận

Kết thúc bằng một ma trận: tiền tố cục bộ, tiền tố từ xa, dịch vụ được phép và cổng trả về. Bảng đó là bài kiểm tra chấp nhận khi tunnel dựng lên, và nó cũng là tài liệu mà kỹ sư tiếp theo sẽ đọc. Hãy thử từ máy chủ thật trên các subnet đã chọn chứ không phải từ cổng.

Một ping giữa các địa chỉ tunnel chứng minh tunnel tồn tại và không nói gì về kế hoạch địa chỉ phía sau.

Giữ ma trận cùng với cấu hình tunnel, và lần thêm site tiếp theo sẽ bắt đầu từ dữ liệu chứ không phải ký ức. hướng dẫn chuyển tiếp của strongSwan bao quát phía cổng khi đã có kế hoạch.