Як побудувати політику резервного перемикання VPN на роутері без витоків

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

Визначте результат до вибору детектора

Зазвичай на столі три результати: відправити постраждалих клієнтів через резервний тунель, дозволити їм користуватися звичайним WAN або заблокувати їх повністю. Запишіть, який із них стосується якої VLAN, SSID чи класу пристроїв. Одне пласке правило «перемкнути на WAN» — це те, як фінансова тека вище опинилася на публічному шляху.

Ці три не є взаємозамінними. Повернення на WAN дозволяє службі підтримки відповідати на дзвінки, але розкриває внутрішні імена локальному резолверу. Резервний тунель зберігає політику, але може опинитися на вихідній адресі, яку віддалена сторона не приймає. Блокування правильне для VLAN зарплати й неправильне для гостьової мережі, яка ніколи не користувалася тунелем.

Зіставте детектор із тим збоєм, якого ви справді боїтеся

Стан рукостискання, стан інтерфейсу та працездатна пересилка — це три різні сигнали, і користувачеві важливий лише останній. Вузол WireGuard може показувати свіже рукостискання, поки вищестояща мережа провайдера відкидає пакети. Клієнт OpenVPN може залишатися «підключеним» після того, як просунутий ним маршрут перестав розв'язуватися.

У pfSense практичне рішення — це група шлюзів, яку живить dpinger, що опитує адресу моніторингу й позначає шлюз як недоступний, коли втрати або затримка перевищують пороги. Спрямуйте цей монітор на щось за межами тунелю, наприклад на хост у віддаленій LAN або на публічну адресу, доступну через нього. Націлення на власну адресу вузла тунелю вимірює ту частину, про яку ви вже знаєте, що вона жива.

Побудуйте групу так, щоб резерв залишався останнім засобом

Використовуйте рівні, а не один плаский список учасників. Основний на рівні 1, резервний тунель на рівні 2, WAN на рівні 3 лише для тих VLAN, чия політика це дозволяє. У pfSense це міститься в System > Routing > Gateway Groups: додайте обидва шлюзи, задайте їм різні рівні, встановіть Trigger Level на недоступність учасника плюс втрату пакетів, збережіть, а потім застосуйте групу як шлюз за замовчуванням інтерфейсу або в полі Gateway правил брандмауера, яким вона потрібна.

Для екземпляра клієнта OpenVPN у pfSense 2.5 і новішому параметр Default Gateway екземпляра вирішує, чи тунель взагалі замінює системний маршрут за замовчуванням. Маршрутизація за правилами поводиться так, як ви очікуєте, лише коли маршрут, який ви припускаєте, справді встановлено. Після зміни перевірте Status > Gateways, а не довіряйте значку стану тунелю.

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

Закрийте шляхи, якими тунель ніколи не володів

Спочатку витоки DNS. Резолвер продовжує відповідати на WAN і пересилати через неї, тож імена й далі розв'язуються через провайдера, поки трафік прикріплений до тунелю. Обмежте вихідні інтерфейси резолвера, проштовхніть внутрішній резолвер клієнтам і заблокуйте порт 53 для всього іншого у VLAN лише з VPN.

IPv6 потребує власного рішення. LAN з подвійним стеком може втратити тунель і зберегти працюючий глобальний маршрут за замовчуванням IPv6, тож браузери віддають перевагу IPv6 і виходять через WAN, поки IPv4 виглядає ідеально закритим. Або маршрутизуйте IPv6 у тунель, або припиніть оголошувати глобальний префікс, поки тунель недоступний. Половина політики гірша за жодну, бо вона виглядає працюючою.

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

Перевірте падіння, миготіння і шлях назад

Відключіть основний при безпечному трафіку, потім прочитайте чотири речі: Status > Gateways для станів учасників групи, pfctl -ss для станів, ще прикріплених до старого шлюзу, traceroute з клієнта для вихідного шляху та запит до резолвера, щоб побачити, який сервер відповів.

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

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

Перш ніж вважати політику готовою, ви маєте відповісти на чотири запитання, не відкриваючи термінал: які VLAN можуть користуватися WAN, поки тунель недоступний, що спостерігає детектор і скільки чекає, які сервери імен і маршрути IPv6 рухаються разом зі шляхом, і як ви повернетеся, якщо резерв теж відмовить. Якщо будь-яка відповідь — «що було за замовчуванням», політика все ще належить роутеру, а не вам.