Два локални 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 или клъстер, вместо да извеждате излишност от броя на адресите. После го тествайте: премахвайте по един път наведнъж и потвърждавайте оставащите маршрути плюс реален обмен на приложение в двете посоки.

Очаквайте закъснения при откриване и сближаване и очаквайте някои съществуващи сесии да приключат.