Azure UDR кон 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 сесија многу пред да се појави како расипана апликација.

Транзитот преку избран префикс е далеку потесна промена од присилно тунелирање. Држете го тесен и враќањето е бришење на една рута.