Два сайти, одна підмережа: створіть окреме подання псевдонімів для кожного

Два клієнтські сайти використовують 192.168.50.0/24, і віддаленому інженеру потрібно потрапити до принтера за тією самою адресою в кожному з них. Жоден трюк маршрутизації не розв'язує цю неоднозначність сам по собі. Кожному сайту потрібен окремий погляд на адреси, і шлюз має вибрати сайт із цього подання, перш ніж щось пересилати.

План має чотири частини: префікси псевдонімів, обидва напрямки перекладу, політика накладання та імена. Кожна має узгоджуватися з іншими.

Виберіть один префікс псевдоніма на сайт

Призначте кожному сайту цілий префікс псевдоніма, який не належить нікому іншому в середовищі. План для двох сайтів може зіставити 192.168.50.0/24 сайту A з 172.21.10.0/24, а ідентичну локальну мережу сайту B — з 172.21.20.0/24. Перевірте кандидатів щодо кожної задіяної мережі, включно з хмарними VPC та іншими пулами VPN. Приватний адресний простір поділяють усі організації, тому те, що діапазон належить до RFC 1918, нічого не каже про його вільність тут.

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

Перекладайте в обох напрямках

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

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

Точний етап, на якому застосовуються політика, селектори та маршрути, відрізняється між IPsec на основі політик, тунелями на основі маршрутів та іншими продуктами. Проєктуйте під той, який ви експлуатуєте.

Проведіть план через накладання

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

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

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

Виправте імена, які бачить кожен викликач

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

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

Записуйте й перевіряйте для кожного сайту

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

Саме цей перелік зберігає розрізнення, коли з'являється третій сайт із тією самою LAN за замовчуванням. Посібник з IPsec NAT на основі політик описує одну конкретну модель перекладу; це не контракт для кожної платформи.