Чому шлюз брандмауера, прив'язаний до стану 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 зсередини тунелю нічого не доводить про цю політику, і саме це вимірювання пропускає більшість впроваджень.