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, започнат от клиента, никога не би показал това, затова посоката на всеки тест принадлежи в записа до резултата му. Пазете и двете посоки в тикета, иначе следващият читател ще повтори теста, който не може да се провали.