Повторение mDNS/Bonjour запрашивает от eth0 до туннеля (tun0)

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

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

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

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

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

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

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

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

[reflector]
enable-reflector=yes

и

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

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

Выполнение Демона Avahi в режиме отладки (avahi-демон - отладка), казалось, работало на первый взгляд, но как только Ведомое устройство в Волшебном Зеркале (работающий 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-повторитель [Связывает 6 ниже] Без файлов конфигурации или устанавливает необходимый, это - следующий вариант, который я выбрал. И кажется, что это работает правильно. Выполненный mdns-повторитель с

mdns-repeater eth0 tun0 -f

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

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

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

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

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

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

4
задан 2 August 2015 в 02:07
1 ответ

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

1
ответ дан 3 December 2019 в 04:09

Теги

Похожие вопросы