Ping працуе ў адзін бок: чаму Windows скідае адказ сервера

Ваш кліент пінгуе сервер, сервер не можа пінгаваць кліент, і тунель відавочна пераносіць пакеты ў абодвух гэтых сцвярджэннях. Адрозніваецца не шлях, а першы пакет кожнага тэсту: адзін — гэта адказ на паток, які Windows ужо адсочвае, другі — новы ўваходны запыт, якога не дапусціла ніводнае правіла. Гэтае адрозненне тлумачыць большасць справаздач пра аднабаковы ping і паказвае прама на правіла, якое трэба напісаць. Два тэсты ў процілеглых кірунках раздзяляюць выпадкі прыкладна за хвіліну.

Два кірункі, два розныя рашэнні

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

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

Такім чынам, поспех кліента даказаў, што зыходны ICMP і зваротны шлях працуюць. Ён ніколі не правяраў уваходнае рашэнне, і натуральная выснова, што міжсеткавы экран у парадку, разумная і памылковая. Вось чаму памылка паўтараецца ў заяўках, якія ўжо ўтрымліваюць доказ.

Ідзіце за пакетам, пакуль ён не знікне

Пацвердзіце адрасы, перш чым нешта змяняць: выкарыстоўвайце адрас тунеля, які кліент фактычна мае, і праверце, што сервер маршрутызуе менавіта да яго, а не да адраса LAN за кліентам. Абедзве няўдачы выглядаюць аднолькава з запыту сервера, бо абедзве сканчаюцца тайм-аўтам. Дзе пакет гіне — гэта адзіны факт, які вырашае, што змяняць.

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

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

Абмяжуйце адно правіла замест таго, каб адкрываць ICMP

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

Get-NetConnectionProfile
Get-NetAdapter | Where-Object Status -eq 'Up'
New-NetFirewallRule -DisplayName "VPN server echo" -Direction Inbound -Protocol ICMPv4 -IcmpType 8 -RemoteAddress 10.63.0.1 -InterfaceAlias "Office VPN" -Profile Private -Action Allow -WhatIf

ICMPv4 тып 8 — гэта запыт рэха, адзінае паведамленне, на якое серверу трэба адказаць. Абмяжуйце яго адрасам тунеля сервера і інтэрфейсам тунеля, і пакіньце профіль такім, якім адаптар сапраўды з'яўляецца. Перайменаванне сеткі, каб яна адпавядала прыкладу, — асобная змена з уласнымі наступствамі.

Чаго правіла не пакрывае

Рэха IPv6 — гэта іншы пратакол з іншым тыпам паведамлення, таму правіла ICMPv4 нічога пра яго не кажа, і тунелю, які пераносіць абедзве сям'і, патрэбна сваё правіла для другой. Гэтае правіла таксама не адкрывае нічога іншага: RDP, агульны доступ да файлаў і кожная іншая служба па-ранейшаму залежаць ад уласнай палітыкі. У гэтым і сэнс абмежавання аднаго вузкага правіла замест уключэння шырокага дазволу ICMP. Шырокі дазвол — гэта лёгкае рашэнне і тое, што жыве найдаўжэй, бо пасля яго ніхто не заўважае.

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

Чытайце вынік у правільным кірунку

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

Get-NetFirewallRule -DisplayName "VPN server echo" | Get-NetFirewallAddressFilter
ping 10.63.4.17
ping -6 fd00:63::17

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