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 дареги журналды окуп жаткан түзмөккө туура келерин ырастаңыз, анткени бир жазылуудагы эки шлюзду кайра курууда чаташтыруу оңой. Бул ката бир күнгө турат жана эч бир журналда из калтырбайт.