OpenVPN: local і адреса тунелю, два різні сокети

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

Помилка прив'язування називає локальну адресу

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

Явна директива local просить демон прив'язати цей сокет до конкретної локальної адреси. Адреса має існувати в мережевому просторі імен, де працює процес, і має бути призначуваною в момент запуску клієнта.

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

Що насправді вибирають local і remote

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

Жодна з директив не має нічого спільного з адресою всередині тунелю.

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

ip -brief address show
ip route get 203.0.113.10

Внутрішня адреса надходить від сервера

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

Запис local із внутрішньою адресою не просить сервер виділити цю адресу. У найкращому разі прив'язування не вдається; у найгіршому клієнт знаходить сторонню адресу хоста з тим самим значенням і починає використовувати її для транспорту.

Інтерфейси, які треба читати, теж інші. Параметри ifconfig і конфігурація пулу описують внутрішній бік, а remote, local, proto і nobind описують зовнішній. Розділення цих двох списків пояснює майже кожен заплутаний приклад, який ви знайдете на форумі. Саме тому посібник OpenVPN 2.6 описує їх в окремих розділах.

Пастка: повний тунель, що захоплює власний транспорт

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

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

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

Звичка, яка запобігає плутанині

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

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

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