Зошто порта на огнена брана врзана со состојбата на VPN не е правило за ping само низ тунелот

Замислете правило на огнена брана што го вклучува ICMP echo за јавната адреса на серверот секогаш кога е поврзан наведен VPN профил. Тоа се чита како „ping само низ тунелот“, и тоа читање е погрешно на начин што е важен. Правилото не ограничува кој може да стигне до домаќинот; тоа менува на што одговара јавниот интерфејс додека некоја друга врска случајно е активна. Тоа се две различни политики, и едната од нив тивко го проширува изложувањето.

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

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

Штом условот стане состојба на врската, а не изворна адреса, множеството дозволени испраќачи повеќе не е множеството VPN партнери. Секој што може да стигне до јавната адреса може да испрати барање echo додека портата е отворена. Тунелот не стана патеката; тунелот стана прекинувачот.

Луѓето што ја промовираат оваа идеја обично не лажат за ефектот што го сакале. Им требаше проверка што одговара само кога врската е здрава, а здравјето на врската беше најлесно да се набљудува преку VPN. Грешката е да се третира сигнал за достапност како одлука за пристап и потоа да се автоматизира.

Што всушност контролира портата

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

Ако барањето навистина е само VPN партнери, опфатот го решава без никаква логика на состојба на врска: врзете го правилото за интерфејсот на тунелот или за опсегот на адреси на тунелот, ограничете ги оддалечените адреси на базенот на клиенти и наведете го типот echo наместо „ICMP“. Тоа правило останува точно кога нема активен VPN и не може да го отвори несоодветен профил.

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

Изградете го објектот еднаш, потоа префрлајте го

Однапред обезбедете едно правило со стабилен идентитет, оневозможено, и дозволете контролорот да ја менува само неговата состојба на овозможеност. Создавањето правила по прикажано име при секое извршување е патот по кој складиштето на политики завршува со пет речиси идентични објекти и без сигурен начин да се отстранат.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

Името е трајниот идентификатор; прикажаното име е документација што човек може да ја уредува. Усогласете по -Name и скриптата престанува да создава дупликати. Истиот облик на командата го покрива случајот IPv6 со -Protocol ICMPv6 -IcmpType 128, но тоа е одделно правило бидејќи броевите на типот echo се разликуваат меѓу двете семејства.

Држете ги семејството адреси и типот ICMP експлицитни и поради втора причина: -Protocol ICMPv4 без тип дозволува секоја ICMPv4 порака што профилот ја дозволува, вклучително и оние што никогаш не сте имале намера да ги прифатите. Именувањето на тип 8 го стеснува правилото на барањето echo, а тоа е единственото што го испраќа проверката на достапност.

Каде автоматизацијата противречи на намерата

Анкетирањето на клиентски профил на неколку минути не може да создаде моментална граница. Меѓу паѓањето на врската и следната анкета правилото се уште одговара на јавната адреса; меѓу кревањето на врската и следната анкета не одговара. Да се признае тоа доцнење е чесно, а да се тврди дека дизајнот наметнува строг инваријант не е.

Во самата проверка на состојбата има стапица на опфат. Get-VpnConnection пријавува клиентски профили конфигурирани на машината, стандардно за тековниот корисник и за сите корисници со -AllUserConnection. Не пријавува оддалечени корисници што моментално се поврзани на RRAS сервер; тоа е друго набљудување со друга команда. Порта изградена на погрешното не е поврзана со ништо.

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

На крајот, тестирајте го јавното барање двапати: еднаш со крената избрана врска и еднаш со спуштена, од домаќин што не е на VPN. Успешен ping од внатрешноста на тунелот не докажува ништо за оваа политика, и токму тоа мерење го прескокнуваат повеќето распоредувања.