UDR в Azure към VPN шлюз: една дестинация, а не целия изходящ трафик

Насочете един префикс в Azure към VPN шлюза, без да местите целия изходящ трафик. Прочетете ефективните маршрути, свържете подмрежата и завършете пътя за връщане.

Добавяте дефиниран от потребителя маршрут за един външен префикс, насочвате го към VPN шлюза и трафикът все още излиза по интернет пътя на Azure. Или излиза правилно и отговорът никога не се връща. И двата резултата идват от една и съща грешка: разглеждането на следващия хоп на Azure като целия дизайн. Таблицата с маршрути решава само кой изход взема пакетът вътре в Azure. Какво се случва с него след тунела и как се връща отговорът е втората половина, която трябва да построите.

Следващият хоп е шлюз, а не IP на устройство

UDR изпраща съответстващ префикс към тип следващ хоп, а VirtualNetworkGateway е тип, не адрес. Хората поставят частния IP на шлюза в маршрут VirtualAppliance и после се чудят защо нищо не съвпада, защото този тип очаква вместо това NIC или вътрешен балансьор на натоварването. Документацията на Microsoft за маршрутизация също ограничава следващия хоп на шлюза до виртуална мрежа, чийто шлюз е VPN шлюз. ExpressRoute, Route Server и хъб на Virtual WAN не се адресират от тази опция.

Проверете какво всъщност има виртуалната мрежа, преди да напишете маршрута. Ако дизайнът маршрутизира през хъб, маршрутът принадлежи на собственика на маршрутизацията на хъба, а не на спока, който редактирате случайно.

Прочетете ефективния маршрут, преди да променяте каквото и да е

Azure комбинира системни маршрути, префикси, научени по BGP, и UDR в ефективна таблица с маршрути за всеки NIC, и най-дългият съвпадащ префикс печели независимо откъде идва. За един и същ префикс UDR побеждава BGP маршрут. Това подреждане е причината остарял UDR от по-ранен експеримент тихо да замести префикса, който току-що научихте през тунела.

Погледнете първо ефективната таблица, после решете дали добавяте маршрут, или заменяте такъв:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Четете колоната за източник заедно с префикса. Маршрут с правилния префикс и грешен източник ви казва кой обект да редактирате и ви спестява добавянето на втори маршрут, който губи от първия.

Пишете маршрута спрямо реалния префикс и подмрежа

Използвайте реалния префикс на дестинацията, взет от услугата, до която действително достигате, вместо публичен диапазон, копиран от форумна публикация. Започнете с една одобрена услуга, преди да обмисляте маршрут по подразбиране, който мести целия изходящ трафик. След това прикачете таблицата с маршрути към подмрежата на натоварването. Подмрежата на шлюза има свои изисквания и прикачването на таблицата там чупи шлюза, вместо да насочва натоварването.

Създайте маршрута, след което свържете таблицата с подмрежата, която хоства натоварването:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Разпространението също има значение. С включено BGP разпространение на тази таблица научените префикси се появяват редом с написаните от вас и по-конкретен научен префикс може да победи по-общ UDR. Изключвайте разпространението само когато искате наборът от UDR да е авторитетен за тази подмрежа.

Завършете локалната половина, иначе потокът умира там

Локалният шлюз трябва да приеме източника от Azure, да го препрати към дестинацията и да разреши приложението. Пътят му нататък може да е интернет изход или друг частен хоп, но това решение принадлежи на плана, не на таблицата с маршрути на Azure. Обичайният провал е връщането. Интернет дестинация няма да маршрутизира частен източник от Azure обратно към вас, затова отговорът отива към собствения си шлюз по подразбиране и умира, или изобщо не излиза.

Два дизайна решават това и те не са взаимозаменяеми. Транслирайте източника на изхода, така че дестинацията да отговаря на публичен адрес, който локалната мрежа притежава. Или запазете източника и изградете маршрутизирана връзка за връщане, така че отговорите да се връщат през тунела. Изберете едно и запишете кой адрес ще види приложението.

Селекторите и списъците с разрешени са отделно от всичко това. Изборът на следващ хоп в Azure не разширява селекторите на VPN трафика и не променя списъка с разрешени източници на външна услуга.

Проверете с наблюдавания от дестинацията източник

Изпратете заявката от реалното натоварване, а не от скоков хост в друга подмрежа, после прочетете адреса на източника, който дестинацията е наблюдавала. Тази единствена стойност ви казва кой от двата дизайна за връщане е налице. След това проверете пътя на отговора и потвърдете, че обичайният административен трафик към VM все още работи, защото маршрут по подразбиране, добавен по грешка, се проявява като счупена SSH сесия много преди да се прояви като счупено приложение.

Транзитът през избран префикс е далеч по-тясна промяна от принудително тунелиране. Дръжте го тесен и връщането назад е изтриване на един маршрут.

Подобни статии