http://mikrotik.moscow Новое в теме UPnP: поддержка "all-ppp"? форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow] ru http://backend.userland.com/rss2 Sat, 15 Aug 2026 06:25:13 -0400 UPnP: поддержка "all-ppp"? RouterOS в форуме RouterOS.
Спасибо за ответ. Обнадёживает, что есть другие, у которых та же самая проблема – а вот что нет официального подтверждения от разработчиков об этой проблеме и намерений её исправить, это уже не так радует. Заметил твою вики-статью в подписи, и кажется, это идеальный временный обходной путь! Попробую и сообщу о результатах. Спасибо за работу, которую ты проделал!
27.08.2014 11:46:00, fragtion.]]> http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229088 http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229088 Wed, 27 Aug 2014 11:46:00 -0400 RouterOS UPnP: поддержка "all-ppp"? RouterOS в форуме RouterOS.
Ну, идеальное время для редизайна UPnP было бы лет 7-10 назад. Я тоже бешусь на латышских ребят из-за этого, но, наверное, опытных разработчиков не так уж и много, и они точно не будут отдавать приоритет работе над такими глупыми функциями. UPnP Scripting можно использовать, чтобы "динамически" добавлять что-то в конфигурацию по мере необходимости.
17.05.2014 09:49:00, NetworkPro.]]> http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229087 http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229087 Sat, 17 May 2014 09:49:00 -0400 RouterOS UPnP: поддержка "all-ppp"? RouterOS в форуме RouterOS.
Приветствую, разработчиков и пользователей Mikrotik! Я использую RouterOS в основе своей сети, потому что, как мне кажется, это самая интуитивно понятная и эффективная платформа для маршрутизаторов, которую я нашел. Она позволяет мне лучше контролировать ситуацию, учитывая мои ограниченные знания, особенно в моем случае, где у меня настроена dual-wan PPPoE-подключение (разделение маршрутов, а не агрегация) и требуется маркировка соединений и пакетов, чтобы правильно обрабатывать трафик входящий и исходящий из локальной сети.

Итак, прежде всего, хочу выразить благодарность за создание такого замечательного продукта. Одно из больших улучшений, которое я заметил с версии 6.x RouterOS, заключается в том, что во многих местах мы теперь можем выбрать "all-ppp" в случаях, когда хотим применить правило ко всем PPPoE-интерфейсам без дублирования правил для каждого из них. Это чрезвычайно полезно, особенно при создании правил NAT в брандмауэре, и кажется совершенно безопасным, если знать, что делаешь.

Однако, серьезным недостатком, с которым я недавно столкнулся, является отсутствие такой поддержки в реализации UPnP в RouterOS (на самом деле, это, похоже, общее ограничение UPnP, которое никто никогда не пытался исправить). Проблема в том, что UPnP, похоже, работает только для одного WAN/внешнего интерфейса, хотя формально можно добавить несколько внешних интерфейсов к экземпляру UPnP через ip->upnp в WinBox/терминале. Можно даже указать 0.0.0.0 в качестве внешнего IP-адреса, и правило будет создано именно так… однако оно не привязывается ко всем PPPoE-интерфейсам и просто не работает так, как ожидается. На самом деле, кажется совершенно бесполезным, что можно добавить несколько внешних интерфейсов к экземпляру UPnP, если добавление их на самом деле не оказывает никакого эффекта.

Если поддержка multi-wan не планируется, то, возможно, нам следует выводить предупреждение об ошибке вместо того, чтобы позволять их назначать. Возможно, есть проблеск надежды в отношении этого в pfSense, но это, конечно, не решит проблему для пользователей Mikrotik. Может ли Mikrotik теперь стать явным исключением и выйти на передовые позиции в этом вопросе?

С ростом p2p и появлением современных приложений, таких как Skype, на все большем количестве мобильных устройств, таких как телефоны и планшеты, ручная поддержка переадресации портов для этих типов приложений становится очень трудоемкой и непрактичной, поскольку MAC-адреса устройств часто меняются, а на полупубличных сетях могут появляться новые устройства постоянно, и поддержание ручных правил становится невозможным! UPnP был создан в качестве идеального решения для этого, но он никогда не развивался и теперь сильно ограничен тем, что до сих пор поддерживает только один WAN.

Поскольку UPnP, по сути, только сообщает сети о своем присутствии и ожидает запросов приложения для открытия порта, а затем настраивает временное правило для этого, можно было бы ожидать, что будет относительно легко изменить тип создаваемого правила в какой-то степени, отличной от текущей. В настоящее время создается правило dst-nat, по dst-адресу IP и не привязывается к интерфейсу, и, похоже, нет способа изменить это поведение.

Кроме того, отсутствует контроль над тем, где будут появляться эти динамические правила dst-nat в таблице брандмауэра… В моем случае они попадают под правило DMZ и, следовательно, игнорируются, если я не отключу правило DMZ. Есть ли какой-либо способ сделать так, чтобы правила UPnP имели приоритет над правилом DMZ? Мне хотелось бы иметь правило DMZ только как последнее средство после рассмотрения других переадресаций портов, и я не могу найти способ сделать это в RouterOS?

В поисках я наткнулся на несколько похожих постов на этих форумах, где пользователи просят помощи с multi-wan upnp, и никто не нашел решения. В связи с текущими изменениями PPP для v6.8/6.9, не было бы ли это идеальное время, чтобы немного освежить UPnP и привести его в 21-й век, что сделает его гораздо более привлекательным и полезным для приложений динамической переадресации портов, которые сейчас появляются чаще, чем когда-либо?
07.01.2014 10:46:00, fragtion.]]> http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229086 http://mikrotik.moscow/forum/forum57/60174-upnp_-podderzhka-_all_ppp_/message229086 Tue, 07 Jan 2014 10:46:00 -0500 RouterOS