Повторение запросов mDNS/Bonjour от eth0 через туннель (tun0)

Начнем с того, что я новичок как в сетевых, так и в дистрибутивах Unix/Ubuntu/Linux. Просто предупреждение, для любой установки / кода может выглядеть немного некрасиво.

По сути, моя конечная цель - успешно установить AirPlay Mirror на удаленный сервер Ubuntu с моего iPhone в другой сети Wi-Fi или на LTE.

TL; DR: С mdns-repeater/avahi-daemon и OpenVPN я все еще не могу передать запросы mDNS из eth0 в tun0.

Для начала я знал, что мне нужен приемник AirPlay для ОС на основе Ubuntu/Linux/Unix, которая поддерживает зеркалирование (и, надеюсь, с открытым исходным кодом). Я нашел пару, большинство для Mac OS/Windows, или вообще не поддерживал зеркалирование. После небольшого поиска я обнаружил Slave в Magic Mirror[ссылка 1 ниже], сервер / приемник Linux AirPlay с открытым исходным кодом, который работает и работает (на основе моей отладки, поскольку у меня нет физического доступа к серверу, на котором я его запускал)).

Теперь я знал, что AirPlay работает только по локальной сети (в то время не понимая, как Bonjour работает только в одной подсети), поэтому я рассмотрел некоторые варианты VPN. OpenVPN оказался наиболее гибким и простым в настройке. Чтобы ускорить процесс и гарантировать, что я не совершу никаких ошибок при настройке OpenVPN, я использовал готовый скрипт здесь [Ссылка 2 ниже]. Проверено и работало безупречно, VPN соединяется без утечек DNS и всех маршрутов трафика успешно через VPN.

У меня есть VPN, чтобы работать так, как будто мое устройство сейчас находится в локальной сети моего сервера, и у меня успешно работает Slave в Magic Mirror (сервер AirPlay). Так что это должно просто работать сейчас, верно? Неудивительно, что это не так, поскольку я не понимал, что сервер AirPlay на самом деле отправляет запросы mDNS/Bonjour (или зонды? Реальный термин сейчас ускользает от меня…). Как домашний обычный пользователь, так как эти запросы mDNS имеют нулевое значение (нулевая конфигурация), это удивительно! Но как корпоративному или бизнес-пользователю сложно работать в VLAN.

В результате исследований я пришел к конечному результату, что мне нужна какая-то настройка типа ретранслятора / прокси / моста mDNS. Я закончил с ретранслятором mDNS. Были две программы, которые я пытался использовать.

Avahi-Daemon [ссылка 3 ниже] Avahi, казалось, был самым обсуждаемым и наиболее задокументированным, поэтому я решил использовать это. Я отредактировал файл конфигурации, чтобы разрешить расположение конфигурации /etc/avahi/avahi-daemon.conf

[reflector]
enable-reflector=yes

а также

[server]
allow-point-to-point=yes

Как объяснено здесь [Ссылка 4 ниже] и здесь [Ссылка 5 ниже].

Запуск демона Avahi в режиме отладки (avahi-daemon --debug), на первый взгляд, работает, но как только Slave в Magic Mirror (работает на интерфейсе eth0, OpenVPN работает на интерфейсе tun0), он каким-то образом видит пакеты mDNS но всегда выводит кучу таких:

Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.
Received packet from invalid interface.

Принуждение Avahi использовать только eth0 и tun0, при многих других изменениях и настройках всегда будет выводить это.

Чтобы убедиться, что это была не просто ошибка вывода, я запустил

tcpdump -i eth0 udp port 5353 а также tcpdump -i tun0 udp port 5353 (порт, через который проходят запросы mDNS) eth0 успешно получает пакеты от фильтра, а tun0 не получает ни одного. Так что не ошибка вывода. Я даже попробовал это на порту 7000 (порт, который сервер AirPlay слушает для зеркалирования)

Не имея успеха в Avahi, я подозревал, что это может быть просто потому, что он не обновлялся с 2011 года.

mdns-repeater [Ссылка 6 ниже] Без конфигурационных файлов и настроек, это следующий вариант, который я выбрал. И, кажется, это работает правильно. Запустите MDNS-повторитель с

mdns-repeater eth0 tun0 -f

Просто добавьте интерфейсы, для которых вы хотите повторять запросы, и -f для переднего плана / отладки. Это оно! Я запустил Slave в Magic Mirror, и mdns-ретранслятор успешно обнаружил и повторил запросы (по крайней мере, по его журналам). Но, к сожалению, работает так же tcpdump командами, как видно выше, запросы все еще не проходят через туннель (tun0).

Теперь из своей отладки я могу только заключить, что это является причиной либо iptables/firewall, либо OpenVPN, фильтрующей порты или запросы каким-либо образом. Не найдя ничего в конфигурации, связанной с фильтрацией в OpenVPN, я перешел к своей теории iptables. Но работает iptables -L ничего не приносит, буквально никаких правил нет в iptables.

Зная немного о iptables, я не знаю, является ли это причиной. Для своей собственной отладки я добавил все различные правила iptables, которые я мог найти, связанные с чем угодно, с разрешением mDNS / Bonjour / AirPlay. Кажется, ничто не поможет.

Любая помощь приветствуется! Я знаю, что это было долгое чтение, я не хотел, чтобы какая-то маленькая проблема провалилась.

TL; DR: С mdns-repeater/avahi-daemon и OpenVPN я все еще не могу передать запросы mDNS из eth0 в tun0.

Все ссылки на источники здесь: http://pastebin.com/mVkpZwRY Извинения, мне не хватает репутации для более чем 2 ссылок на данный момент.

1 ответ

Не знаю ответов, но для начала настройки интерфейса не поддерживают трансляцию. Если вы используете кран, они делают. Похоже, что tap используется для соединения в документации OVPN, которую вы можете использовать в конфигурациях, использующих tun. Они будут вести себя почти одинаково, но при настройке ifconfig будут указывать BROADCAST как поддерживаемую опцию.

Другие вопросы по тегам