Другий вхід VPN через WAN не працює, а основний далі працює

Основний тунель залишається піднятим, користувачі продовжують працювати, а другий канал ISP простоює, хоч би що ви змінювали. Ви опублікували адресу для резервного каналу, спрямували на неї ім'я, можливо, додали резервний вхід у клієнт, а клієнт або ніколи його не пробує, або проходить автентифікацію і потім падає. У випадках, які я дослідив, функція перемикання зазвичай була гаразд; бракувало однієї з п'яти речей, які роблять вхід придатним до використання. Ім'я може розв'язуватися в резервну адресу, поки на цьому інтерфейсі ніхто не слухає, а прослуховувач може прийняти з'єднання, поки відповідь виходить через основний. Розглядайте кожну WAN як окремий вхід із власним контрактом, і збій перестане виглядати як помилка клієнта.

Кожній WAN потрібен власний контракт входу

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

Пристрій і його версія також мають підтримувати таку схему. Запис DNS не може відкрити службу на іншому інтерфейсі, а на багатьох платформах прослуховувач налаштовують за адресою, а не за пристроєм. IPsec на основі інтерфейсу в ASA прив'язує криптокарти й групи тунелів до зовнішнього інтерфейсу, тож другому аплінку потрібна політика там, куди ці пакети насправді приходять. Схеми на основі маршрутів поводяться інакше: прослуховувач може прив'язуватися до кожної адреси або до однієї названої адреси, і цей вибір вирішує, чи може ISP B взагалі відповісти.

Перевірте, чи друга WAN справді відповідає

Перевіряйте ззовні обох каналів, а не з машини за шлюзом, і перевіряйте саме те ім'я, яке використовує профіль клієнта. Для прослуховувача TLS швидка перевірка — це openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts, запущена з хоста поза вашою мережею. Вам потрібне завершене рукостискання, ланцюжок якого збігається з ім'ям у профілі, а не просто порт TCP, що приймає з'єднання.

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

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

Стежте за відповіддю, а не лише за запитом

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

Перевірте рішення про маршрутизацію для трафіку, джерелом якого є другий вхід. Відповідь має виходити через інтерфейс, яким прийшов запит, або принаймні нести адресу, яку віддалена сторона приймає як належну цьому шляху. На платформах із маршрутизацією політик це означає правило, прив'язане до вхідного інтерфейсу або трансльованого джерела, плюс інструкцію трансляції, прив'язану до кожного зовнішнього інтерфейсу. Знімайте захоплення на обох інтерфейсах одночасно, поки клієнт підключається; SYN, що приходить на ISP B, і SYN-ACK, що виходить на ISP A, вирішують питання за один прогін.

Дайте клієнтові спосіб дізнатися про другий вхід

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

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

Одна адреса в двох провайдерів — це інший продукт

Тримати одну публічну адресу доступною через обидва канали — це послуга маршрутизації, а не галочка у VPN. Для неї потрібен адресний простір, який обидва провайдери готові передавати, анонсований так, щоб їхні мережі його приймали, і саме це дає мультихостинг із незалежним від провайдера простором і BGP. Призначення адреси ISP A інтерфейсу ISP B туди не приведе; пакет потрапляє в мережу, яка ніколи не анонсувала цей префікс, і відкидається вище за течією.

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

Що перевірити далі

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

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