Zyxel и туннели, часть 2

В очередной раз появилось немного свободного времени, да и поддержка zyxel активизировалась, так что, я решил добить, или хотя бы, попытаться добить тему туннелей и решить проблемы, которые с ними остались. Проблем было две: неудовлетворительное качество работы IPIP/GRE туннелей в простых задачах ftp/smb и… некоторые сложности в пробросе multicast трафика. Т.е. туннели не работали совсем, либо работали плохо. Первая проблема пока не решена, решение второй я попытаюсь изложить ниже.

Итак, некоторое время назад у меня случилось новоселье и старая квартира с двумя 100 mbit каналами, импровизированной серверной и очень хорошим провайдером IP телевидения перестала быть для меня основной площадкой. Контроль над площадкой не потерян — там сейчас живут родители, да и счета за электричество и интернет/телевизор я оплачиваю, но, как уже упоминалось выше, теперь основной стала другая площадка. С более высокими потолками, большей площади и с лучшим ремонтом, но с каналами 70 mbit и 15 mbit и без IPTV вообще. Собственно, туннели от того и решено было пробрасывать.

Начал я опыты с оборудованием Zyxel на NDMS 2.08 и IPIP туннели работали быстро и стабильно, но на версии 2.09 я не могу через туннель передать файл размером несколько сотен мегабайт, в то время как через интернет (т.е. не по серому туннелю, а через белый адрес FTP или SMB сервера) могу. Возможно, что-то изменилось у провайдера, возможно я сам что-то наделал, возможно что-то изменилось в NDMS, это выяснить пока не удалось. А вот телевизор стал для IPIP задачей нерешаемой. Ну не умеет IPIP мультикаст трафик, зато умеет GRE.

Туннель GRE был поднят легко и просто, файлики летали между сетями так же как и по IPIP, но мультикаст трафик ходить отказывался. IGMP PROXY проблему не решал, а использовать UDPROXY не хотелось, ибо хотелось использовать приставки провайдера, т.е. сделать всё прозрачно. Поддержка общалась со мной долго и в общем вежливо, с пониманием, но конкретных решений не предлагалось. Под конкретными решениями я имею в виду инструкции, а не общие фразы типа «А не попробовать ли Вам EoIP?».

Блин, я хочу сохранить формально разные серые сети, ходить между этими сетями на шары и смотреть телевизор (портал в 3 статических правила и мультикаст), а мне предлагают EoIP. Когда общение с поддержкой было прекращено, а телевизор всё же смотреть хотелось, я начал искать такой вариант использования EoIP, который позволил бы не объединять серые сети, использовать два независимых DHCP сервера и вообще, мало чем бы отличался от GRE/IPIP для всех, кроме телевизора.

Решение в общих чертах такое:
1. Строим на конкретном порту «клиентского» роутера новый Бридж (и новый vlan), предварительно выведя этот порт из Home.
2. Поднимаем EoIP туннель без адресов и на «клиентском» и на «серверном» роутере.
3. Бриджуем EoIP на «серверном» роутере с интерфейсом Home и на «клиентском» с интерфейсом нового vlan.

То же самое в картинках:

 

 

 
 

 

 
 
Важные на мой взгляд элементы я выделил красным, белые адреса своих хостов замазал.

После такой настройки приставки вполне себе получают адреса от «удалённого» DHCP и показывают контент с «удалённого» сервера. GRE туннель при этом работает параллельно.

У этого решения есть минусы:

1. На компьютере в программном клиенте или в VLC телевизор не посмотреть.
2. У роутера «потерялся» один порт.
3. Все же пришлось строить два туннеля: «для файлов» и «для телевизора».

Конечно, есть соблазн «склеить» домашние сети совсем, но шанс получить падение канала или отключение основной площадки вполне реален, и тогда на удалённой не будет даже dhcp. Конечно, можно разделить склеенную сеть на сегменты, поднять два dhcp сервера и при этом гонять по туннелю только широковещательный трафик, но делать это дома и на железе домашнего уровня как-то не хочется. Так что, будет два туннеля.

Кстати, маршрутизаторы уровня Keenetik Lite III rev. B вполне справляются с мультикастом на 3-4 телевизора с приличным потоком не смотря на «программный NAT». Систему нужно еще понагружать, но не совсем понятно как объективно реакцию на нагрузку мониторить.