Ping работи само во една насока: зошто Windows го отфрла ехото од серверот

Вашиот клиент прави 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 од клиентот никогаш не би го покажал тоа, и затоа насоката на секое тестирање припаѓа во записот покрај неговиот резултат. Чувајте ги двете насоки во тикетот, инаку следниот читател ќе го повтори тестирањето што не може да пропадне.