Azure приватен IP VPN преку ExpressRoute без NVA

Митот е дека шифрирањето на сообраќајот преку приватниот peering на ExpressRoute бара виртуелен мрежен уред. Не бара. Azure поддржува Site-to-Site VPN Gateway чијашто крајна точка на тунелот е приватна RFC1918 адреса што се пренесува преку колото, а уредот е опционален, а не структурен. Она што митот за уредот го крие е делот што навистина боли: овозможување на приватната крајна точка на еден објект наместо на два, и дозволување директна peering рута тивко да победи над шифрираната патека.

Од каде дојде митот

Тврдењето има почитувано потекло. Со години практичниот рецепт за IPsec преку приватен peering беше NVA, бидејќи управуваната порта изложуваше само јавни крајни точки. Тоа се промени, а одговорите напишани пред промената сè уште се цитираат во нишки каде никој не го проверува датумот. Исправката е тесна: постои VPN порта со приватна адреса, и таа ја менува крајната точка, не логиката за рутирање околу неа.

Ништо од ова не ја пензионира NVA. Тоа ја пензионира претпоставката дека уредот е единствениот пат до барањето.

Овозможете ја приватната крајна точка на двете нивоа

Започнете од работно ExpressRoute приватно peering поврзување поврзано со VNet-от во кој е VPN портата. Локалната страна веќе мора да ги достигнува релевантните приватни адреси преку тоа коло, бидејќи тунелот ќе ги користи тие адреси како транспорт. Потоа предусловот на портата: постапката на Microsoft за приватна IP VPN бара порта изградена на Standard јавен IP ресурс. Приватното адресирање на тунелот не го отстранува тоа барање, што ги изненадува оние што претпоставуваат дека „приватно“ значи „никаде јавен IP“.

Сега овозможете го знаменцето на двете места. Конфигурацијата на портата има свој прекинувач за приватни IP-а, а одделното Site-to-Site поврзување има втор што го тера тоа поврзување да ја користи приватната адреса. Поставувањето едно без другото е најчестата нецелосна конфигурација; тунелот или не се воспоставува или се воспоставува кон погрешна крајна точка.

az network vnet-gateway update -g rg-net -n vpngw-prod --set enablePrivateIpAddress=true
az network vpn-connection update -g rg-net -n conn-onprem --set enablePrivateIpAddress=true
az network vnet-gateway show -g rg-net -n vpngw-prod \
  --query '{sku:sku,priv:enablePrivateIpAddress,active:activeActive}'

Проверете ги имињата на својствата спрема инсталираната CLI верзија, бидејќи ознаките на порталот и CLI својствата не секогаш ја делат истата формулација. Активна-активна порта изложува две приватни тунелски адреси, а локалниот уред треба да ги има конфигурирани двата партнера ако сакате таа резервираност да значи нешто. BGP не е потребен само за подигање на овој тунел со приватна адреса, иако обично е дел од начинот на кој ги распоредувате префиксите.

Вториот мит: воспоставен тунел го шифрира вашиот сообраќај

Две патеки сега стигнуваат до апликациската мрежа: директната приватна peering патека и патеката низ VPN. Двете работат. Само една го применува овој IPsec слој. Microsoft документира дека кога идентични префикси се објавуваат преку ExpressRoute и преку VPN, Azure ја претпочита директната ExpressRoute патека, па здрав тунел со здрави бројачи не докажува ништо за тоа каде отишле апликациските пакети.

Документираните методи на насочување се покривен опсег на ExpressRoute со поконкретен заштитен опсег на VPN, или дисјунктни префикси на двете патеки. На пример, приватниот peering може да носи 10.40.0.0/16, додека VPN објавува 10.40.12.0/24. Поконкретниот префикс победува и остатокот од опсегот останува директен.

az network vnet-gateway list-advertised-routes -g rg-net -n vpngw-prod
az network vnet-gateway list-learned-routes -g rg-net -n vpngw-prod
az network vpn-connection show -g rg-net -n conn-onprem --query connectionStatus

Направете ја истата проверка во локалниот правец, бидејќи преференцијата на вашиот рутер одлучува од каде излегува излезниот сообраќај. И држете го сопствениот транспорт на тунелот на ExpressRoute патеката; рута што ја вовлекува приватната крајна точка на портата во тунелот го прави тунелот зависен од самиот себе.

Одлучете што се случува кога тунелот ќе падне

Поконкретна VPN рута исчезнува кога тунелот ќе падне, додека пошироката директна рута останува. Сообраќајот тогаш тече нешифриран и сè изгледа здраво, што е најлошиот режим на откажување за барање што постои за да гарантира шифрирање. Ако барањето го забранува тоа враќање, рутирањето и политиката за пристап мораат тоа експлицитно да го кажат наместо да се потпираат на достапноста на тунелот.

Запишете кои префикси смеат да останат директно достапни и кои мораат да запрат кога шифрираната патека отсуствува. Потоа тестирајте го дозволениот случај со вистински сообраќај и споредете ги бројачите на врската, бидејќи само табелата со рути нема да ви каже дали барањето за шифрирање сè уште важи.

Таа рамка ви овозможува и да оцените NVA според неговите вистински функции, како повеќе тунели, пропусна моќ или проверка од добавувач, наместо да купите еден затоа што крајната точка е приватна.