Một /23 thay vì hai /24: điều gì thay đổi trong đàm phán

Hai /24 liền kề gộp gọn thành một /23, và phép số học gọn gàng đó khiến người ta tin rằng thay đổi chỉ là bề ngoài. Đó là số học về địa chỉ, còn tunnel quan tâm đến selector, thứ là một đề nghị đàm phán chứ không phải mô tả mạng. Dòng ngắn hơn có thể để lưu lượng đó vẫn được bảo vệ, bảo vệ nhiều hơn dự định, hoặc không bao phủ nổi một nửa, tùy vào việc hai bên sẵn sàng chấp nhận điều gì. Đọc kết quả đã cài đặt là cách duy nhất để biết điều nào trong ba điều đó đã xảy ra.

Ba sự thật mà người ta gộp thành một

Tập địa chỉ cho biết host nào cần được bảo vệ. Cách nhóm cho biết các địa chỉ đó được đề nghị ra sao: một selector hay nhiều, trong một liên kết hay nhiều hơn. Kết quả đàm phán cho biết hai bên thực sự đã cài đặt gì, và nó có thể hẹp hơn bất kỳ điều nào trong hai điều đầu.

Hãy viết chúng riêng rẽ trong bản ghi thay đổi. Một dòng cấu hình thường che giấu ba câu trả lời khác nhau. Người đánh giá không tách được chúng thì cũng không thể phê duyệt thay đổi.

Bên phản hồi được phép làm gì với tập tổng hợp của bạn

Một bên phản hồi IKEv2 có thể thu hẹp cặp selector được đề nghị thành một tập con mà nó sẵn sàng chấp nhận, và có thể từ chối thẳng đề nghị nếu không có gì chấp nhận được. Nó cũng có thể chỉ ra rằng lưu lượng bổ sung cần một liên kết khác thay vì vừa vào liên kết này.

Bên phản hồi không chấp nhận gì sẽ trả về lỗi thay vào đó, điều này ít nhất cho biết đề nghị đã bị từ chối chứ không bị thu hẹp trong im lặng.

Điều đó nghĩa là một trao đổi thành công chứng minh các bên đã đồng ý về một điều gì đó, không phải rằng họ đồng ý về mọi thứ bạn liệt kê. Thông báo thành công ban đầu là điểm khởi đầu để đọc kết quả, không bao giờ là kết luận. Tập con được chấp nhận có thể nhỏ hơn một /24, khiến tập đã cài đặt trông chẳng giống đề nghị chút nào.

Nơi một bản tóm tắt lặng lẽ xóa một ranh giới

Hai /24 có thể có các quy tắc dịch vụ khác nhau: một bên chỉ cho phép một giao thức quản trị, bên kia một ứng dụng chung. Một selector bao trùm cả hai địa chỉ ở lớp IP không giữ được các quy tắc đó, và bản tóm tắt chuyển ranh giới vào bất kỳ việc lọc nào phía sau tunnel. Hãy liệt kê quy tắc dịch vụ theo từng subnet trước khi tổng hợp, nếu không phép so sánh đó sẽ không bao giờ diễn ra.

Giá trị giao thức và cổng là một phần của selector, không phải phần thêm tùy chọn. Nếu chính sách gốc giới hạn chúng thì tập tổng hợp phải mang cùng giới hạn đó, nếu không thay đổi là một thay đổi quyền đang mặc áo định tuyến. Nếu giới hạn chính là điểm cốt lõi của chính sách gốc, hãy giữ nó rõ ràng sau bản tóm tắt và ghi điều đó vào bản ghi.

Đọc kết quả theo từng tiền tố

Sau thay đổi, hãy nhìn vào những gì đã cài đặt chứ không phải những gì đã cấu hình. Sau đó tạo một luồng từ mỗi tiền tố theo mỗi hướng, và kiểm tra các bộ đếm thuộc về liên kết xử lý nó. Hai tiền tố tạo lưu lượng trên một liên kết là ổn; hai tiền tố mà một trong đó không tạo ra gì chính là phát hiện.

Hãy làm điều này bằng đúng ứng dụng mà người dùng chạy. Một phép thử bắt đầu tại cổng sẽ thử một đường khác với một máy khách phía sau nó, và sự khác biệt nằm đúng chỗ các lỗi selector ẩn náu. Một bộ đếm phẳng trên tiền tố lẽ ra phải bận là bằng chứng mạnh hơn bất kỳ dòng log nào, vì nó đo sự vắng mặt.

Làm cho thay đổi có thể đảo ngược

Hãy giữ chính sách gốc trong cấu hình cho đến khi chính sách mới được thử từ mọi tổ hợp tiền tố, và ghi lại mỗi luồng rơi vào liên kết nào. Nếu một bên thay liên kết khi đề nghị thay đổi, việc khôi phục phải trả lại đề nghị cũ chứ không chỉ các địa chỉ cũ.

Hãy phối hợp với chủ của đầu bên kia trước khi mở cửa sổ. Một bản tóm tắt mà một bên thấy hiển nhiên có thể là cách nhóm không chấp nhận được với bên kia, và phát hiện điều đó giữa lúc thay đổi thì tốn kém. Hãy thống nhất cách nhóm được đề nghị bằng văn bản, rồi so sánh nó với những gì trao đổi cài đặt. Hãy giữ thỏa thuận đó trong phiếu thay đổi, không phải trong một luồng chat sẽ biến mất vào tuần sau.