Профили на защитната стена срещу изход през 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
Първата команда показва как е класифицирана всяка свързана мрежа, което често не е това, което е предполагал човекът, писал правилото. Втората показва действието по подразбиране за всеки профил, а третата изброява включените изходящи забрани, включително онези, които тихо ще отменят по-тясно разрешение.
Изпълнете четирите случая отново след промяна в мрежата, защото профилът може да бъде прекласифициран, когато машината се присъедини към друга мрежа. Съвпадащ етикет на профила не е доказателство, че пътят е бил този, който сте искали.