Azure peering пе, әлде VNet-тен VNet-ке VPN пе? Маршруттау алдында шешіңіз
Peering шлюзсіз Azure омыртқасымен жүреді; VNet-тен VNet-ке VPN өзіңізге тиесілі IPsec шекарасын қосады. Тасымал, транзиттілік және сенім бойынша таңдаңыз.
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 және үнсіз біреуін таңдайтын маршрут кестесі.