OpenVPN remote-random: перемішаний порядок, один тунель

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

Ця різниця важлива і для тестування, і для заяв про конфіденційність.

Що опція змінює в момент підключення

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

Посібник OpenVPN документує опцію як таку, що впливає на порядок спроб підключення, і саме такого обсягу слід очікувати в поведінці.

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

Міф: кожен запит отримує новий сервер

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

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

Для чого потрібен remote-random-hostname

Друга директива зі схожою назвою змінює ім'я хоста, яке використовується для розв'язання, а не порядок списку remote. Вона існує для розгортань, де ім'я розв'язується в кілька адрес через round-robin DNS, і її слід використовувати лише тоді, коли сервіс для цього побудований. Змінюється лише крок розв'язання; порядок списку кандидатів — ні.

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

Прочитайте вибрану кінцеву точку з журналу

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

grep -c '^remote ' client.ovpn
openvpn --config client.ovpn --verb 4 2>&1 | grep -i -E 'attempting|peer connection'
openvpn --help | grep -A2 remote-random
head -20 client.ovpn

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

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