Azure S2S VPN қосылған, бірақ трафик жоқ: IKE журналын оқыңыз

Портал Connected деп көрсетеді, туннельдің жұмыс уақытының есептегіші бар, ал виртуалды машинаңыздан алынған trace екінші hop-та үзіледі. Қосылым күйі IKE және IPsec келіссөзін сипаттайды, қандай да бір жақта бір пакеттің саясат қабатынан өтетінін емес. Осы билеттердің көбін екі ақау түсіндіреді және олардың ешқайсысы Azure маршрутын өзгертумен түзетілмейді. Екеуі де шлюз жасаған журналда жазылған, сондықтан мен маршруттар кестесінен емес, сол жерден бастаймын.

Connected шын мәнінде нені растайды

Қосылған site-to-site қосылымы 1-ші және 2-ші фазалардың аяқталғанын және қауіпсіздік ассоциацияларының жұмыс істеп тұрғанын білдіреді. Бұл келіссөз туралы мәлімдеме: екі тарап та ұсыныс бойынша келісті, кілттерді алмастырды және SA жұбын орнатты. Ол трафик селекторларының қорғалған деп есептейтін ішкі желілерге сәйкес келетіні туралы ештеңе айтпайды, сондай-ақ шифрды шешкеннен кейін алыс жақ пакетті бір жерге бағыттайтыны туралы да ештеңе айтпайды. Туннель апталар бойы тұрып, әрбір маңызды ағынды тастай алады, және дәл осы үлгі адамдарды сау шлюзді қайта салуға мәжбүр етеді.

Бірінші кезекте тексеруге тұрарлық екі ақау: ESP орнына AH ұсынатын peer және шлюз ішкі деп қабылдамайтын кеңістікте нөмірленген виртуалды желі.

Маршруттарға тиюдің алдында экспортталған журналды ашыңыз

Порталда виртуалды желі шлюзін ашып, қосылымға VPN troubleshoot операциясын іске қосыңыз, содан кейін ол жасайтын буманы жүктеп алып, распаковкалаңыз. Ішінде 1-ші және 2-ші фазалардың алмасуы бар IKE журналы, уақыт белгілерімен және қарапайым мәтін ретінде оқуға болады. Онда transform жолын іздеңіз, жоғарыдан төмен оқымаңыз, өйткені қызықты жазба әдетте бірнеше жүз жолдан кейін болады. Егер порталға рұқсатыңыз болмаса, диагностика параметрлері қосылған кезде дәл сол диагностика шлюздің журнал межелі жерінде пайда болады.

Екі жазба құнның басым бөлігін алып жүреді. Біріншісі шамамен былай оқылады: expected ESP with combined authentication and cipher, received AH. Екіншісі IKE алмасуы кезіндегі invalid payload қатесі, бұл әдетте дұрыс құрылмаған немесе қолдау көрсетілмейтін ұсыныс өрісін білдіреді.

Екеуі де жергілікті құрылғының не ұсынғанын сипаттайды, сондықтан екеуі де peer жағындағы параметрлер. Қосылымның Azure жағын қайта жасау файрволыңыз жіберетін ұсынысты өзгертпейді, ал солай істеу осы жұмыста ең жиі ысырап болатын сағат. Peer-де 2-ші фазаны біріктірілген аутентификация мен шифрмен ESP-ге қойып, алгоритмді келіссөзге қалдырыңыз, содан кейін combined mode тәріздес атауы бар өндірушінің құсбелгісі астынан үнсіз AH ұсынысын таңдап жатқанын тексеріңіз.

Виртуалды желінің мекенжай кеңістігін растаңыз

Шлюз виртуалды желінің жеке диапазондарда болуын күтеді. Жалпы блокта нөмірленген желі, мысалы 111.x-тен басталатыны, туннельді көтеруі мүмкін, бірақ Azure бұл кеңістікті ішкі деп санаудан бас тартады, сондықтан қосылым сау көрінеді және бірде-бір ағын қабылданбайды. Селекторларға түстен кейінгі уақытты жұмсамас бұрын мекенжай кеңістігін растаңыз. Егер нөмірлеу ескі бөлуден қалған қатаң талап болса, түзету басқа шлюз емес, мекенжай жоспарын өзгерту.

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

Префикстерді екі бағытта да тексеріңіз

Жергілікті желі шлюзінің ресурсы жергілікті префикстерді ұстайды және олар алыс құрылғы шынымен қорғайтын ішкі желілерге сәйкес болуы керек. Құрылғы тастайтын мекенжайларды қамтитын қорытынды кейбір ағындарды өткізіп, басқаларында сәтсіз болады, бұл конфигурация сәйкессіздігі емес, үзік-үзік маршруттау ақауы ретінде оқылады. Алыс жағын да тексеріңіз: бір ұшы /16 тізімдесе, екіншісі оның ішінде үш /24 тізімдейді — бұл классикалық ішінара сәтсіздік. Ешбір тізім өздігінен беделді емес, сондықтан көретініңізге сенудің орнына екеуін қатар салыстырыңыз.

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

Ping емес, жолды сынаңыз

Жұмыс істеп тұрған туннельді жұмыс істеп тұрған маршруттан ажырататын trace былай көрінеді: бірінші hop жергілікті шлюз, содан кейін жауап бермейтін бірнеше hop, содан кейін алыс хост жауап береді. Егер trace хостқа ешқашан жетпесе, қолданба шынымен пайдаланатын TCP портын сынаңыз, өйткені ICMP жеткілікті жиі сүзіледі, сондықтан сәтсіз ping өте азды дәлелдейді. Сол trace-ті алыс хосттан Azure-дағы виртуалды машинаға қарай іске қосыңыз. Екі нәтиженің арасындағы асимметрия жоғалған қайтару маршрутын немесе тек бір бағытқа рұқсат беретін ережені табудың ең жылдам жолы.

Peer ұсынысын, екі мекенжай кеңістігін және қосылым жасалған уақытты билетке жазыңыз, келесі инженер қай мәндер қайта салынғанын және қайсысына ешқашан тиіспегенін білсін.

Егер журнал бос қайтса, шлюз қосылымыңызды мүлде аяқтамауы мүмкін. Жергілікті желі шлюзіндегі peer мекенжайының журналды оқып отырған құрылғыға сәйкес келетінін растаңыз, өйткені бір жазылымдағы екі шлюзді қайта салу кезінде шатастыру оңай. Бұл қате бір күнге тұрады және ешбір журналда із қалдырмайды.