Клієнти OpenVPN не бачать одне одного: підмережа чи net30?
Клієнти доходять до сервера, але не одне до одного. Розділіть несправність одним ping, потім виберіть топологію підмережі, client-to-client або сегмент TAP у мості.
Дві незв'язані несправності дають ту саму скаргу. У першій один клієнт не доходить до іншого навіть за адресою тунелю, бо адреси не в одній підмережі або сервер не пересилає трафік між учасниками. У другій ping працює, а список пристроїв у застосунку лишається порожнім, бо виявлення спирається на широкомовлення, яке тунель 3-го рівня нести не може. Один ping розділяє їх, і виправлення кожного зовсім не схоже на виправлення іншого.
Один ping ділить проблему на дві
З одного клієнта пропінгуйте адресу тунелю іншого клієнта, а не його ім'я і не його адресу в LAN. Якщо це не вдається, проблема в пересиланні або адресації, і виявлення не має значення, доки це не виправлено. Якщо вдається, пересилання вже працює, а те, чого бракує, — широкомовлення або розв'язання імен.
ip addr show tun0Насамперед прочитайте інтерфейс клієнта, бо маска мережі називає топологію. /24 або інша маска підмережі означає спільний пул; /30 з адресою партнера означає стару схему точка-точка, де кожен клієнт має рівно одного сусіда — сервер.
net30 проти підмережі, прочитано з боку клієнта
| What you observe | net30 | subnet |
|---|---|---|
| Client netmask | /30 with a peer address | The pool's own mask |
| Peers a client can address directly | One, the server | Every client in the pool |
| Addressing | One /30 block per client, with the server as the only peer | One pool mask shared by all clients |
| Effect of client-to-client | Required for any peer traffic | Required for peer traffic, still no broadcast |
За net30 сервер видає невеликий блок на клієнта, тож маршруту до адреси тунелю іншого клієнта немає, якщо сервер його не перешле. За підмережі весь пул — одна мережа, кожен клієнт може звернутися до будь-якого іншого, і сервер пересилає між ними. Тому одна конфігурація сервера може виглядати здоровою, доки ping між учасниками не проходить: нічого не зламано, клієнти просто не в одній мережі. Клієнт бачить робоче з'єднання й адресу учасника, яка не відповідає, що читається як міжмережевий екран, але насправді це схема адресації.
Перемикання директиви — це правка на боці сервера плюс перезапуск, і вона діє для наступного підключення, а не для вже відкритих сеансів. Перепідключіть клієнтів, перш ніж оцінювати зміну. Якщо пристрій заново генерує конфігурацію з веб-інтерфейсу, запишіть директиву, файл і дату, і вносьте правку через інтерфейс, коли він є, бо перезбирання перезапише ручну правку під час наступного збереження.
client-to-client — окремі ворота
Навіть у межах однієї підмережі сервер відкидає пакети, які приходять від одного клієнта й адресовані іншому, якщо не задано client-to-client. Це ключове слово робить сервер пересилачем трафіку між учасниками, а не кінцевою точкою, яка лише його приймає. Це друга умова, яку люди пропускають після виправлення топології.
Це не поширюється на широкомовлення. Налаштування пересилає одноадресний трафік між клієнтами; воно не робить тунель спільним сегментом, і жодна його кількість не доставить запит виявлення багатоадресної розсилки кожному учаснику.
TUN проти TAP, і що кожен може нести
| Property | TUN | TAP |
|---|---|---|
| Layer | Layer 3, IP packets | Layer 2, Ethernet frames |
| Broadcast and multicast | Not carried | Carried |
| Bridging to the LAN | Not applicable | Required for a shared segment |
| Client platform support | Everywhere | Missing on Android and iOS, limited on macOS |
Мостіння tap-пристрою в LAN поміщає віддалених клієнтів у широкомовний домен офісу, що повністю вирішує виявлення. Ціна — платформи, які не реалізують TAP, міст, який має існувати на сервері, і домен відмови, де широкомовний шторм на офісному кабелі сягає кожного віддаленого ноутбука.
Для двох-трьох робочих станцій, яким потрібне розв'язання імен, запис у hosts або одноадресна адреса значно дешевші за міст. Беріться за TAP, коли протокол, який ви не можете замінити, залежить від виявлення на 2-му рівні, і не раніше.
Клієнти однієї підмережі без моста
Видача адреси з діапазону LAN не ставить клієнта на кабель. Сервер маршрутизує між тунелем і Ethernet, тому ARP для цієї адреси зупиняється на інтерфейсі сервера, і решта LAN так і не дізнається, де він живе.
ip neigh add proxy 10.50.1.250 dev eth0Proxy ARP закриває цю прогалину: сервер відповідає від імені клієнта. Для діапазону parpd керує записами в міру приходу й виходу клієнтів, а sysctl net.ipv4.conf.eth0.proxy_arp=1 відповідає за все, що маршрутизується в інше місце, і цього достатньо широко, щоб створити власні несподіванки на жвавому сегменті.
Який би шлях ви не обрали, приберіть NAT між тунелем і кабелем. Правило MASQUERADE приховує саме те питання адресації, на яке ви намагаєтеся відповісти. Воно також залишає наступній людині топологію, про яку вона не зможе міркувати з боку клієнта.
Перш ніж щось змінити, перехопіть одну спробу на сервері з tcpdump -ni tun0 і підтвердьте, чи пакет учасника взагалі приходить. Приходить і відкидається — це вказує на client-to-client; ніколи не приходить — на топологію або маршрутизацію. Посібник OpenVPN 2.6 описує обидва ключові слова й типову топологію, і це варто звірити зі своєю версією, перш ніж копіювати рядок із повідомлення на форумі.
- Інтерфейс tun показує маску пулу, а не пару учасників /30.
- Прямий ping на іншу адресу тунелю проходить до перевірки виявлення.
- Конфігурація сервера містить
client-to-clientщоразу, коли учасники мають обмінюватися пакетами. - Назвіть протокол виявлення, який ви перевіряєте, замість того щоб казати, що застосунок не працює.
- Використовуйте TAP лише якщо його підтримує кожна клієнтська платформа в групі.
- Тримайте NAT поза шляхом між тунелем і LAN, коли важлива доступність у межах однієї підмережі.