Azure UDR'ден 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 сессиясы катары көрүнөт.

Тандалган префикс аркылуу транзит мажбурланган туннелдөөдөн алда канча тар өзгөртүү. Аны тар кармаңыз, артка кайтаруу — бир маршрутту жок кылуу.

Тектеш макалалар