Маршрутизиране на трафик между два клона през VPN шлюз на Azure
Две връзки сайт към сайт на един VPN шлюз на Azure могат да пропускат трафик между клоните, но само когато двата края научат префикса и съществува обратен път в LAN.
Два клона могат да обменят трафик през VPN шлюз на Azure без директен тунел помежду им. Всеки клон отваря връзка сайт към сайт към същия шлюз и шлюзът предава научените префикси между двете връзки. Това, което го прави работещо, не е вторият тунел, а обменът на маршрути: клон A трябва да научи префикса на клон B, а B — този на A. Прегледайте проверките по-долу по ред и спрете на първата, която се провали, защото всяка следваща стъпка зависи от нея.
Предварителни условия, преди да конфигурирате каквото и да е
Четири условия решават дали този дизайн може да работи изобщо. Шлюзът трябва да е базиран на маршрути и на SKU, който поддържа BGP, двете връзки трябва да имат включен BGP, адресните пространства на клоните не трябва да се застъпват и никоя страна не бива да разчита на NAT, за да скрие реалния си префикс.
Планирайте ASN-ите съзнателно. Документираната стойност по подразбиране в Azure е 65515 и всеки маршрутизатор на клон се нуждае от собствен частен ASN, който не се сблъсква с шлюза или с другия клон. Повторното използване на стойност по подразбиране без проверка на съществуваща конфигурация на шлюз е начинът, по който AS път по-късно бива отхвърлен.
Също така потвърдете, че не очаквате поведение на VNet peering. Шлюзът обменя маршрути между двете връзки, които сте конфигурирали; той не прави произволни peering връзки транзитивни. Ако трета мрежа трябва да достигне до двата клона, тя се нуждае от собствена връзка или собствен път на маршрут, а не от предположението, че шлюзът ще разпръсне трафика. Запишете тази граница преди първия прозорец за промяна, защото това е дизайнерското решение, към което хората се връщат, когато по-късно се добави сайт.
Конфигурирайте в този ред
Всяка стъпка има наблюдаем резултат, така че не продължавайте, докато той не се появи.
- Включете BGP на шлюза на виртуалната мрежа и запишете неговия ASN и адрес на партньора.
- Създайте локален мрежов шлюз за всеки клон с реалното адресно пространство на клона, неговия ASN и адреса му за BGP партньор.
- Създайте всяка връзка сайт към сайт и включете BGP на самата връзка.
- Конфигурирайте маршрутизатора на клона да партнира с адреса на шлюза, който Azure е задал, а не с публичната IKE крайна точка на шлюза по предположение.
Четвъртата стъпка е мястото, където повечето опити засядат. Адресът за BGP партньор, който Azure отчита, е този, който маршрутизаторът на клона трябва да използва като съсед, и той не винаги е адресът, който хората очакват от схемата на тунела.
Обявете самия префикс на клона, например 10.10.0.0/16 от A и 10.20.0.0/16 от B. Не обявявайте маршрут по подразбиране или широк агрегат, за да покриете липсваща конкретна мрежа; празнината се връща по-късно като тиха черна дупка.
Проверете обмена на маршрути в двата края
Състоянието на връзката не е проверката. IPsec може да е активен на двете връзки, докато нито един префикс не преминава между тях. Прочетете BGP партньорите на шлюза и научените му маршрути, след което потвърдете, че маршрутът към другия клон се появява като използваем път.
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
Префикс, присъстващ в BGP таблица, все още може да загуби решението за препращане от статичен маршрут или по-конкретен префикс. Проверявайте избрания маршрут, не само получения.
Следете обратния път от страната на LAN
Това е частта, която изглежда правилна в Azure и се проваля на място. Хост в клон A изпраща пакета си към VPN маршрутизатора на A само ако този маршрутизатор е неговият шлюз по подразбиране или ако хостът или неговият шлюз има маршрут за префикса на B. Същото трябва да е вярно и в обратната посока.
Ако отделен основен комутатор е шлюзът по подразбиране на LAN, той се нуждае от маршрут към другия клон, сочещ към VPN маршрутизатора. Без него заявката пристига и отговорът излиза по интернет пътя, а потребителят вижда връзка, която се отваря и след това засича.
Не прибягвайте до група за мрежова сигурност в подмрежата на шлюза, за да поправите това. Тази подмрежа има собствени изисквания и NSG там не е поддържана замяна на политиката от страната на клона. Филтрирането принадлежи на защитните стени на клоните и на самите работни натоварвания, където правилата могат да бъдат прегледани от хората, които ги притежават. Преместването на тези правила в NSG на подмрежата също ги скрива от екипа, който ще отстранява следващата повреда.
Разрешете операцията, после я докажете със забранен тест
Наученият маршрут не е разрешение. Разрешете източника, дестинацията и услугата, които действително ви трябват, през защитните стени на клоните и политиката на крайната точка, а останалото оставете забранено.
Тествайте от обикновено работно натоварване в клон A към реална услуга в клон B, потвърдете отговора, след което опитайте операция, която трябва да остане забранена. Трафикът, генериран от самото VPN устройство, може да използва различен адрес на източника и да прескочи етапа на LAN маршрутизация, така че успешен ping от маршрутизатора доказва по-малко, отколкото изглежда.
Завършете, като запишете четири факта: обменените префикси, използваните ASN, обратния LAN път за всяка страна и политиката, която допуска услугата. Ако един от тях липсва, конфигурацията работи до първата промяна и след това никой не може да обясни защо.