Три види відмовостійкості OpenVPN на pfSense, три механізми

«OpenVPN failover» на pfSense охоплює щонайменше три не пов'язані між собою проєкти, і кожен із них потребує іншого механізму. Утримання тунелю живим через резервний інтернет-канал, повторне підключення до іншого сервера й спрямування трафіку LAN в інший уже встановлений тунель — це не варіанти однієї функції. Виберіть збій, від якого ви захищаєтеся, перш ніж будувати групу шлюзів. Група, яка виправляє один із них, нічого не робить для двох інших.

Назвіть збій, перш ніж будувати групу

Запишіть речення, яке хочете бачити правдивим під час збою. «Тунель перепідключається через резервний WAN» і «філія й далі доходить до застосунку через інший тунель» — різні речення. Лише перше про транспорт.

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

Локальний WAN: перенести транспорт

Для клієнта OpenVPN на pfSense підтримувана схема з кількома WAN вибирає відповідну групу шлюзів як інтерфейс, до якого прив'язується клієнт. Саме це дає зовнішньому з'єднанню виходити через резервний канал, коли основний відмовляє. Саме по собі це не змінює маршрутизацію внутрішнього трафіку.

Серверна сторона тієї самої схеми окрема. Серверу OpenVPN, який має бути доступним за кількома публічними адресами, потрібен слухач і вхідна політика для кожного з цих записів, а не лише клієнт, що вміє набирати через два канали. Один робочий публічний запис не доводить, що другий налаштований.

Правило маршрутизації на основі політики для пересиланих пакетів LAN — не те налаштування, яке переносить локально створене транспортне з'єднання VPN. Це два різні пошуки, і зміна одного не змінює іншого.

Віддалена кінцева точка: інший сервер

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

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

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

Шлях тунелю: вибрати інший вихід

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

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

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

Монітори, NAT і правило fail-closed

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

Перевірте вихідний NAT для обох виходів. Робоче перетворення на основному не описує адресу джерела резерву, а віддаленій приватній мережі потрібен зворотний маршрут, що відповідає тому джерелу, яке ви подаєте. Перетворення, правильне на одному шляху, може тихо бути неправильним на іншому.

Далі вирішіть, що відбувається з трафіком, який ніколи не повинен використовувати WAN. У pfSense визначено поведінку для правил, чий вибраний шлюз недоступний, а пізніше широке правило пропуску або маршрут за замовчуванням можуть скасувати ваш намір. Запишіть заблокований результат як вимогу й перевірте його, вимкнувши шлях.

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