Одна /23 замість двох /24: що змінюється в переговорах
Арифметика зведення проста, а договір ні. Порівняйте набір адрес, групування, яке приймає кожна сторона, і результат, який дає обмін.
Дві сусідні /24 охайно зливаються в одну /23, і ця охайна арифметика переконує людей, що зміна косметична. Це арифметика про адреси, а тунелю важливі селектори, які є пропозицією на переговорах, а не описом мережі. Коротший рядок може залишити той самий трафік захищеним, захистити більше, ніж задумано, або не покрити половину, залежно від того, що обидві сторони готові прийняти. Прочитати встановлений результат це єдиний спосіб дізнатися, який із цих трьох випадків стався.
Три факти, які люди зливають в один
Набір адрес каже, які хости мають бути захищені. Групування каже, як ці адреси пропонуються: один селектор чи кілька, в одній асоціації чи в кількох. Узгоджений результат каже, що обидві сторони справді встановили, і він може бути вужчим за будь-який із перших двох.
Запишіть їх окремо в журналі змін. Один рядок конфігурації часто приховує три різні відповіді. Рецензент, який не може їх розділити, не може й схвалити зміну.
Що відповідач має право робити з вашою агрегацією
Відповідач IKEv2 може звузити запропоновану пару селекторів до підмножини, яку готовий прийняти, і може взагалі відхилити пропозицію, якщо нічого прийнятного не існує. Він також може вказати, що додатковому трафіку потрібна інша асоціація, а не місце в цій.
Відповідач, який нічого не приймає, натомість повертає помилку, і це принаймні каже, що пропозицію відхилено, а не тихо звужено.
Це означає, що успішний обмін доводить, що сторони домовилися про щось, а не про все, що ви перелічили. Перше повідомлення про успіх це відправна точка для читання результату, але ніколи не висновок. Прийнята підмножина може бути меншою за одну /24, через що встановлений набір зовсім не схожий на пропозицію.
Де зведення тихо стирає межу
Дві /24 можуть мати різні правила обслуговування: одна може дозволяти лише протокол керування, інша загальний застосунок. Селектор, що охоплює обидві адреси на рівні IP, цих правил не зберігає, а зведення переносить межу в будь-яку фільтрацію, яка є за тунелем. Перелічіть правила обслуговування для кожної підмережі перед агрегуванням, інакше це порівняння ніколи не відбудеться.
Значення протоколу й порту це частина селектора, а не необов'язковий додаток. Якщо початкова політика їх обмежувала, агрегат має нести те саме обмеження, інакше зміна це зміна дозволів у костюмі маршрутизації. Якщо обмеження було суттю початкової політики, залиште його явним після зведення і напишіть про це в журналі.
Читання результату за префіксами
Після зміни дивіться на те, що встановлено, а не на те, що налаштовано. Потім згенеруйте потік із кожного префікса в кожному напрямку і перевірте лічильники, що належать асоціації, яка його обслуговує. Два префікси, що дають трафік на одній асоціації, це нормально; два префікси, де один не дає нічого, це і є знахідка.
Робіть це тим самим застосунком, який запускають користувачі. Зонд, запущений на шлюзі, перевіряє інший шлях, ніж клієнт за ним, і різниця саме там, де ховаються помилки селекторів. Рівний лічильник на префіксі, який має бути зайнятий, це сильніший доказ, ніж будь-який рядок журналу, бо він вимірює відсутність.
Як зробити зміну оборотною
Залишайте початкову політику в конфігурації, доки нова не буде перевірена з усіх комбінацій префіксів, і занотуйте, до якої асоціації потрапив кожен потік. Якщо сторона замінює асоціації, коли змінюється пропозиція, відкат має відновити стару пропозицію, а не лише старі адреси.
Узгодьте з власником іншого кінця до відкриття вікна. Зведення, яке одній стороні здається очевидним, для іншої може бути неприйнятним групуванням, і з'ясувати це під час зміни дорого. Домовтеся про пропоноване групування письмово, потім порівняйте його з тим, що встановлює обмін. Тримайте цю домовленість у заявці на зміну, а не в гілці чату, яка зникне наступного тижня.