Чому адмінка роутера перестає відповідати після зміни VPN

Ви змінили маршрут або правило брандмауера, щоб перевірити тунель на роутері, і тепер сторінка адміністрування не відповідає з ноутбука, який десять хвилин тому працював нормально. Рефлекс — звинувачувати VPN. Найчастіше тунель у порядку, а зламалося одне з трьох інших: немає маршруту назад на власну адресу роутера, політика входу відкидає запит, або вебслужба не слухає адресу, до якої ви звертаєтеся. Усі три виглядають у браузері однаково, тому люди годину перезапускають тунель і нічого не дізнаються.

Ось міф, який варто вбити першим: робочий тунель — не шлях назад усередину. Це нове мережеве підключення з власними питаннями довіри, і воно може тихо прибрати старий шлях керування, відкривши новий, який ніхто не перевіряв.

Тунель ніколи не був шляхом керування

Пересилання та вхід — різні завдання. «Чи може клієнт дістатися до NAS через тунель?» — це питання пересилання про пакети, що проходять через роутер. «Чи можу я відкрити порт SSH роутера?» — це питання входу про пакети, адресовані самому роутеру. Правило пропуску, написане для пересильного трафіку, нічого не робить для другого, і це найчастіша причина, чому тунель, який бездоганно несе трафік, усе ж відхиляє вашу сесію адміністрування.

Зворотна помилка — довіряти назві інтерфейсу. Тунель шифрується до партнера, а не до кожної служби за ним, і слово VPN на етикетці інтерфейсу нічого не каже про те, яким джерелам має бути дозволений вхід.

Перший шар: чи є маршрут до власної адреси роутера?

Почніть на клієнті й запитайте ядро, куди піде пакет. У Linux ip route get 10.6.0.1 друкує вибраний маршрут, вихідний інтерфейс і адресу джерела. Якщо він повідомляє маршрут за замовчуванням у бік вашого провайдера, пакет ніколи не входить у тунель, і жодне правило на роутері його не врятує.

Бік тунелю має власну версію питання. WireGuard розглядає AllowedIPs як таблицю маршрутизації криптоключів: на кожному кінці вона оголошує, які адреси джерела партнер може використовувати і які призначення надсилаються цьому партнеру. Якщо запис клієнта не містить тунельної адреси роутера, клієнт не має до неї маршруту. Якщо запис сервера для цього клієнта не охоплює тунельної адреси клієнта, сервер відкидає пакет ще до того, як буде переглянуто хоч одне правило брандмауера.

Підтвердьте точну адресу, якої ви хочете досягти, перш ніж налагоджувати політику. Застарілий запис DNS або кешований запис сусіда з часів до зміни веде вас на адресу, якою роутер ніколи не володів.

Другий шар: політика входу, а не політика пересилання

Брандмауери оцінюють правила на інтерфейсі, куди надходить пакет. У pfSense та OPNsense вкладка інтерфейсу й порядок правил вирішують, чи дозволено трафік до власних служб брандмауера; правило, яке випускає клієнтів LAN в інтернет, не є правилом, що дозволяє партнерові тунелю відкрити вебінтерфейс. В OpenWrt із firewall4 кожна зона несе політику входу, option input 'ACCEPT' або 'REJECT', і тунельний інтерфейс у зоні з входом REJECT відхилятиме керівні з'єднання, водночас далі пересилаючи трафік, якщо пересилання дозволене.

Не вимикайте правило захисту від блокування, щоб новий шлях запрацював. Це правило не дає поганому правилу заблокувати адресу керування LAN; воно захищає підмережу LAN, а не підмережу тунелю, яку ви щойно створили. Додайте одне вузьке правило для джерела адміністратора й залиште страхувальну сітку в спокої. Документація pfSense про доступ адміністратора пояснює, де ці елементи керування.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

Третій шар: чи щось слухає цю адресу?

