Клиенты 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, когда важна доступность внутри одной подсети.