Ping тек бір бағытта жұмыс істейді: Windows неге сервердің жаңғырығын тастайды

Клиенттің Ping-і сәтті, өйткені брандмауэр жауапты рұқсат етті, сұрауды емес. Жаңғырықты қарсы бағытта қадағалап, бір ережені туннельге шектеңіз.

Клиентіңіз серверге Ping жібереді, сервер клиентке Ping жібере алмайды, ал туннель осы екі тұжырымда да пакеттерді анық тасымалдап тұр. Айырмашылық жолда емес, әр сынақтың бірінші пакетінде: біреуі Windows әлдеқашан бақылап отырған ағынға берілген жауап, екіншісі ешбір ереже рұқсат етпеген жаңа кіріс сұрауы. Осы айырмашылық бір бағытты Ping туралы есептердің көбін түсіндіреді және жазуға тиіс ережеге тікелей нұсқайды. Қарсы бағыттағы екі сынақ жағдайларды шамамен бір минутта ажыратады.

Екі бағыт, екі түрлі шешім

Клиент жаңғырық сұрауын жібергенде, Windows брандмауэры рұқсат беруге шешім қабылдаған шығыс қосылысты көреді. Жауап сол орныққан ағынның ішінде қайтады, сондықтан күйді қадағалайтын механизм оны ICMP үшін ешбір кіріс ережесін сұрамай қабылдайды. Тәжірибеде күйге негізделген сүзудің мағынасы осы, ал ешкім жазбаған ереже мұнда қатыспайды. Сондықтан клиенттің сәттілігі кіріс саясаты туралы ештеңе айтпайды.

Сервер сұрауды бірінші жіберсе, оған ешбір күй сәйкес келмейді. Windows пакетті жаңа кіріс қосылыс ретінде қарастырады және кіріс саясатынан сұрайды, ол әдепкі бойынша ерікті көздерден келетін жаңғырық сұрауларын ескермейді.

Яғни клиенттің сәттілігі шығыс ICMP мен қайту жолының жұмыс істейтінін дәлелдеді. Ол кіріс шешімін ешқашан сынамады, ал брандмауэрдің жарамды екені туралы табиғи қорытынды ақылға қонымды әрі қате. Сондықтан бұл қате дәлел қамтылған тикеттерде қайталана береді.

Пакет жоғалғанша оны қадағалаңыз

Бірдеңені өзгертуден бұрын мекенжайларды растаңыз: клиентте шынымен бар туннель мекенжайын қолданыңыз және сервердің клиенттің артындағы LAN мекенжайына емес, дәл соған маршруттайтынын тексеріңіз. Екі сәтсіздік сервер пәрмен жолынан бірдей көрінеді, өйткені екеуі де уақыт бітуімен аяқталады. Пакет қайда өлетіні — нені өзгерту керегін шешетін жалғыз факт.

Егер сұрау туннель интерфейсіне жетіп, сыртқа ештеңе шықпаса, ықтимал себеп — жергілікті брандмауэр. Егер ол интерфейске ешқашан жетпесе, жауап жоғарыда: сервердегі маршрут, шығыс саясаты немесе VPN-нің өз теңдес жеткізуі.

Сервер Ping жіберіп жатқанда клиенттің туннель интерфейсінде түсіріп алыңыз. Сұраудың жанында жауапсыз келуін көру — 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 мұны ешқашан көрсетпес еді, сондықтан әр сынақтың бағыты нәтижесінің жанындағы жазбаға тиесілі. Тикетте екі бағытты да сақтаңыз, әйтпесе келесі оқырман сәтсіздікке ұшырауы мүмкін емес сынақты қайталайды.

Қатысты мақалалар