Azure P2S: пасля змены VNet у аднаго кліента Windows зніклі маршруты

Два ноўтбукі праходзяць аўтэнтыфікацыю на адным і тым жа шлюзе Azure point-to-site, і толькі адзін дасягае нядаўна далучанай VNet. Абодва паказваюць Connected, значыць, аўтэнтыфікацыя не адрозненне; адрозненне — маршруты прызначэння, якія яны трымаюць. Пачніце з кліента, які не працуе, параўнайце адно прызначэнне і толькі потым вырашайце, ці прабел належыць пакету шлюза, ці лакальнай табліцы маршрутаў.

Пачніце з кліента, які не працуе, а не са шлюза

Пацвердзіце тапалогію, перш чым вінаваціць ноўтбук. Праверце, якія VNet далучаны да VNet шлюза і ці новая сетка знаходзіцца ў непасрэдным peer-злучэнні, ці дасягаецца праз асобны тунэль site-to-site. Калі новая VNet зусім не далучана да VNet шлюза, ніводзін кліенцкі пакет не зможа маршрутызаваць да яе, і працаздольны ноўтбук — гэта анамалія, якую трэба патлумачыць. Запішыце адказ, бо ён вызначае, ці адладжваеце вы кліента, ці шлюз.

Калі тапалогія ў парадку, пастаўце два ноўтбукі побач. Адзін шлюз, адзін пул адрасоў, адзін пратакол і адна зборка кліента — гэта менавіта тое параўнанне, якое вам патрэбна; усё іншае — другая зменная, якую давядзецца выключыць пазней.

Параўнайце адно прызначэнне праз route print

Выберыце дазволены IP рэсурсу і параўнайце абодва ноўтбукі двойчы: у адключаным стане, затым у падключаным. У Windows route print -4 пералічвае маршруты IPv4 з прэфіксам прызначэння, інтэрфейсам, наступным хапам і метрыкай. Запішыце радок, які рэальна пераможа для гэтага прызначэння, а не лічыце запісы, што змяшчаюць слова VPN.

Выбар ідзе ад найдаўжэйшага прэфікса, затым па метрыцы, таму больш канкрэтны лакальны маршрут можа перамагчы тунэльны, не выглядаючы памылковым. Калі патрэбнае прызначэнне ўнутры 10.24.0.0/16, здаровы кліент паказвае адпаведны маршрут на інтэрфейсе VPN, а кліент, які не працуе, адпраўляе той жа адрас на свой шлюз па змаўчанні.

Канфліктны лакальны прэфікс можа даць той жа сімптом. Перш чым нешта дадаваць, вызначце, які з двух выпадкаў у вас: тунэльнага маршруту няма зусім, або тунэльны маршрут прайграе больш канкрэтнаму.

TTL expired — гэта не памылка размеркавання маршрутаў

Ping, які вяртае TTL expired in transit, кажа, што пакет вычарпаў ліміт хапаў, а гэта звычайна азначае пятлю перасылкі, а не зламаны драйвер VPN. Ping у Windows прымае TTL да 255, і павелічэнне значэння не рамантуе пятлю; яно толькі адтэрміноўвае тую ж памылку. Успрымайце паведамленне як сімптом шляху, а не як доказ пра размеркаванне маршрутаў.

Выкарыстайце tracert -4 10.24.1.10, каб убачыць, дзе шлях паўтараецца. Калі тыя ж два хапы з'яўляюцца зноў і зноў, шукайце маршрут, які вяртае трафік, накіраваны ў тунэль, назад у тунэль або ў лакальны маршрутызатар, што перасылае яго назад.

Перастварыце пакет на шлюзе, які ім валодае

Microsoft дакументуе, што пакеты кліента Windows трэба спампаваць і ўсталяваць нанова пасля значных змен тапалогіі. Вазьміце актуальны пакет з шлюза Azure, які абслугоўвае гэты профіль, затым прымяніце яго падтрыманым працэсам для гэтага кліента. Замена выканальнага файла старонняй праграмы VPN — не тая ж аперацыя, што перастварэнне налад, спецыфічных для шлюза. Спампаваць пакет нанова танна; здагадкі пра лакальныя маршруты — не.

Перападключыцеся і зноў прачытайце маршрут для першапачатковага прызначэння. Захавайце радкі да і пасля разам з запісам пра змену, каб вынік быў дакладнейшы за пераўсталяваў кліента.

Сцэнарыі маршрутызацыі Azure P2S аддзяляюць VNet у непасрэдным peer-злучэнні ад сетак, дасяжных праз іншыя тунэлі, і новы пакет не можа зрабіць peer-злучэнне транзітыўным. Некаторыя сцэнарыі Windows site-to-site або BGP таксама патрабуюць уручную наладжаных аддаленых маршрутаў, таму абнаўленне пакета не з'яўляецца ўніверсальным механізмам размеркавання маршрутаў.

Пакідайце часовы маршрут часовым

Ручны маршрут можа ізаляваць адсутны кліенцкі маршрут, але будуйце яго ад рэальнага дызайну: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, без сцяга захавання, каб ён знікаў пры перазагрузцы. Выберыце індэкс інтэрфейса і наступны хап з падключанага адаптара VPN, а не з здагадкі.

Не пакідайце эксперыментальны маршрут на месцы як пастаяннага канкурэнтнага ўладальніка. Будучыя абнаўленні профілю могуць дадаць той жа прэфікс з іншай метрыкай, і тады ручны запіс моўчкі вырашае, які шлях пераможа. Запішыце крок выдалення ў змене.

Калі правільны маршрут актыўны, тэстуйце мэтавую праграму, а не ping. Калі пакеты дасягаюць Azure, але сэрвіс усё яшчэ не працуе, праверце групу сеткавай бяспекі і зваротны шлях, бо яны не залежаць ад таго, ці вывучыў ноўтбук прэфікс.