NAT в Azure VPN не вирішує проблему перетинних адрес VNet
Дві мережі VNet з однаковим приватним діапазоном не з'єднаються лише тому, що є NAT. Спершу перевірте тип підключення, потім перенумеруйте адреси або володійте псевдонімом трансляції.
Обидві VNet використовують 10.40.1.0/24, тунелі піднімаються, і нічого не працює. Додавання другого шлюзу VPN цього не змінює, як і нижча метрика маршруту, бо проблема не у виборі шляху. Два робочі навантаження, що відповідають на ту саму приватну адресу, залишають кожен пакет із неоднозначним призначенням і неперевірюваним зворотним шляхом. Перш ніж планувати будь-яку трансляцію, з'ясуйте, який тип підключення ви насправді створили, адже саме цей вибір визначає, чи доступна функція NAT в Azure взагалі.
Що насправді каже цей симптом
Коли вузол у VNet A надсилає на 10.40.1.10, таблиця маршрутизації може лише направити його кудись. Якщо VNet B також містить 10.40.1.10, ця адреса не є призначенням, яке шлях може розрізнити; це одна адреса з двома власниками.
Другий шлюз, який зазвичай розгортають, не допомагає. Він дає ще один тунель, а не ще одну адресу, і дублікат діапазону проходить усередині тунелю без змін. Він також подвоює конфігурацію, яку треба тримати узгодженою. Чого він не може — зробити так, щоб одна адреса означала два вузли.
Зміна публічних адрес партнерів VPN також нічого не дає. Ці адреси визначають кінцеві точки тунелю, тоді як конфлікт міститься в приватному діапазоні, що переноситься всередині.
Тип підключення визначає, чи доступний NAT
У Azure VPN Gateway справді є можливість NAT, і вона задокументована для маршрутних підключень IPsec між майданчиками на певних SKU шлюзу. Та сама документація виключає підключення VNet-to-VNet і «точка — сайт», тож ця функція не є прапорцем, який з'являється в кожному відношенні шлюзу.
| Connection type | NAT support | Overlap workaround |
|---|---|---|
| Site-to-Site (route-based IPsec, documented SKUs) | Supported with configured NAT rules | Translate the range in the rules |
VNet-to-VNet (Vnet2Vnet) | Not supported | Renumber, or redesign as a site-to-site connection |
| Point-to-site | Not supported | Choose client address pools that do not collide |
Власний VNet-to-VNet також вимагає, щоб діапазони VNet і локальної мережі від початку не перетиналися, що узгоджується з цим виключенням. Об'єднання VNet у піринг з тієї ж причини не є рішенням проблеми перетину.
Є підтримувана альтернатива, яку плутають із власним типом: уявити іншу VNet як локальну мережу й підключити її як з'єднання між майданчиками. Це інший ресурс і інший проєкт, тому перейменоване підключення слід сприймати як зміну, що потребує перевірки, а не як просте перейменування.
Перенумеруйте адреси або транслюйте за допомогою того, що володіє псевдонімом
Якщо обидві VNet ваші, порівняйте заплановану перенумерацію з постійними витратами на трансляцію. Перенумерація зачіпає конфігурацію застосунків, записи DNS, правила безпеки та кожне наявне підключення, але залишає мережу, яка потім читається нормально. Робіть це по одній підмережі, а зміну DNS — останньою. Наполовину перенумерований діапазон гірший за будь-який варіант, бо тоді обидва префікси виглядають достовірними для того, хто прочитає таблицю наступним.
Там, де перенумерація недоцільна, використовуйте трансльований проєкт із реальним власником псевдоніма. Ті, хто звертається з VNet A, можуть досягати 10.40.1.10 у VNet B як 10.140.1.10, але цьому псевдоніму потрібні пристрій, що транслює, маршрут до нього й узгоджена поведінка для відповіді. Адреса, додана лише в DNS, не є трансляцією.
Зафіксуйте обидва діапазони в обох напрямках: що набирає сторона, яка викликає, що бачить призначення як джерело і яка сторона може ініціювати. Власні правила NAT в Azure містять зворотну трансляцію для своїх зіставлень SNAT, тому відповідне правило DNAT вручну не пишеться, але ця зручність закінчується на типах підключень, які підтримує функція.
Що не спрацює
Визначений користувачем маршрут або метрика маршруту не можуть створити відсутнє розрізнення адрес. Обидва працюють із призначенням, яке досі неоднозначне, і пакет надходить до того наступного вузла, якому надає перевагу таблиця.
Додавання дубліката діапазону до таблиці маршрутизації як конкретнішого префікса зсуває неоднозначність лише на крок. Воно також зазвичай ламає зворотний напрямок, де відповідь тепер має два ймовірні джерела.
Прийміть проєкт із трафіком в обох напрямках
Доведіть проєкт свіжою дозволеною операцією з кожного боку, а не станом тунелю. Підключений тунель IPsec каже, що партнери згодні щодо шифрування; він нічого не каже про те, чи стали призначення розрізнюваними.
Потім виконайте заборонені шляхи: адресу, яка має залишатися недосяжною, і службу, яку політика має блокувати. Якщо обидва досі успішні, трансляція ширша, ніж передбачав проєкт.
Завершіть фактами, які пояснять налаштування пізніше: початковий діапазон, поданий діапазон, пристрій, що транслює, і напрямок, у якому кожна сторона може ініціювати. Якщо чогось із цього бракує, наступний інженер успадкує мережу, де два вузли поділяють одне ім'я і ніхто не пам'ятає, чому один із них відповідає.