Три вида отказоустойчивост на 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 описва обвързването на транспорта и експортираните клиентски алтернативи, на които това се крепи.