VPN клиентите блокирани од јавниот профил на заштитниот ѕид на Windows

Тунелот е подигнат, портата кон мрежата одговара на ping, а споделувањето датотеки се уште истекува. Таа комбинација ретко е проблем со рутирањето: Windows ја ставил подмрежата на VPN адаптерот во Јавниот профил и секое правило за дозвола напишано за Приватен или Доменски профил никогаш не се применило. Сретнал сум го ова на преносни компјутери што без проблем стигнуваат до канцеларијата и на RRAS сервери што ги опслужуваат сите други клиенти, а поправката е кратка штом го именувате профилот што е во игра. Еве го редоследот по кој работам, со проверката што ви кажува кога да застанете пред следниот чекор.

Утврдете на кој профил сообраќајот навистина пристигнува

Заштитниот ѕид на Windows нема единствен глобален режим. Секој поврзан интерфејс носи категорија, а влезните пакети се филтрираат според категоријата на интерфејсот низ кој пристигнуваат, па профилот на VPN адаптерот одлучува што може да достигне клиент во тунелот, а не Wi-Fi или Ethernet адаптерот до него. Прочитајте ги двата факти пред да промените нешто:

Get-NetConnectionProfile | Select-Object Name, InterfaceAlias, NetworkCategory, IPv4Connectivity
Get-NetFirewallProfile -Name Public | Select-Object Name, Enabled, DefaultInboundAction

При стандардна инсталација на OpenVPN или WireGuard, VPN адаптерот се појавува како неидентификувана мрежа и завршува во Јавниот профил, што е стандардна вредност за секоја мрежа што Windows не може да ја класифицира: ниту еден контролер на домен не одговорил преку неа и ниту еден профил на порта не се совпаднал. Името на интерфејсот овде не е важно, па нарекувањето на адаптерот „VPN“ или „Corp“ ништо не менува. DomainAuthenticated бара машина приклучена на доменот , која преку тој интерфејс навистина може да достигне контролер на домен; разделен тунел што пренесува само една подмрежа нема да го исполни условот.

Ако правилото што ви треба веќе е ограничено на VPN пулот и веќе се применува на категоријата што штотуку ја прочитавте, застанете овде: филтрирањето не е ваш слој, а следното место за проверка е конфигурацијата на услугата. Таа проверка трае десет секунди и штеди еден час уредување правила. Имињата на категориите и што покрива секоја се документирани во референцата Get-NetConnectionProfile.

Потврдете филтрирање, а не рутирање, пред да уредувате правила

Ping е слаб тест. ICMP може да помине додека портот на услугата се отфрла, а домаќинот може да одговори од LAN додека го одбива истото барање преку тунелот. Тестирајте го портот што му треба на клиентот, од клиентот:

Test-NetConnection 10.8.0.1 -Port 445
Test-NetConnection 10.8.0.1 -Port 3389 -InformationLevel Detailed

Ако тестот на портот не успее, разделете ги двата слоја. Дефект на тунелот или рутата обично се покажува како никаков одговор од адресата на портата, додека отфрлањето од заштитниот ѕид покажува порта што одговара и порт на услуга што не одговара. На Windows сервер што го објавува пулот преку RRAS, извршете го истиот тест од клиент и прочитајте го сопствениот профил на серверот: RAS интерфејсот може да стои во категорија чии влезни правила никогаш не го споменуваат опсегот на клиентите, и затоа машината ја опслужува сопствената LAN и одбива секој клиент во тунелот.

Кога резултатот е се уште двосмислен, запишете ги отфрлањата за профилот во игра и прочитајте ги:

Set-NetFirewallProfile -Name Public -LogBlocked True `
  -LogFileName "$env:systemroot\system32\LogFiles\Firewall\pfirewall.log"

Записите што ја именуваат адресата и портот на клиентот со DROP се убедливи и ви кажуваат и кое правило недостасувало. Дневник без ништо во него, додека SYN на клиентот никогаш не се појавува, укажува пред домаќинот, па вратете се на тунелот, NAT правилото или рутата на пулот пред да допрете друг објект на заштитниот ѕид.

Ограничете едно влезно правило на пулот на клиенти

Поправката е едно влезно правило за дозвола чија оддалечена адреса е пулот, а не целиот свет. Од сесија со зголемени права:

New-NetFirewallRule -DisplayName "VPN clients - SMB 445" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 445 `
  -RemoteAddress 10.8.0.0/24 -Profile Public

Кога услугата е една бинарна датотека, дајте предност на правило ограничено на програма со -Program наместо список на портови; тоа го ограничува исклучокот и на процесот и на опсегот на изворот.

Изборот на профил е местото каде што истата грешка се прави во спротивна насока. -Profile Public е доволно кога адаптерот е Јавен и останува Јавен. -Profile Any е одбранливо кога услугата мора да работи без оглед на тоа како Windows го класифицира адаптерот, но само додека останува оддалечениот опсег. Она што никогаш не е одбранливо е -RemoteAddress Any на Јавниот профил: тоа правило го следи преносниот компјутер во секоја мрежа на кафуле и хотел на која се приклучува и го отвора портот за секој што ја дели таа подмрежа.

Запишете го пулот до правилото. -RemoteAddress 10.8.0.0/24 тивко престанува да се совпаѓа во денот кога VPN пулот се пренумерира, а дефектот изгледа точно како првобитната грешка, затоа чини уште едно попладне. Именувајте ги правилата по услугата и опсегот на изворот, држете ги заедно со -Group, и препрочитувајте ги секогаш кога дефиницијата на пулот се менува. Инвентар на правила што можете да го прегледате на еден екран е подобар од точно правило што никој не може да го најде.

Менувајте ја категоријата само кога категоријата е одлуката

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

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

Set-NetConnectionProfile -InterfaceAlias "OpenVPN TAP-Windows6" -NetworkCategory Private

На управуван уред прво проверете дали поставката ја поседува групна политика или MDM основна линија. Ако ја поседува, локалната промена се поништува при следното освежување, а gpresult /h ќе ја именува политиката што ја поседува; поправете го тоа таму, а не на крајната точка.

Проверете од двата краја и оставете трага

Проверете го текот што го пријавил корисникот, од клиентот, по промената:

Test-NetConnection 10.8.0.1 -Port 445
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallAddressFilter | Select-Object RemoteAddress
Get-NetFirewallRule -DisplayName "VPN clients - SMB 445" | Get-NetFirewallPortFilter | Select-Object Protocol, LocalPort

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

Пред да го прогласите за готово:

• Профилот наведен во правилото е профилот на интерфејсот низ кој пристигнува сообраќајот.
• Оддалечениот опсег е VPN пулот, и тој пул одговара на она што серверот навистина го доделува.
• Ниту едно правило што го додадовте не користи -RemoteAddress Any на Јавниот профил.
• Ништо не беше оневозможено за тестот да помине, и секоја промена на категоријата запишува кој ја одобрил.