Профілі фэйрвола супраць выхаду праз 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
Першая каманда паказвае, як класіфікавана кожная падключаная сетка, што часта не тое, што меркаваў чалавек, які пісаў правіла. Другая паказвае дзеянне па змаўчанні для кожнага профілю, а трэцяя пералічвае ўключаныя блакіроўкі зыходнага трафіку, у тым ліку тыя, што ціха адмяняюць вузейшы дазвол.
Прайдзіце чатыры выпадкі зноў пасля змены сеткі, бо профіль можа быць перакласіфікаваны, калі машына далучаецца да іншай сеткі. Супадзенне этыкеткі профілю не доказ таго, што шлях быў менавіта ваш.