Azure: прыватны IP VPN праз ExpressRoute без NVA

Міф у тым, што шыфраванне трафіку праз прыватны peering ExpressRoute патрабуе віртуальнага сеткавага прыстасавання. Гэта не так. Azure падтрымлівае Site-to-Site VPN Gateway, канцавы пункт тунеля якога — прыватны адрас RFC1918, які перадаецца праз канал, а прыстасаванне з'яўляецца апцыянальным, а не структурным. Што міф пра прыстасаванне хавае, дык гэта частку, якая сапраўды балючая: уключэнне прыватнага канцавога пункта на адным аб'екце замест двух і тое, што прамы маршрут peering ціха перамагае зашыфраваны шлях.

Адкуль узяўся міф

Сцвярджэнне мае паважную гісторыю. На працягу гадоў практычным рэцэптам для IPsec праз прыватны peering было NVA, бо кіраваны шлюз прапаноўваў толькі публічныя канцавыя пункты. Гэта змянілася, а адказы, напісаныя да змены, дагэтуль цытуюцца ў абмеркаваннях, дзе ніхто не правярае дату. Папраўка вузкая: шлюз VPN з прыватным адрасам існуе, і ён змяняе канцавы пункт, а не логіку маршрутызацыі вакол яго.

Нішто з гэтага не адпраўляе NVA на пенсію. Яно адпраўляе на пенсію здагадку, што прыстасаванне — адзіны шлях да патрабавання.

Уключыце прыватны канцавы пункт на абодвух узроўнях

Пачніце з працоўнага злучэння прыватнага peering ExpressRoute, звязанага з VNet, у якой знаходзіцца шлюз VPN. Лакальны бок павінен ужо дасягаць адпаведных прыватных адрасоў праз гэты канал, бо тунель будзе выкарыстоўваць гэтыя адрасы як транспарт. Затым перадумова шлюза: працэдура Microsoft для VPN з прыватным IP патрабуе шлюз, пабудаваны на рэсурсе публічнага IP Standard. Прыватная адрасацыя тунеля не адмяняе гэтага патрабавання, што здзіўляе людзей, якія лічаць, што «прыватны» азначае «ніякага публічнага 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 па яго рэальных функцыях, такіх як некалькі тунеляў, прапускная здольнасць ці інспекцыя пастаўшчыка, замест таго каб купляць яго таму, што канцавы пункт прыватны.