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 алмасу қызмет порты, оның аутентификациясы немесе атау шешімі туралы ештеңе айтпайды. Қайта қосылғаннан кейін тесті қайталаңыз, өйткені пулдан басқа мекенжай алған клиент нәтижені өзгерте алады. Содан кейін клиент ұйықтап оянғаннан кейін тағы бір рет қайталаңыз, өйткені жалғасқан сессияда бір бағытты мінез-құлық жиі қайта пайда болады.