Профили заштитног зида наспрам излаза VPN: зашто јавно није пут
Профил заштитног зида бира који се скуп правила примењује. Он не говори ништа о томе који је интерфејс носио пакет, а изричито блокирање побеђује ужу дозволу.
Правило звучи прецизно: дозволи локални саобраћај на приватном профилу и само VPN саобраћај на јавном. Није, јер мрежни профил бира који се скуп правила заштитног зида примењује и не говори ништа о томе који је адаптер носио пакет. Третирање имена профила као захтева за путању је грешка због које пројекат ограниченог излаза изгледа завршен када није.
Прво запишите токове, па одлучите који механизам заиста може да спроведе сваки од њих. Та листа токова је једини артефакт који преживи следећу измену правила.
Категорија бира правила, не руте
Када Windows класификује мрежу као јавну или приватну, заштитни зид примењује скуп правила конфигурисан за тај профил. Класификација прати мрежу којој се адаптер придружио, а скуп правила одлучује шта је на њој дозвољено. Ниједна од тих чињеница не зависи од тога да ли је саобраћај апликације користио тунел. Управо та независност је сва тешкоћа.
Избор путање врши рутирање, кроз метрику интерфејса и префикс који тунел инсталира. Профил зато може бити означен као јаван док веза апликације иде физичком путањом, а заштитни зид ће ипак пријавити да је примењен јавни скуп правила.
Зато правило ограничено на профил не може да значи само тунел. Та два својства одлучују различите компоненте и једно не може да замени друго.
| 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-а за правила заштитног зида разликује дозволу као изузетак од подразумеване радње блокирања од изричитог блокирања које је у сукобу са дозволом. Изричита блокирања побеђују у том сукобу, а излазна правила следе исти приоритет.
Зато популарни рецепт да се дода правило које блокира све и да се ослоните на ужу дозволу постављену изнад не ради оно што његов аутор очекује. Windows Firewall не решава сукоб по редоследу правила који је доделио администратор. Блокирање једноставно важи, а апликација која се повезује пријављује истек времена. Правило које је изгледало као изузетак никада није било у игри.
Подржани облик је политика подразумеваног одбијања са одобреним правилима дозволе, где свака дозвола именује програм, услугу или одредиште довољно прецизно да може да се прегледа. Такав пројекат пролази ревизију, јер је сваки изузетак видљив и ниједан не зависи од редоследа стварања.
Два правила која противрече једно другом гора су од једног правила, јер је резултујуће понашање истовремено тачно и необјашњиво.
Дајте излазној политици једног власника
Подржани VPN клијент већ одржава сопствено понашање блокирања и сопствене изузетке за крајње тачке. Додавање некоординисаних ручних правила може тај клијент да остави изван тунела који му је потребан за подешавање или да остави отворен други пут који нико није приметио.
Одлучите чија је излазна политика пре него што напишете правила: сопствена конфигурација клијента, управљана политика заштитног зида или документована локална листа изузетака са власником. Затим ускладите слојеве уместо да ређате експерименте док се нешто не повеже. Именовани власник је и онај кога питате када се два слоја не слажу.
Сачувајте канал за опоравак пре него што било шта промените. Удаљена машина закључана изван сопствене путање управљања гори је исход од празнине у политици коју сте затварали. Правило опоравка лакше је оправдати када је унапред записано и лакше га је наћи када измена крене наопако у сат који никоме није драг.
Тестирајте четири исхода уместо да читате етикету
Политика је добра онолико колико разликује случајеве, зато етикету профила третирајте као полазну тачку, а не као резултат. Четири исхода кажу да ли ради: предвиђени 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
Прва команда показује како је класификована свака повезана мрежа, што често није оно што је претпоставило лице које је написало правило. Друга показује подразумевану радњу по профилу, а трећа наводи омогућена излазна блокирања, укључујући она која ће тихо поништити ужу дозволу.
Покрените четири случаја поново након промене мреже, јер профил може бити рекласификован када се машина прикључи другој мрежи. Подударна етикета профила није доказ да је путања била она коју сте наменили.