Дали firewall-от го блокира VPN-от? Проверка чекор по чекор

Еден истек на време на VPN докажува дека не пристигнал никаков употреблив одговор и ништо не докажува за причината. Профилот може да наведе погрешен порт, серверот може да биде исклучен или барањето може да пристигне без работна повратна патека. Секое од овие остава различен траг, а трагот е тоа што ви кажува кое правило да го допрете. Поминете низ четирите фази подолу по ред. Запрете веднаш штом една од нив го објасни симптомот.

Чекор 1: потврдете го серверот и транспортот

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

Застарен DNS запис го испраќа клиентот до домаќин што никогаш не одговорил. Тоа е уште еден дефект што имитира филтер и чини едно барање за да се исклучи.

Запишете ги двете вредности во тикетот. Секоја подоцнежна споредба ги користи, а тикет без нив ја започнува истрагата одново.

Чекор 2: докажете ја патеката со една контролирана споредба

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

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

Тестирајте го портот што навистина го користите и третирајте го 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: прочитајте ги безбедносните настани за моментот на дефектот

Настаните на firewall-от се најсилниот достапен доказ и носат една забелешка што вреди прво да се каже. Евидентирањето е исклучено во многу стандардни профили, затоа проверете дали соодветниот профил ги запишува отфрлањата пред празен дневник да го прочитате како доказ за невиност. Кога евидентирањето е вклучено, настанот го наведува правилото, насоката и адресите, што е точно она што му треба на една измена на правило. Правилата за апликации и правилата за порти се одделни објекти, а управуваната политика може да го надмине локалното поставување. Потврдете кој клиент и која услуга правилото навистина ги покрива.

Соберете ја состојбата на профилот и последните настани од машината што не успеа, а не од соседен домаќин.

Споредете го времето на настанот со времето на вашиот обид за тест, бидејќи совпаѓачко име на правило со различен временски печат е случајност.

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: тестирајте проследување откако тунелот е подигнат

Firewall-от може да ја дозволи сесијата и сепак да одбие сѐ до што сесијата сака да стигне. 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

Кога споредбената мрежа работи, оригиналната мрежа сѐ уште не успева и настаните остануваат празни, преостанатиот сомнителен е патеката, а не домаќинот. Предајте го тоа на сопственикот на мрежата како конкретна изјава, со двата резултати од споредбата приложени. Тоа е подобро место за запирање од исклучен профил на firewall.