Де має бути маршрут у OpenVPN: у клієнта чи в сервера?
Голий маршрут у конфігурації сервера змінює сервер, а не клієнта. Виберіть клієнтський файл, глобальний push або push для одного клієнта та перевірте, що дійшло.
Ви додаєте route 10.60.0.0 255.255.255.0 до конфігурації сервера, перезапускаєте, знову підключаєте ноутбук, а підмережа досі недоступна з цього ноутбука. Рядок було прийнято, служба запустилася чисто, і в журналі нічого не виглядає неправильно. Сталося те, що маршрут було встановлено на машині, яку ви редагували: шлюз тепер вважає, що може досягти цього префікса, а клієнту нічого не сказали. Усе питання в розміщенні, і є чотири місця, де той самий рядок може жити.
Чотири місця і хто отримує кожне
Маршрут можна додати власною конфігурацією клієнта, запропонувати кожному клієнту через глобальний push, запропонувати одному клієнту через файл для конкретного клієнта або записати у власний контекст маршрутизації сервера.
Ці чотири випадки використовують майже ідентичний синтаксис і дають цілком різні результати. Перші три впливають на те, що клієнт надсилає в тунель; четвертий впливає на те, як сервер досягає мережі, що корисно, коли самому серверу потрібен шлях, і шкідливо, коли його плутають із роздачею.
Вирішіть, який із чотирьох вам потрібен, перш ніж писати рядок, потім підтвердьте отримувача.
| Placement | Effect | Receiver |
|---|---|---|
| Client profile route | Installed by the client at connect | That client only |
Global push "route ..." | Sent to every client that accepts pushed options | All pulling clients |
| Client-specific push | Sent to the matching client context | One identity |
| Server config route, no push | Added to the server's own table | The gateway itself |
Чому голий серверний маршрут дивує людей
Конфігурація сервера — перше місце, куди дивляться адміністратори, і директива маршруту там читається як твердження про мережу VPN. Це не так. OpenVPN розглядає її як локальне встановлення маршруту на машині, де працює демон, — саме така сама зміна, яку ви зробили б за допомогою ip route і потім забули.
Роздача вимагає, щоб маршрут було надіслано через push, а push вимагає, щоб клієнт його забрав. Клієнт, запущений з вимкненими отриманими опціями, повністю ігнорує пропозицію. Перевірте обидва кінці цього рукостискання, перш ніж переписувати серверний файл, бо журнал сервера не поскаржиться: з його боку пропозицію надіслано. Прийнятий маршрут також набуває чинності лише за наступного підключення і ніколи в сеансі, у якому ви вже перебуваєте.
Щойно ви побачите дві операції як окремі, збій перестає бути загадковим: сервер досягає префікса, клієнт ні, і обидва твердження правдиві одночасно.
Файли для окремих клієнтів і ідентичність, якій вони відповідають
Файл для конкретного клієнта називається за ідентичністю, яку сервер автентифікував, а за замовчуванням це загальне ім'я сертифіката. Дружнє ім'я підключення в настільному клієнті не є цим значенням, і невідповідність створює файл, який ніколи не читається.
Перевірте каталог, який сервер справді використовує, потім підтвердьте, що ім'я файлу точно відповідає автентифікованій ідентичності, включаючи регістр літер.
grep -n 'client-config-dir' /etc/openvpn/server/server.conf
ls -l /etc/openvpn/ccd/Усередині цього файлу маршрут усе одно потрібно надіслати через push, бо контекст для окремого клієнта — це набір опцій, застосованих до сеансу цього клієнта, а не локальна таблиця маршрутизації. Голий маршрут там має ту саму проблему, що й голий маршрут у глобальному файлі.
Власний файл клієнта й інструмент, який ним володіє
Маршрут, вміщений у конфігурацію клієнта, встановлюється, коли цей клієнт підключається, і видаляється, коли відключається, що є правильним життєвим циклом для статичного призначення.
Якщо профілем володіє мережевий менеджер, він може один раз імпортувати ці опції, а потім зберігати власну копію. Редагування завантаженого файлу згодом нічого не змінює, і це часта причина фрази "маршрут є, але не застосовується".
Перевірте активний профіль, а не файл, який ви завантажили, і перевірте імпортовані налаштування, які показує менеджер. Потім підключіться і запитайте систему, який шлях використовує конкретна адреса, замість того щоб припускати, що тунель переміг, бо маршрут був у текстовому файлі.
Перевірте на клієнті, потім перевірте зворотний шлях
Запитайте власну таблицю маршрутизації клієнта про призначення, а не таблицю сервера. Пошуку одного хоста всередині префікса достатньо, щоб показати інтерфейс і наступний перехід, які будуть використані.
ip route get 10.60.0.10Якщо пошук указує на тунель, роздача спрацювала, і залишкова проблема в іншому місці. Якщо він указує на шлюз за замовчуванням, маршрут не було встановлено, його відфільтрувала опція на боці клієнта або він належить профілю, який клієнт не використовує.
Припустімо, роздача спрацювала, а ніщо не відповідає: тоді перевірте пересилання на шлюзі, зворотний маршрут протилежного боку і будь-який міжмережевий екран між ними. Маршрут вибирає шлях, він не дає доступу.