MULTI: хибна адреса джерела від клієнта: чия це була адреса?
Внутрішнє джерело не збігається з клієнтом, який його доставив. Зіставте його з призначенням тунелю, LAN за клієнтом або дубльованою особистістю.
Журнал сервера друкує MULTI: bad source address from client, відкидає пакет, а сеанс залишається з’єднаним. Таке поєднання бентежить тих, хто читає повідомлення як невдалу автентифікацію. Це не так: клієнт пройшов автентифікацію, а пакет, що надійшов, ніс внутрішню адресу джерела, яку сервер не зміг пов’язати з цим екземпляром клієнта. Перевірка відбувається перед доставкою, тому тунель виглядає здоровим, хоча нічого корисного через нього не проходить.
Що сервер порівнює перед доставкою
Для кожного пакета, що надходить від клієнта, сервер у просторі користувача дивиться на адресу джерела всередині тунелю й питає свій внутрішній стан маршрутизації, якому клієнтові належить ця адреса. Якщо власником є інший екземпляр або власника немає взагалі, пакет відкидається і видається попередження.
Звичайна доставка через інтерфейс тунелю не відбувається ніколи.
Цей порядок пояснює деталь, яка бентежить людей: лічильники міжмережевого екрана на хості не рухаються, бо пакет так і не дійшов до екрана. Налаштування фільтрації зворотного шляху на хості тут нічого не змінює, оскільки відмова сталася у власній перевірці зіставлення демона. Читайте повідомлення як твердження про власність, а потім з’ясуйте, яка з трьох ситуацій його створила.
Три джерела невідповідної внутрішньої адреси
Клієнт може надсилати з адреси, яка йому не призначена, з мережі, яку ніхто не оголосив його, або з копії особистості, що вже має власника. Усі три дають той самий рядок журналу. Вони різняться тим, що потрібно змінити. Почніть з адреси та поточного списку призначень і дозвольте цим двом фактам вибрати випадок.
Щоб їх розрізнити, потрібні два факти: відкинута адреса в журналі та призначення, які сервер вважає поточними. Другий доступний із подання стану або керування працюючого екземпляра, і це єдиний авторитет, до якого варто звертатися, бо файл конфігурації фіксує наміри, а не поточний стан.
Запишіть обидва, перш ніж щось змінювати, а потім класифікуйте. Знімок екрана, зроблений пізніше, не є записом стану, що спричинив попередження. Збережіть і позначку часу, бо призначення переміщуються між сеансами.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
LAN за клієнтом і iroute
Коли клієнт майданчика маршрутизує свою приватну мережу, ця мережа має бути оголошена як така, що належить клієнтові. Файл, специфічний для клієнта, із записом iroute робить це, а запис називає префікс, який клієнтові дозволено переносити.
Маршрут ядра, що спрямовує той самий префікс у тунель, є окремою вимогою, і його додавання нічого не змінює у внутрішній власності демона.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Переконайтеся, що чинна особистість збігається з назвою файлу, оскільки невідповідність означає, що файл ніколи не завантажується, а симптом ідентичний відсутньому запису. Не додавайте широкий iroute, щоб заглушити попередження, оскільки це перетворює неочікуване джерело на дозволене, не відповідаючи, чому клієнт його надіслав. Посібник OpenVPN 2.6 документує iroute, duplicate-cn і зіставлення особистостей як окремі засоби контролю.
Та сама особистість на двох машинах
Профіль, скопійований на другий ноутбук, несе той самий сертифікат і те саме загальне ім’я. Залежно від налаштувань сервера новіше з’єднання може замінити старіше, і перевірку зіставлення виграє той екземпляр, який володіє власністю.
Через це несправність виглядає періодичною і з’являється лише тоді, коли обидва пристрої активні.
Дозвіл дубльованих загальних імен дає змогу обом підключитися, але не дає їм незалежних статичних адрес чи незалежної власності. Якщо два пристрої мають співіснувати, реєструйте їх окремо, щоб кожен мав власну особистість і власне призначення. Розгляд налаштування дублікатів як виправлення цього попередження залишає загадку на місці й додає другу.
Доведіть, що зіставлення змінилося
Застосуйте виправлення через власника конфігурації, потім повторно підключіть постраждалого клієнта, щоб завантажилася нова політика.
Повторіть той самий потік і підтвердьте три речі: внутрішнє джерело пакета, екземпляр клієнта, з яким сервер його зіставляє, і поведінку призначення після цього.
Якщо попередження припиняється, але застосунок досі не працює, проблема перемістилася, а не зникла. Пересилання, правила міжмережевого екрана і зворотний шлях — це окремі етапи, а проходження перевірки зіставлення означає лише те, що пакетові дозволено залишити тунель.