Екі VNet те 10.40.1.0/24 ауқымын пайдаланады, туннельдер көтеріледі, бірақ ештеңе жұмыс істемейді. Екінші VPN шлюзін қосу мұны өзгертпейді, төменірек маршрут метрикасы да өзгертпейді, себебі мәселе жол таңдауда емес. Бір жеке мекенжайға жауап беретін екі жұмыс жүктемесі әр пакетті екіұшты межелі орынмен және тексерілмейтін қайтару жолымен қалдырады. Кез келген аударманы жоспарламас бұрын нақты қандай қосылым түрін жасағаныңызды анықтаңыз, өйткені сол бір таңдау Azure-дың NAT мүмкіндігінің мүлдем қолжетімді екенін шешеді.

Бұл симптом сізге шын мәнінде не дейді

VNet A ішіндегі хост 10.40.1.10 мекенжайына жібергенде, маршруттау кестесі оны тек бір жерге бағыттай алады. Егер VNet B де 10.40.1.10 болса, бұл мекенжай жол ажырата алатын межелі орын емес; бұл екі иесі бар бір мекенжай.

Адамдар әдетте орнататын екінші шлюз көмектеспейді. Ол басқа туннель береді, басқа мекенжай емес, және қайталанатын ауқым туннель ішінде өзгеріссіз жүреді. Ол сондай-ақ біркелкі ұстауға тиіс конфигурацияны екі еселейді. Оның істей алмайтыны — бір мекенжай екі хостты білдіруі.

VPN серіктестерінің ашық мекенжайларын өзгерту де ештеңе бермейді. Ол мекенжайлар туннельдің шеткі нүктелерін анықтайды, ал қақтығыс оның ішінде тасымалданатын жеке ауқымда.

NAT қолжетімді ме, жоқ па — қосылым түрі шешеді

Azure VPN Gateway-де шынымен NAT мүмкіндігі бар және ол белгілі бір шлюз SKU-ларында маршрутқа негізделген IPsec сайтаралық қосылымдар үшін құжатталған. Сол құжаттама VNet-to-VNet және point-to-site қосылымдарын жоққа шығарады, сондықтан бұл мүмкіндік әр шлюз қатынасында пайда болатын белгі құсбелгісі емес.

Connection typeNAT supportOverlap workaround
Site-to-Site (route-based IPsec, documented SKUs)Supported with configured NAT rulesTranslate the range in the rules
VNet-to-VNet (Vnet2Vnet)Not supportedRenumber, or redesign as a site-to-site connection
Point-to-siteNot supportedChoose client address pools that do not collide

Байырғы VNet-to-VNet сонымен қатар VNet және жергілікті желі ауқымдарының басынан қайталанбауын талап етеді, бұл алып тастауға сәйкес келеді. VNet теңдестіруі де сол себепті қайталанудың шешімі емес.

Адамдар байырғы түрмен шатастыратын қолдау көрсетілетін балама бар: екінші VNet-ті жергілікті желі ретінде үлгілеп, оны сайт-аралық қосылым ретінде қосыңыз. Бұл басқа ресурс және басқа дизайн, сондықтан аты өзгертілген қосылымды жай ғана атауын өзгерту емес, тексерілуі тиіс өзгеріс ретінде қарастырыңыз.

Қайта нөмірлеңіз немесе бүркеншікті иеленетін нәрсемен аударыңыз

Екі VNet те сіздікі болса, жоспарланған қайта нөмірлеуді аударманың тұрақты құнымен салыстырыңыз. Қайта нөмірлеу қолданба конфигурациясына, DNS жазбаларына, қауіпсіздік ережелеріне және әрбір бар қосылымға тиеді, бірақ кейін қалыпты оқылатын желі қалдырады. Оны бір уақытта бір ішкі желімен жасаңыз, DNS өзгерісі ең соңында болсын. Жартылай қайта нөмірленген ауқым екі нұсқадан да жаман, өйткені сонда екі префикс те кестені келесі оқыған адамға беделді көрінеді.

Қайта нөмірлеу практикалық болмаған жерде бүркеншіктің нақты иесі бар аударылған дизайнды пайдаланыңыз. VNet A ішіндегі шақырушылар VNet B-нің 10.40.1.10 мекенжайына 10.140.1.10 ретінде жете алады, бірақ бұл бүркеншікке аударатын құрылғы, оған баратын маршрут және жауап үшін сәйкес мінез-құлық қажет. Тек DNS-ке қосылған мекенжай аударма емес.

Екі ауқымды да екі бағытта жазып алыңыз: шақырушы нені тереді, межелі орын көз ретінде нені көреді және қай жақ бастай алады. Azure-дың өз NAT ережелері өздерінің SNAT салыстырулары үшін кері аударманы қамтиды, сондықтан сіз сәйкес DNAT ережесін қолмен жазбайсыз, бірақ бұл ыңғайлылық мүмкіндік қолдайтын қосылым түрлерінде аяқталады.

Не істемейді

Пайдаланушы анықтаған маршрут немесе маршрут метрикасы жетіспейтін мекенжай айырмашылығын жасай алмайды. Екеуі де әлі де екіұшты межелі орынға әсер етеді, ал пакет кесте ұнататын келесі секіріске жетеді.

Қайталанатын ауқымды маршруттар кестесіне неғұрлым нақты префикс ретінде қосу екіұштылықты тек бір қадам жылжытады. Ол сондай-ақ қарсы бағытты бұзуға бейім, онда жауаптың енді екі ықтимал көзі бар.

Дизайнды екі бағыттағы трафикпен қабылдаңыз

Дизайнды туннель күйімен емес, әр жақтан жаңа рұқсат етілген операциямен дәлелдеңіз. Қосылған IPsec туннелі серіктестердің криптография туралы келіскенін айтады; ол межелі орындардың ажыратылатын болғаны туралы ештеңе айтпайды.

Содан кейін тыйым салынған жолдарды іске қосыңыз: қолжетімсіз болып қалуы тиіс мекенжай және саясат бөгеуі тиіс қызмет. Егер екеуі де әлі сәтті болса, аударма дизайн көздегеннен кеңірек.

Орнатуды кейін түсіндіретін фактілермен аяқтаңыз: бастапқы ауқым, ұсынылған ауқым, аударатын құрылғы және әр жақ бастай алатын бағыт. Егер солардың бірі жетіспесе, келесі инженер екі хост бір атты бөлісетін және ешкім олардың біреуі неге жауап беретінін есіне түсірмейтін желіні мұра етеді.

Қатысты мақалалар