Служба може працювати й усе одно бути недосяжною, бо прив'язалася до однієї адреси. uhttpd в OpenWrt тримає явні записи прослуховування в /etc/config/uhttpd, наприклад list listen_http '0.0.0.0:80'; збірка, що прив'язується лише до адреси LAN, нічого не приймає на тунельній адресі, а продукти з налаштуванням інтерфейсу прослуховування поводяться так само. Наведені вище команди прослуховування відповідають на це безпосередньо.

Потім відділіть відмову від тиші. nc -vz 10.6.0.1 443, що повертає відмовлене з'єднання, означає, що пакет дійшов до роутера і щось його відхилило — або закритий порт, або явне правило відмови. Зависання до тайм-ауту означає, що пакет було відкинуто або взагалі не маршрутизовано. Ця різниця підказує, який шар перевіряти далі, і коштує п'ять секунд.

Інтерфейс VPN — це межа, а не шлях відновлення

Шифрування захищає провід; воно нічого не каже про те, кому можна відкривати сторінку адміністрування. Коли тунель запрацює, опирайтеся бажанню вирішити доступність дозволом усього на тунельному інтерфейсі. Дайте адміністраторам правило, прив'язане до їхньої власної тунельної адреси, або окремий тунель лише для адміністраторів, і тримайте звичайних користувачів, NAS, камери та родинні ноутбуки подалі від порту керування. Партнер, якому потрібен обмін файлами, не повинен бути за одне правило від входу в роутер.

Роль роутера змінює відповідь. Роутер, який завершує тунель, може законно приймати адміністраторів із нього, а роутер, що використовує тунель лише як вихід в інтернет, зазвичай не повинен. В обох випадках дозвіл підмережі — не вхід, тож залиште ввімкненими автентифікацію облікового запису й безпеку транспорту.

Компенсаційний крок, який люди роблять після блокування, гірший: увімкнення адміністрування через WAN або переспрямування порту на вебінтерфейс. Це перетворює короткий збій на постійну експозицію, і сторінка входу стає доступною кожному сканеру в інтернеті. Перевіряйте й заборонений бік, а не лише дозволений, щоб партнер, якому не годиться мати адміністративний доступ, отримував тайм-аут або відмову замість запрошення до входу.

Перевіряйте й новим з'єднанням. Брандмауер зі станом тримає наявні потоки у своїй таблиці станів, тож уже відкрита сесія SSH може пережити зміну, яка блокує кожне нове з'єднання. Так блокування залишається непомітним до наступного перезавантаження або наступного сну ноутбука.

Підготуйте шлях назад, перш ніж торкатися політики

Запишіть чотири речі до першої зміни: як ви дістанетеся до пристрою, якщо тунель помре, наприклад через послідовну консоль, консоль провайдера або машину в LAN; куди експортується поточна конфігурація; яке одне правило або маршрут ви збираєтеся змінити; і як ви повернете саме цей елемент. В OpenWrt sysupgrade -b /tmp/backup.tar.gz знімає конфігурацію, а правки залишаються в очікуванні до uci commit, що дає дешеве скасування, якщо помітити вчасно. pfSense веде історію конфігурації, а AutoConfigBackup допомагає лише якщо його вже було ввімкнено. Якщо роутер працює з набором правил fail-closed, переконайтеся, що запланований шлях обслуговування не лежить усередині трафіку, який блокує це правило, і пам'ятайте, що перезавантаження знову застосовує постійні правила, а не стирає їх.

Змінюйте одну межу за спробу, потім перевіряйте з нового з'єднання, а не з оболонки, яку тримаєте відкритою. Якщо тест не вдався, відкотіть цю одну зміну, перш ніж торкатися наступного шару. Тунель може залишатися піднятим увесь час, але його зелений значок стану не є доказом, що ви ще можете ввійти.

Швидка перевірка перед виходом:

• Чи дістаєтеся ви до роутера з джерела, що не залежить від щойно зміненого правила?
• Чи дозволяє політика входу на тунельному інтерфейсі лише джерело адміністратора?
• Чи прив'язана служба керування до адреси, що існує в тунелі?
• Чи перевірили ви одного забороненого партнера й одну нову сесію?
• Чи поверхня адміністрування через WAN усе ще закрита?