Двом активним тунелям IPsec усе ще потрібен план зворотного шляху

Відкрийте термінал на робочій станції на одному сайті й підключіться до сервера на іншому. Цій єдиній розмові TCP тепер треба пройти через чотири шлюзи замість двох, і цікаве не в тому, чи працює вона в добрий день. Цікаве в тому, яку пару шлюзів обрало пряме напрям, яку пару обирає відповідь і хто тримає стан потоку, поки це відбувається. Ніщо в таблиці маршрутизації не вирішує це за вас.

Намалюйте чотири шлюзи, перш ніж малювати маршрут

Двоактивна схема з двома незалежними міжмережевими екранами VPN на кожному сайті, по парі на провайдера, дає два придатні шляхи й три способи їх зламати. Запишіть адреси, перш ніж щось налаштовувати: клієнт, як він видимий до і після кожного шлюзу, сервер так само, наступний крок уперед і наступний крок назад.

Ця таблиця і є проєкт. Усе після неї — питання, чи згодні пристрої з таблицею.

Як обирається прямий шлях

Рівень багатошляхової маршрутизації з рівною вартістю розподіляє потоки за наступними кроками, хешуючи поля заголовка, що докладно описує RFC 2992. Цей вибір може бути цілком безстановим: йому не потрібен запис відстеження з'єднань, лише стабільний хеш за незмінними полями. Тримайте набір шляхів і вхідні дані хешу сталими, і кожен пакет потоку обере той самий наступний крок.

Вибір за потоком уникає перевпорядкування, яке спричинило б балансування пакет за пакетом на каналах з різними затримками. Він не обіцяє, що рівна вартість маршрутизації означає рівну виміряну затримку, бо це не так. А коли склад шляхів змінюється, потоки перепризначаються, тож виживання з'єднання під час збою — окрема вимога від вибору шляху.

Що насправді потрібно зворотному шляху

Тут прогулянка перестає бути симетричною. Стабільний прямий хеш нічого не каже про те, що далекий сайт зробить з відповіддю. Якщо незалежний міжмережевий екран має бачити обидва напрямки з'єднання, щоб тримати корисний стан, зворотний маршрут в обхід нього залишає трафік, що нічому не відповідає. Два ящики зі схожими наборами правил — не спільний стан.

Підтвердьте реалізовану двобічну поведінку або напишіть явну політику, яка тримає потрібні межі узгодженими. Здогад тут виявляється під час збою, людьми, яким це не подобається.

Де трансляція вирішує за вас

NAT — інший важіль, і він необов'язковий, а не обов'язковий. Трансльовані ідентичності, прив'язані до шляху, можуть спрямовувати відповіді назад до шлюзу, який тримає стан, і це законна схема. Але вони додають відображення, зворотні маршрути й власника цього стану, тож беріть навантаження лише заради вимоги, яку можете назвати вголос.

Якщо вимога просто в тому, щоб обидва шляхи несли трафік і будь-який із них пережив втрату провайдера, звичайна багатошляхова схема за потоком з узгодженою зворотною маршрутизацією зазвичай менша.

Пройдіть приймання по порядку

Перевіряйте в цьому порядку й записуйте адреси на кожному кроці: нове з'єднання на шляху A та його зворотний шлях, те саме на шляху B, потім втрата одного провайдера, потім відновлення. Для кожного результату позначте, які усталені потоки зрушили, яким довелося перепідключитися й куди потім пішли нові потоки. Спочатку запишіть очікуване значення, потім порівняйте його з захопленням. Два усталені тунелі нічого з цього не доводять.

Проєкт завершено, коли написана вами таблиця збігається з тим, що показує захоплення, а не коли піднято обидва тунелі.