Azure peering же VNet–VNet VPN? Маршруттоодон мурун чечиңиз

Azure сизге эки виртуалдык тармакты туташтыруунун жок дегенде эки жолун берет жана булар бир объектидеги алмаштырылуучу жөндөөлөр эмес. Peering VNet-терди Microsoft омурткасында шлюзсуз бириктирет; VNet–VNet VPN өзүңүз жайгаштырган, өлчөмүн аныктаган жана көзөмөлдөгөн эки шлюздун ортосунда IPsec мамилесин орнотот. Чечим үч шартка келет, эгер маршрут кошконго чейин үчөөнө тең жооп бере албасаңыз, сиз эч качан тандабаган модел үчүн айланма жол курууга аз калдыңыз.

Моделди аныктаган үч шарт

Биринчиси — талаптын бир бөлүгү өзүңүзгө таандык жана көрсөтө алган IPsec чекти талап кылабы. Экинчиси — дарек мейкиндиктери тазабы жана эки VNet бири-бири менен гана сүйлөшүшү керекпи. Үчүнчүсү — кандайдыр бир транзиттик жолдун жана шлюз эсебинин ээси ким. Ушул тартипте жооп бериңиз, анткени биринчиси экинчиси канчалык жагымдуу көрүнсө да peering-ди жокко чыгары мүмкүн.

Эки моделге тең жалпы нерсе — катуу даректөө эрежеси: VNet дарек мейкиндиктери кабатташпашы керек. Peering да, VNet–VNet VPN да эки бирдей диапазонду бир маанилүү кылуунун колдоого алынган жолу эмес, ал эми кабатташуу башка туташуу түрүн эмес, карталоо долбоорун же кайра долбоорлоону талап кылат.

1-шарт: өзүңүзгө таандык IPsec чек керекпи?

Peering трафикти Azure-дын жеке омурткасы аркылуу ташыйт жана peered туташуу үчүн VPN шлюзун талап кылбайт. Бул ташуу тууралуу билдирүү, ал эми аудиторго «биз IPsec иштетебиз» деп берүүчү шифрлөө билдирүүсү эмес. Эгер талап кардар конфигурациялаган туннелди, белгилүү IKE саясатын же сиз көзөмөлдөгөн жабдууда бүткөн чекти атаса, омуртка канчалык жеке болбосун, peering ага жооп бербейт.

VNet–VNet VPN ошол чекти берет: эки шлюз, IPsec/IKE мамилеси, жалпы ачкычтар жана ага коштолгон бүткүл операциялык бет. Сиз туннелдин абалын, шлюздун сыйымдуулугун, SKU чектөөлөрүн жана туннел иштеп жатканын далилдеген көзөмөлдү мураска аласыз. Талап так ошол чекке байланыштуу болгондо бул туура жооп, ал peering серебинде peering-ден өзгөчө туташуу түрү катары сүрөттөлгөн.

Карама-каршы багытта да ошончолук этият болуңуз. «Бизге VNet-тердин ортосунда шифрлөө керек» көбүнчө жумуш жүктөмүнүн өз TLS-и менен канааттандырылат, ошондо шлюз артында талап жок чыгым болот. Механизмди тандоодон мурун аудитор окуй турган сүйлөмдү жазыңыз.

2-шарт: топология түзбү же бир нерсе өтүшү керекпи?

Peering транзиттик эмес. Хабга peered эки VNet ушунун аркасында бири-бири менен туташкан эмес, ал эми бир багытта иштегендей көрүнгөн маршрут адатта бир тарапта гана Connected-го жеткен peering. Эки тарап тең болушу керек жана экөө тең Connected көрсөтүшү керек, трафик үнсүз жоголгондо эң оболу ушуну текшересиз.

Эгер талап хаб аркылуу жергиликтүү тармакка жетүү болсо, шлюз транзити белгилүү ролдору бар өзүнчө долбоор: хаб шлюзга ээлик кылат, spoke peering шлюз транзитине уруксат берет, ал эми 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 кийинки секиригин көрсөтүшү жана жолдо шлюздун жоктугу. VNet–VNet VPN үчүн бул эки туташуунун тең Connected болушу, эки шлюзде дал келген ачкычтар менен саясаттар жана кийинки секириги виртуалдык тармак шлюзу болгон маршрут.

Эгер текшерүүлөр сүйлөмгө каршы келсе, адегенде сүйлөмдү оңдоңуз. Бул долбоорлордогу башаламандыктын көбү эч ким сүрөттөбөгөн гибридден келет: жумуш жүктөмүнүн ички тармагы үчүн peering, бир эски кызмат үчүн VPN жана үнсүз бирин артык көргөн маршрут таблицасы.