Блокира ли защитната стена VPN? Проверка стъпка по стъпка

Едно изтичане на времето при VPN доказва, че не е пристигнал използваем отговор, и не доказва нищо за причината. Профилът може да сочи грешен порт, сървърът може да е спрян или заявката може да пристигне без работещ обратен път. Всяко от тези оставя различна следа и именно следата ти казва кое правило да пипнеш. Мини четирите етапа по-долу по ред. Спри веднага щом един от тях обясни симптома.

Стъпка 1: потвърди сървъра и транспорта

Прочети името на сървъра, транспорта и порта от текущия профил на оператора, а не от локална промяна. Порт, променен на лаптопа ти, не може да създаде слушател на публичен сървър и това разминаване дава същото изтичане на времето като блокировка. Ако профилът предлага поддържан алтернативен транспорт, отбележи го като резервен вариант, а не като поправка. Разреши името и сравни отговора с адреса, който операторът е публикувал.

Остарял DNS запис изпраща клиента към хост, който никога не е отговарял. Това е друга повреда, която имитира филтър, и струва една заявка, за да се изключи.

Запиши двете стойности в тикета. Всяко следващо сравнение ги използва, а тикет без тях започва разследването отначало.

Стъпка 2: докажи пътя с едно контролирано сравнение

Остави устройството и профила непроменени и опитай друга доверена мрежа за достъп. Ако тунелът се вдигне там, разликата е в първоначалния път или в неговата политика. Ако второ одобрено устройство работи в първоначалната мрежа, разликата е в първото устройство. Едно от тези две сравнения почти винаги е решаващо.

Първо завърши всеки законен мрежов вход, защото captive portal изглежда като блокировка, докато не приключи.

Тествай порта, който реално използваш, и приемай резултата от TCP като информация само за TCP.

Resolve-DnsName vpn.corp.example
tracert -h 8 -w 500 vpn.corp.example
Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed

Успешно TCP ръкостискане на порт 443 означава, че там е отговорил слушател. То не казва нищо за UDP слушател на 51820 и нищо за това дали преговорите са завършили.

Стъпка 3: прочети събитията за сигурност за момента на отказа

Събитията на защитната стена са най-силното налично доказателство и носят уточнение, което заслужава да се каже първо. В много профили по подразбиране журналирането е изключено, затова провери дали съответният профил записва отхвърляния, преди да прочетеш празен журнал като доказателство за невинност. Когато журналирането е включено, събитието посочва правилото, посоката и адресите, което е точно това, което е нужно за промяна на правило. Правилата за приложения и правилата за портове са отделни обекти и управляваната политика може да отмени локална настройка. Потвърди кой клиент и коя услуга покрива правилото в действителност.

Събери състоянието на профила и последните събития от машината, която се провали, а не от съседен хост.

Сравни часа на събитието с часа на твоя опит за тест, защото съвпадащо име на правило с различен час е случайност.

Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, LogBlocked
Get-NetFirewallRule -Enabled True -Direction Outbound | Where-Object DisplayName -match 'VPN'
Get-WinEvent -LogName 'Microsoft-Windows-Windows Firewall With Advanced Security/Firewall' -MaxEvents 20

На сървър, който администрираш, питай дали заявката изобщо е стигнала до слушателя. Пристигащ пакет без отговор е проблем с препращането или с обратния маршрут. Заявка, която никога не се появи, е проблем с филтрирането или адресирането.

Стъпка 4: тествай препращането, след като тунелът е вдигнат

Защитната стена може да разреши сесията и пак да откаже всичко, до което сесията иска да стигне. Sysctl за препращане, NAT правила и обратни маршрути стоят след удостоверяването и широко изключение за VPN порта не поправя никое от тях. Тествай една вътрешна дестинация и една интернет дестинация поотделно, защото те обикновено се провалят по различни причини. Ако вътрешните имена се провалят, а адресите работят, погледни подадения DNS преди всяко правило.

Изпълни трите проверки по-долу на сървъра, докато клиент е свързан и опитва неуспешната заявка.

Броячите на интерфейса на тунела са важната част, защото показват дали пакетите са влезли и дали нещо е излязло.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -n -E 'forward|masquerade'
tcpdump -ni tun0 -c 10

Когато пакети пристигат на тунела и нищо не излиза към дестинацията, заподозрян е препращането или NAT. Когато не пристига нищо, сесията е вдигната, но клиентът не изпраща и мястото за гледане е таблицата с маршрути на клиента.

Провери поправката и премахни това, което не помогна

След одобрена корекция повтори точния тест, който се провали, и запиши резултата срещу същия профил и устройство. След това премахни всяко временно изключение, което не промени резултата, защото неизползваните изключения се натрупват и всяко едно е решение, което никой не помни. Запази останалото тясно: една дестинация, един порт, една посока, един собственик.

Пусни отново същите три команди и ги сравни с изхода, който си запазил преди промяната.

Test-NetConnection vpn.corp.example -Port 443 -InformationLevel Detailed
tracert -h 8 -w 500 vpn.corp.example
Get-NetFirewallRule -Enabled True | Where-Object DisplayName -match 'VPN' | Select-Object DisplayName, Action

Когато сравнителната мрежа работи, първоначалната мрежа все още се проваля и събитията остават празни, останалият заподозрян е пътят, а не хостът. Предай това на собственика на мрежата като конкретно твърдение, с приложени два резултата от сравнението. Това е по-добро място за спиране от изключен профил на защитната стена.