Azure peering или VPN од VNet до VNet? Одлучете пред рутирање

Azure ви дава најмалку два начина да поврзете две виртуелни мрежи и тие не се заменливи поставки на истиот објект. Peering ги поврзува VNet мрежите на рбетот на Microsoft без порта; VPN од VNet до VNet поставува IPsec врска меѓу две порти што вие ги распоредувате, димензионирате и надгледувате. Одлуката се сведува на три услови, и ако не можете да одговорите на сите три пред да додадете рута, вие сте на пат да изградите заобиколно решение за модел што никогаш не сте го избрале.

Три услови што го одредуваат моделот

Првиот е дали нешто во барањето бара IPsec граница што ја поседувате и на која можете да покажете. Вториот е дали адресните простори се чисти и дали двете VNet мрежи треба само да разговараат една со друга. Третиот е кому му припаѓаат секоја транзитна патека и сметката за портата. Одговорете по тој редослед, зашто првиот може да го исклучи peering, колку и да изгледа привлечен вториот.

Она што е заедничко за двата модели е строго адресирачко правило: адресните простори на VNet не смеат да се преклопуваат. Ниту peering ниту VPN од VNet до VNet не е поддржан начин да се направат два идентични опсези недвосмислени, а преклопувањето бара дизајн за мапирање или препроектирање, а не друг тип на врска.

Услов 1: ви треба IPsec граница што ја поседувате?

Peering пренесува сообраќај по приватниот рбет на Azure и не бара VPN порта за самата peered врска. Тоа е изјава за транспортот, а не изјава за шифрирање што можете да му ја дадете на ревизор како «ние користиме IPsec». Ако барањето именува тунел што го конфигурира клиентот, одредена IKE политика или граница што завршува на опрема што ја контролирате, peering не го задоволува тоа, колку и да е приватен рбетот.

VPN од VNet до VNet ја обезбедува таа граница: две порти, IPsec/IKE врска, споделени клучеви и целата оперативна површина што доаѓа со тоа. Вие наследувате состојба на тунелот, капацитет на портата, SKU ограничувања и надгледувањето што докажува дека тунелот е активен. Тоа е точниот одговор кога барањето е конкретно за таа граница, опишана во прегледот на peering како различен тип на врска.

Бидете исто толку внимателни во спротивната насока. «Ни треба шифрирање меѓу VNet мрежите» често се задоволува со сопствениот TLS на работното оптоварување, и тогаш портата е трошок без барање зад неа. Напишете ја реченицата што ќе ја прочита ревизорот пред да го изберете механизмот.

Услов 2: топологијата е директна или нешто мора да транзитира?

Peering не е транзитивен. Две VNet мрежи peered на центар не се со тоа поврзани една со друга, а рута што изгледа дека работи во една насока обично е peering што достигнал Connected само на едната страна. Двете страни мора да постојат и двете мора да покажуваат Connected, и тоа е првото што го проверувате кога сообраќајот тивко исчезнува.

Ако барањето е достапност на локалната мрежа преку центар, транзитот на портата е посебен дизајн со конкретни улоги: центарот ја поседува портата, peering на spoke мрежата дозволува транзит на портата, а spoke мора да дозволи пренесен сообраќај. Тоа се својства на peering, а не автоматски последици од поврзувањето на VNet мрежите:

az network vnet peering create -g hub-rg -n hub-to-spoke1   --vnet-name hub-vnet --remote-vnet /subscriptions/SUB/resourceGroups/spoke-rg/providers/Microsoft.Network/virtualNetworks/spoke1-vnet   --allow-vnet-access --allow-gateway-transit --allow-forwarded-traffic

az network vnet peering list -g hub-rg --vnet-name hub-vnet -o table
az network nic show-effective-route-table -g spoke-rg -n app-nic -o table

Ефективната табела на рути е чесниот одговор на «дали патеката постои?». Таа го покажува типот на следниот скок што платформата навистина ќе го користи, па peering што изгледа конфигуриран но не е поврзан се појавува како рута што недостасува или е погрешна, а не како загатка.

Услов 3: кому му припаѓаат транзитната патека и сметката?

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

Трошокот го следи истиот облик но не истите ставки: peering надоместоците се врска и пренос на податоци, додека VPN додава часови на портата и сопствени надоместоци за пренос. Споредете го вкупниот износ за топологијата што навистина ќе ја возите една година, вклучително вториот тунел и надгледувањето, а не цената на една врска денес. Вклучете ја работата што никој не ја фактурира: некој мора да ротира клучеви, да ја следи состојбата на тунелот и да одговори на предупредувањето во три часот наутро кога портата се рестартира. Обично токму оваа ставка ја решава расправата, зашто е единствената што никогаш не се појавува во понуда.

Што и да изберете, тестирајте три текови: предвидениот, одбиениот што мора да остане одбиен и случајот на обновување кога портата на центарот или peering е исклучена. Модел што го објаснува само среќниот пат не е потврден, туку е демонстриран.

Проверете го изборот против неговото сопствено тврдење

Напишете една реченица што ги именува моделот, границата и сопственикот, потоа проверете дали распоредената состојба се совпаѓа со неа. За peering тоа значи двете состојби на peering Connected, ефективната рута го покажува следниот скок на peering за целната претставка и нема порта на патеката. За VPN од VNet до VNet тоа значи двете врски Connected, соодветни клучеви и политики на двете порти и рута чиј следен скок е портата на виртуелната мрежа.

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