Сплануйте підмережі до VPN між майданчиками: перенумеруйте або транслюйте

Два офіси обидва використовують 192.168.1.0/24, бо ніхто не спланував інакше, а тунель має це вирішити. Він не може: маршрутизатор не може зробити так, щоб та сама приватна адреса означала два різні місця. Робота, яка це запобігає, виконується до введення першого параметра тунелю.

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

Зберіть LAN, серверні сегменти, пули клієнтів віддаленого доступу, діапазони хмарних VPC і будь-які контейнерні або оверлейні мережі, до яких мають дістатися хости. Пули клієнтів — це ті, які забувають, і вони напрочуд часто перетинаються з офісним діапазоном, бо обидва вибрані з одного типового значення. Включіть мережу керування та будь-який сегмент поза смугою.

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

Робіть IPv6 окремо, бо його план і його перетини незалежні.

Порівнюйте префікси, а не знайомі адреси

Дві мережі з різними адресами хостів усе одно можуть перетинатися, бо перетин — це властивість масок, а не чисел, які люди запам'ятовують. 10.20.0.0/16 містить 10.20.30.0/24, каже хтось це вголос чи ні. Порівнюйте повні пари префіксів і перевіряйте агрегати щодо менших мереж усередині них. Тому перевірка належить до таблиці, а не до чиєїсь голови.

Та сама перевірка стосується власного пулу клієнтів VPN і будь-якого трансльованого діапазону, який ви плануєте запровадити, бо конфліктний трансльований діапазон гірший за початковий перетин.

Таблиці префіксів із масками достатньо; схеми без масок — ні.

Вирішіть, що насправді має проходити

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

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

Напишіть список доступу до конфігурації тунелю, а не після її відмови.

Перенумеруйте або транслюйте і знайте ціну

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

Що б ви не вибрали, задокументуйте і початкову, і подану адресу, бо кожній подальшій розмові про усунення несправностей потрібні обидві.

Обхідний шлях без зворотного шляху — не обхідний шлях.

Використовуйте матрицю маршрутів як приймальний тест

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

Ping між адресами тунелю доводить, що тунель існує, і нічого про план адрес за ним.

Зберігайте матрицю разом із конфігурацією тунелю, і наступне додавання майданчика почнеться з даних, а не з пам'яті. Коли план існує, керівництво strongSwan з пересилання охоплює бік шлюзу.