Чи потрібен кожному піру OpenVPN рядок remote? Не зовсім

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

Що насправді задає remote

Запис remote називає хост, необов’язково порт і транспорт, а також необов’язково кілька таких записів, які пробуються по черзі.

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

Читайте запис як відношення адрес. Чи довіряти далекій стороні, відповідають сертифікати й параметри перевірки, а не сам факт записаної адреси.

Відповідь визначають три схеми

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

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

Ніщо в директиві не перетворює конфігурацію на сервер із багатьма клієнтами, і ніщо в її наявності не заважає ролі сервера. Довідка OpenVPN 2.6 описує необов’язкові аргументи й поведінку без remote окремо, що натякає на їхню незалежність.

Ролі транспорту — інша вісь

У TCP одна сторона чекає, а друга набирає. Це окремі від призначення директиви, і їх змішування дає пару, в якій обидві чекають або обидві набирають.

Існує також роль фільтра джерела TCP, тому пласке твердження, що сервер ніколи не може містити remote, хибне.

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

Чому відсутність remote — не відчинені двері

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

Автентифікація й призначення незалежні, і для довіри важливе перше.

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

Запишіть, що припускає конфігурація

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

Ці припущення і є проєкт. Директиви — лише їхній запис.

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