Дві локальні адреси VPN: два партнери Azure, а не один

На схемі два інтернет-канали у філії та один шлюз VPN в Azure, тому шлюз локальної мережі отримує обидві публічні адреси. Виглядає охайно і працює не так, як припускає схема. Кожен локальний пристрій VPN — це окремі партнерські відносини, і проєкт Microsoft для кількох пристроїв дає кожному свій ресурс шлюзу локальної мережі та своє підключення. Додавання другої адреси до одного ресурсу не створює другого партнера. Воно створює ресурс, який не описує правильно жодного з двох пристроїв.

Міф: один шлюз, дві адреси

Шлюз локальної мережі — це опис віддаленого партнера: одна публічна кінцева точка та приватні префікси за нею. Немає підтримуваного способу змусити цей ресурс означати «будь-який із цих двох пристроїв».

Та сама плутанина трапляється і в зворотному напрямку, де дві публічні IP-адреси Azure читаються як доказ існування двох шлюзів Azure.

Спочатку порахуйте об'єкти, потім тунелі

Візьміть два незалежно керовані локальні пристрої, кожен зі своєю публічною адресою та доступом до тих самих приватних мереж, плюс один шлюз Azure на основі маршрутизації в режимі активний-активний. Шлюз Azure має два активні екземпляри з окремими публічними IP-адресами. Кожен локальний пристрій підключається до обох екземплярів. Це повна сітка, і кількість об'єктів випливає з неї, а не зі схеми.

Арифметика достатньо коротка, щоб вставити її в проєктний документ:

2 on-premises VPN devices
2 local network gateway resources
2 connection resources
4 IPsec tunnels in the complete 2 x 2 mesh

Один ресурс підключення може нести більше одного базового тунелю, тому чотири тунелі не означають чотири шлюзи віртуальної мережі. Дві публічні IP-адреси Azure також не ті самі об'єкти, що два шлюзи локальної мережі, які описують віддалений сайт.

Що додає режим активний-активний на боці Azure

Режим активний-активний перетворює шлюз Azure з одного активного екземпляра на два, кожен зі своєю публічною IP-адресою, і саме це взагалі уможливлює повну сітку. Він не подвоює пропускну здатність одного потоку. Він також не усуває потреби локальної сторони підтримувати багатошляхову маршрутизацію з рівною вартістю, якщо обидва пристрої передають одночасно. Підтвердьте режим шлюзу, SKU та можливості віддаленого пристрою, перш ніж щось розгортати.

Шлюз у режимі пасивного очікування — цілком припустимий проєкт; він просто дає іншу кількість тунелів.

BGP робить обидва шляхи придатними до використання

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

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

Вибір на основі потоку — це не об'єднання пропускної здатності

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

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

Яку надмірність ви насправді прибрали

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

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