Ping ради само у једном смеру: зашто Windows одбацује ехо сервера

Ваш клијент пингује сервер, сервер не може да пингује клијента, а тунел очигледно преноси пакете у обе те тврдње. Не разликује се пут, већ први пакет сваког теста: један је одговор на ток који Windows већ прати, други је нови долазни захтев који није пропустило ниједно правило. Та разлика објашњава већину извештаја о једносмерном пингу и показује директно на правило које треба да напишете. Два теста у супротним смеровима раздвајају случајеве за око минут.

Два смера, две различите одлуке

Када клијент пошаље захтев за ехо, заштитни зид 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 одобрења. Широко одобрење је лако решење и оно које најдуже траје, јер га после нико не примети.

На управљаном уређају правило може бити замењено при следећем освежавању политике, па власник политике мора да направи еквивалентну промену, а не локални администратор. Запишите намеру у тикет заједно са командом, јер ће освежавање избрисати команду и оставити захтев нетакнут. То нису исти артефакт и преживљава само један од њих.

Читајте резултат у правом смеру

Након што правило ступи на снагу, пингујте са сервера и потврдите да одговор стиже до клијента, затим пингујте из извора који и даље треба да буде искључен и потврдите да не стиже. Поновите тест доступности на другој фамилији адреса ако је тунел носи.

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

Штампање правила које је ступило на снагу корисније је од поверења у команду која га је створила, јер су преглед и примењено правило различита стања. Ако филтер адреса показује жељени извор, а искључени извор и даље истиче, правило ради тачно оно што његов опсег каже. Успешан ping са клијента то никада не би показао, зато смер сваког теста припада запису поред његовог резултата. Сачувајте оба смера у тикету, иначе ће следећи читалац поновити тест који не може да не успе.