Кілька OpenVPN-з’єднань: список failover, а не об'єднання каналів

Два рядки remote в одному профілі виглядають як друга смуга; насправді це друга спроба. Коли перший endpoint перестає відповідати, клієнт переходить далі, і сеанс не стає ширшим. Назвіть список failover відразу, інакше крутитимете не ту ручку.

Що дає список remote

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

Справжня агрегація — інша машина. Щоб рознести один потік кількома шляхами, потрібне програмне забезпечення на обох кінцях, яке розділить і знову збере трафік за порядком.

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

Блоки, що тримають налаштування при одному endpoint

Звичайний рядок remote несе адресу, а іноді порт і протокол. Коли endpoint потребує проксі або транспорту, який решта файлу не використовує, покладіть ці налаштування в блок з'єднання, що тримає їх разом із ним. Вбудовані блоки працюють і в одному файлі .ovpn, і саме так постачається більшість профілів.

Усе поза блоком діє як типове значення для записів, які його не перекривають. Тому один збудований блок і чотири звичайні remote поводяться так, чого список адрес не може пояснити.

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

Порядок повторів і ціна remote-random

Порядок важливий, бо кожен мертвий запис коштує часу перед наступною спробою. Поставте потрібний endpoint першим, а решту вважайте ранжованими запасними.

remote-random перемішує стартовий порядок: навантаження розходиться по рівноцінних серверах, але за явно головного endpoint це б'є в зворотний бік. У будь-якому разі фіксуйте в журналі endpoint, який вибрав клієнт; ім'я профілю нічого не каже, коли з'єднання здається повільним. Пошук рядка з'єднання в докладному журналі показує, де приземлився сеанс.

Змішування операторів ламає заяву про довіру

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

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

Перевіряйте кожен запис, а не припускайте

Після схваленого оновлення профілю навмисно підключіться до кожного потрібного endpoint і підтвердьте, який транспорт піднявся. Докладний запуск робить це видимим. Запустіть openvpn --config office.ovpn --verb 4 і прочитайте рядок з'єднання для очікуваної адреси. Потім перевірте ресурси за тунелем; запис може завершити рукостискання і все одно нікуди вас не скерувати.

Failover потребує власної перевірки, а не надії. Заблокуйте перший endpoint у лабораторії, запустіть клієнт і виміряйте, скільки часу потрібно, щоб перейти далі. Довгий список за повільним першим записом гірший за короткий, який добре стартує.

Перевіряйте список знову щоразу, коли оператор його змінює. Імпортований набір корисний лише доки його записи існують і говорять транспортом, який описують ваші блоки. Посібник OpenVPN 2.6 описує тут директиви remote, connection і random-order, і це та версія, яку варто перевіряти, коли синтаксис сумнівний.