Защо портата на защитната стена, обвързана със състоянието на 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 от вътрешността на тунела не доказва нищо за тази политика и точно това измерване повечето внедрявания пропускат.