NVA жок ExpressRoute аркылуу Azure жеке IP VPN

Уламыш — ExpressRoute жеке peering аркылуу трафикти шифрлөө үчүн виртуалдык тармактык түзмөк керек деген. Керек эмес. Azure Site-to-Site VPN Gatewayди колдойт, анын туннелдин акыркы чекити схема аркылуу ташылуучу жеке RFC1918 дареги, ал эми түзмөк структуралык эмес, кошумча. Түзмөк уламышы жашырган нерсе — чындап ооруган бөлүк: жеке акыркы чекитти эки объектинин ордуна бирине күйгүзүү жана түз peering маршрутунун шифрленген жолдон үнсүз жеңишине жол берүү.

Уламыш кайдан келди

Бул ырастоонун урматтуу булагы бар. Көп жылдар бою жеке peering үстүндөгү IPsec үчүн практикалык рецепт NVA болгон, анткени башкарылуучу шлюз гана коомдук акыркы чекиттерди ачкан. Бул өзгөрдү, жана өзгөрүүгө чейин жазылган жооптор дагы эле күнүн эч ким текшербеген темаларда келтирилет. Түзөтүү тар: жеке даректүү VPN шлюзу бар, жана ал акыркы чекитти өзгөртөт, анын айланасындагы маршруттоо логикасын эмес.

Мунун эч бири NVAны пенсияга чыгарбайт. Ал түзмөк талапка жетүүнүн жалгыз жолу деген божомолду пенсияга чыгарат.

Жеке акыркы чекитти эки деңгээлде күйгүзүңүз

VPN шлюзу жайгашкан VNetке байланган иштеп турган ExpressRoute жеке peering байланышынан баштаңыз. Жергиликтүү тарап ошол схема аркылуу тиешелүү жеке даректерге мурун эле жетүүсү керек, анткени туннель ошол даректерди ташуу катары колдонот. Андан кийин шлюздун алдын ала шарты: жеке IP VPN үчүн Microsoft жол-жобосу 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ны акыркы чекит жеке болгондуктан сатып алуунун ордуна, анын чыныгы функциялары боюнча баалоого мүмкүндүк берет, мисалы, бир нече туннель, өткөрүү жөндөмдүүлүгү же жеткирүүчү инспекциясы.