Firewall профили наспроти VPN излез: зошто јавното не е пат
Firewall профилот избира кој сет правила се применува. Тој ништо не кажува за тоа кој интерфејс го пренел пакетот, а експлицитното блокирање победува над потесното дозволување.
Правилото звучи прецизно: дозволи локален сообраќај на приватниот профил и само VPN сообраќај на јавниот. Но не е, бидејќи мрежниот профил избира кој сет firewall правила се применува и ништо не кажува за тоа кој адаптер го пренел пакетот. Третирањето на името на профилот како барање за пат е грешката поради која дизајнот со ограничен излез изгледа завршен кога не е.
Прво запишете ги тековите, потоа одлучете кој механизам навистина може да го спроведе секој од нив. Таа листа на текови е единствениот артефакт што ја преживува следната промена на правила.
Категоријата избира правила, не маршрути
Кога Windows класифицира мрежа како јавна или приватна, firewall-от го применува сетот правила конфигуриран за тој профил. Класификацијата го следи мрежата на која се приклучил адаптерот, а сетот правила одлучува што е дозволено на неа. Ниту еден од тие факти не зависи од тоа дали сообраќајот на апликацијата го користел тунелот. Токму таа независност е целата тешкотија.
Изборот на пат го прави рутирањето, преку метриката на интерфејсот и префиксот што го инсталира тунелот. Затоа профилот може да биде означен како јавен додека врската на апликацијата оди по физичкиот пат, а firewall-от сепак ќе пријави дека е применет јавниот сет правила.
Затоа правило ограничено на профилот не може да значи само тунел. Двете својства ги одлучуваат различни компоненти и едното не може да го замени другото.
| Flow | What decides it | What a rule can enforce |
|---|---|---|
| VPN client to its endpoint | Routing plus the outer transport | Allow the client process before the tunnel exists |
| Application to an internet host | Interface metric and prefix length | Block the process unless the tunnel interface is up |
| Application to a LAN host | Local subnet route | Allow one destination, not the whole category |
Експлицитното блокирање е над потесното дозволување
Упатството на Microsoft за firewall правила разликува дозвола како исклучок од стандардното дејство на блокирање од експлицитно блокирање што е во спротивност со дозвола. Експлицитните блокирања победуваат во тој конфликт, а излезните правила го следат истиот приоритет.
Затоа популарниот рецепт да се додаде правило што блокира сѐ и да се потпре на потесна дозвола поставена над него не го прави тоа што го очекува неговиот автор. Windows Firewall не го решава конфликтот по редот на правила што го доделил администраторот. Блокирањето едноставно се применува, а апликацијата што се поврзува пријавува истек на време. Правилото што изгледаше како исклучокот никогаш не беше во игра.
Поддржаната форма е политика на стандардно одбивање со одобрени правила за дозвола, каде секоја дозвола именува програма, услуга или дестинација доволно прецизно за да може да се прегледа. Таков дизајн преживува ревизија, бидејќи секој исклучок е видлив и ниту еден не зависи од редоследот на создавање.
Две правила што си противречат се полоши од едно правило, бидејќи добиеното однесување е истовремено точно и необјасниво.
Дајте и на излезната политика еден сопственик
Поддржан VPN клиент веќе одржува сопствено однесување на блокирање и сопствени исклучоци за крајни точки. Додавањето некоординирани рачни правила може тој клиент да го остави надвор од тунелот што му е потребен за поставување или да остави отворен втор пат што никој не го забележал.
Одлучете чија е излезната политика пред да пишувате правила: сопствената конфигурација на клиентот, управувана firewall политика или документирана локална листа на исклучоци со сопственик. Потоа усогласете ги слоевите наместо да редите експерименти додека нешто не се поврзе. Именуваниот сопственик е и тој што го прашувате кога два слоја не се согласуваат.
Зачувајте канал за враќање пред да смените нешто. Оддалечена машина заклучена надвор од сопствениот пат за управување е полош исход од празнината во политиката што ја затворавте. Правилото за враќање полесно се оправдува кога е однапред запишано и полесно се наоѓа кога промената тргне наопаку во час што никој не го сака.
Тестирајте четири исходи наместо да го читате етикетот
Политиката е добра колку што разликува случаи, затоа третирајте го етикетот на профилот како почетна точка, а не како резултат. Четири исходи кажуваат дали работи: предвиденото LAN барање успева, опфатеното интернет барање успева, забранетото директно барање не успева, а случајот со дефект на тунелот се однесува како што е проектиран наместо тивко да се повлече. Запишете ги четирите резултати до промената на правилата. Планот за тестирање со четири именувани случаи е доволно краток за да се извршува секој пат и доволно конкретен за гласно да падне.
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,InterfaceAlias Get-NetFirewallProfile | Select-Object Name,DefaultOutboundAction Get-NetFirewallRule -Direction Outbound -Enabled True | Where-Object Action -eq Block | Select-Object DisplayName,Profile
Првата команда покажува како е класифицирана секоја поврзана мрежа, што често не е она што го претпоставило лицето што го напишало правилото. Втората го покажува стандардното дејство по профил, а третата ги наведува овозможените излезни блокирања, вклучително и оние што тивко ќе ја поништат потесната дозвола.
Извршете ги четирите случаи повторно по промена на мрежата, бидејќи профилот може да се рекласифицира кога машината се приклучува на друга мрежа. Совпаѓачкиот етикет на профилот не е доказ дека патот бил оној што сте го намениле.