Зваротны трафік Azure P2S VPN працуе толькі ў адзін бок

Значок тунэля зялёны, NSG выглядае дазваляючым, эфектыўныя маршруты выглядаюць слушнымі, але ВМ па-ранейшаму не можа адкрыць зваротнае злучэнне да падключанага кліента. Звычайнае дапушчэнне: працоўны тунэль point-to-site сіметрычны — калі кліент дасягае ВМ, то і ВМ дасягае кліента. Гэтае дапушчэнне — памылка ў разважанні, а не ў канфігурацыі. Тунэль можа несці адзін напрамак незапатрабаванага патоку і скідваць іншы, і выпраўленне залежыць ад таго, які ўзровень яго скідвае.

Міф: падключаны тунэль — гэта двухбаковы тунэль

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

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

Праверце напрамак раней, чым правяраць дасягальнасць

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

Наступны крок — доказы, а не новыя правілы. Праверце NSG на падсетцы ВМ у абодвух напрамках, прачытайце эфектыўныя маршруты на NIC ВМ і злавіце пакеты на ВМ, пакуль кліент адпраўляе трафік. Запыт, які прыходзіць без адказу, — гэта праблема фільтра або зваротнага маршруту; запыт, які не прыходзіць зусім, — праблема шляху. Не лічыце няўдалы ping доказам таго, што ВМ недасягальная, бо палітыка ICMP можа скідваць адказ, пакуль TCP працуе.

Зваротны шлях IKEv2 point-to-site — звычайны падазроны

У справаздачы Azure, на якой заснаваны гэты артыкул, кліент дасягаў ВМ праз IKEv2, але ўваходны ICMP ад ВМ да кліента не працаваў, пакуль тып тунэля шлюза не быў пераключаны на OpenVPN. Аўтар справаздачы сцвярджае, што Microsoft пацвердзіла абмежаванне ў шляху IKEv2 point-to-site: зваротны трафік ад ВМ да кліента не маршрутызуецца сіметрычна, калі сеанс не пачаў кліент. IKEv2 спадзяецца на селектары трафіку, і шлюз у тым выпадку не ўлічыў зваротны напрамак.

Гэта не робіць OpenVPN лепшым тыпам тунэля наогул. Гэта робіць тып тунэля зменнай у матрыцы тэстаў для гэтай працоўнай нагрузкі.

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

Міф: выяўленне праз broadcast перасякае мяжу VNet

Другое дапушчэнне не спраўджваецца па несучойнай прычыне. Віртуальная сетка Azure не перадае broadcast-трафік, таму ВМ не можа атрымліваць broadcast-кадры з лакальнай сеткі праз злучэнне site-to-site або point-to-site. Праграмы, якія знаходзяць партнёраў праз broadcast, напрыклад стары агляд файлаў або некаторыя пратаколы выяўлення прылад, ніколі не ўбачаць аддалены бок, як бы ні былі напісаны маршруты.

Замяніце выяўленне праз broadcast на імёны DNS, службу каталога або яўны спіс партнёраў. Калі ў праграмы няма unicast-альтэрнатывы, дызайну патрэбен іншы механізм выяўлення, а не шырэйшы тунэль.

Што змяніць і як гэта даказаць

Калі тэст напрамку не праходзіць толькі на IKEv2, запішыце тып тунэля шлюза, пул адрасоў кліентаў і дакладны тэст ICMP або TCP, затым ацаніце зацверджаны профіль OpenVPN для закранутых кліентаў. Калі ён не праходзіць на любым тыпе тунэля, працуйце са зваротным шляхам: адрас кліента павінен быць маршрутызуемым з падсеткі ВМ, любы маршрут, вызначаны карыстальнікам, павінен паказваць на сапраўдны наступны хоп, а брандмаўэр кліента павінен прымаць уваходны паток. Далучыце доказы NSG і маршрутаў да заяўкі.

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