Azure P2S VPN кайтаруу трафиги бир гана багытта иштейт

Туннелдин белгиси жашыл, NSG уруксат берип жаткандай, натыйжалуу маршруттар туура көрүнөт, бирок VM туташкан кардарга карай байланыш ача албайт. Адаттагы божомол — иштеп жаткан point-to-site туннели симметриялуу: кардар VMге жетсе, VM да кардарга жетет. Ушул божомол конфигурациядагы эмес, ой жүгүртүүдөгү ката. Туннель суралбаган агымдын бир багытын ташып, экинчисин таштай алат, ал эми оңдоо аны кайсы катмар таштап жатканына көз каранды.

Уламыш: туташкан туннель эки тараптуу туннель

VPN туннели — зым эмес, саясат жолу. Ар бир багыт селекторлор, маршруттар жана чыпкалар менен салыштырылат, жана алардын кайсынысы болбосун бир багытка уруксат берип, экинчисин тосо алат.

Иш жүзүндө асимметрия ушунчалык көп кездешет, ошондуктан багыт акыркы эмес, биринчи тестке кириши керек. Кардар баштайт, шлюз агымды көзөмөлдөйт, ал эми жооп түзүлгөн абалга ээрчийт. Жаңы агымды баштаган VMде мындай абал жок, ошондуктан ал кайтаруу жолу ачык маршрутталуучу жана уруксат берилген болушуна көз каранды. Ал жол болбосо, байланыш аракети аны эч бир колдонмо көрө электе эле өлөт.

Жеткиликтүүлүктү текшерүүдөн мурун багытты текшериңиз

Бир кардар дарегин, бир VM дарегин жана бир протоколду тандаңыз. Кардардан туташып, жыйынтыкты жазыңыз; анан ошол эле тестти VMден баштап, аны да жазыңыз. Биринчиси ийгиликтүү, экинчиси ийгиликсиз болсо, кардарлар пулу, шлюз ассоциациясы жана кардардан VNetке чейинки жол иштейт.

Кийинки кадам — далил, көбүрөөк эреже эмес. VMдин субнетиндеги NSGни эки багытта текшериңиз, VMдин NICиндеги натыйжалуу маршруттарды окуңуз жана кардар трафик жиберип жатканда VMде пакеттерди кармаңыз. Жоопсуз келген сурам — чыпка же кайтаруу маршрутунун маселеси; эч качан келбеген сурам — жол маселеси. Ийгиликсиз pingди VM жеткиликсиз деген далил деп эсептебеңиз, анткени ICMP саясаты TCP иштеп жатканда жоопту таштай алат.

IKEv2 point-to-site кайтаруу жолу — адаттагы шектүү

Ушул макаланын негизиндеги Azure отчётунда кардар IKEv2 аркылуу VMдерге жеткен, бирок VMден кардарга кирүүчү ICMP шлюздун туннель түрү OpenVPNге алмаштырылганга чейин ийгиликсиз болгон. Отчёттун автору Microsoft IKEv2 point-to-site жолунда чектөөнү ырастаганын айтат: VMден кардарга кайтаруу трафиги, эгер сессияны кардар баштабаса, симметриялуу маршрутталбайт. IKEv2 трафик селекторлоруна таянат, ал эми шлюз ошол учурда кайтаруу багытын сактаган жок.

Бул OpenVPNди жалпысынан жакшыраак туннель түрү кылбайт. Бул ушул жумуш жүктөмү үчүн тест матрицасында туннель түрүн өзгөрмө кылат.

Туннель түрүн алмаштыруу — кызматтын өзгөрүшү, которгуч эмес. Ар бир кардарга шайкеш профиль керек, ал эми шлюзге башка сертификат же аутентификация жөндөөсү керек болушу мүмкүн. Бир тесттик кардар жана бир тесттик VM менен бир багыттуу жүрүм-турумду кайталаңыз, түрдү бекитилген график боюнча өзгөртүңүз, анан ошол эле багыт тесттерин кайталаңыз. Эгер жүрүм-турум алмаштыруудан кийин да сакталса, туннель түрү себеп болгон эмес жана өндүрүшкө тийбестен маселени тарыттыңыз.

Уламыш: broadcast аркылуу табуу VNet чегинен өтөт

Экинчи божомол байланышсыз себептен улам ийгиликсиз. Azure виртуалдык тармагы broadcast трафигин ташыбайт, ошондуктан VM site-to-site же point-to-site байланышы аркылуу жергиликтүү тармактан broadcast кадрларын ала албайт. Broadcast аркылуу өнөктөштөрүн тапкан колдонмолор, мисалы эски файл көрүү же кээ бир түзмөктү табуу протоколдору, маршруттар кандай жазылбасын, алыскы тарапты эч качан көрбөйт.

Broadcast аркылуу табууну DNS аттары, каталог кызматы же ачык өнөктөштөр тизмеси менен алмаштырыңыз. Эгер колдонмодо unicast альтернативасы жок болсо, долбоорго кененирээк туннель эмес, башка табуу механизми керек.

Эмнени өзгөртүү керек жана аны кантип далилдөө керек

Эгер багыт тести IKEv2де гана ийгиликсиз болсо, шлюздун туннель түрүн, кардар даректеринин пулун жана так ICMP же TCP тестин жазыңыз, анан жабыркаган кардарлар үчүн бекитилген OpenVPN профилин баалаңыз. Эгер ал бардык туннель түрлөрүндө ийгиликсиз болсо, кайтаруу жолу боюнча иштеңиз: кардар дареги VMдин субнетинен маршрутталуучу болушу керек, колдонуучу аныктаган ар кандай маршрут жарактуу кийинки секирикке көрсөтүшү керек, ал эми кардардын firewallы кирүүчү агымды кабыл алышы керек. NSG жана маршрут далилдерин билетке тиркеңиз.

Колдонмо менен текшериңиз, ping менен эмес. Өзгөртүүдөн кийинки ийгиликтүү ICMP алмашуу кызмат порту, анын аутентификациясы же ат чечилиши жөнүндө эч нерсе айтпайт. Кайра туташкандан кийин тестти кайталаңыз, анткени пулдан башка дарек алган кардар жыйынтыкты өзгөртүшү мүмкүн. Анан кардар уктап ойгонгондон кийин дагы бир жолу кайталаңыз, анткени улантылган сессияда бир багыттуу жүрүм-турум көп кайра пайда болот.