Багофича в OpenWRT, связанная с NAT
Наткнулся на неприятную багофичу в последних версиях OpenWRT. Внешне проявляется она в том, что если на коробке терминируется больше одного IPSec-тоннеля, то какие-то из них начинают работать нестабильно: не подиматься автоматически после обрыва, несвоевременно проводить rekey, подниматься только по пинку с одной из сторон и т.п. Не мог понять в ( Read more... )
Comments 13
У кого-нибудь получилось на роутере с openwrt реализовать автоматические апдейты самой ОС и всех её пакетов, чтобы всё стабильно работало годами без участия админа, чтобы все конфиги не ломались при апдейтах?
Или для таких вещей надо перейти с openwrt на OPNsense?
Reply
Во-первых, вопрос "зачем". Если всё устраивает, новый функционал не требуется, критических багов класса "Remote Code Execution" и иже с ними не находят, то зачем обновляться? Сам по себе OpenWRT без "навесок" - это настолько простой "кипятильник", что там просто нечего ломать. Разве что DropBear и Luci, но дык не открывай их внаружу, да и всё.
Во-вторых, говоря о "конфигах", то конфиги от чего именно? Linux это жы ж конструктор из десятков-сотен разных приложений. И никто не сможет гарантировать что ни одна софтина из этого набора не перейдёт на другой синтаксис конфига к следующей версии. Даже всякие Cisco и Juniper-ы, являясь "монолитными кирпичами" не могут такого гарантировать. Нет-нет, а временами таки возникает несовместимость конфига при очередном обновлении прошивки.
В-третьих, единственный раз на моей памяти когда в OpenWRT прям серьезно-серьезно что-то ломалось, это переход через версию 21.02, в которой разработчики поменяли сетевой Framework. В остальных случаях оно более-менее нормально подхватывало старые настройки.
В- ( ... )
Reply
> говоря о "конфигах", то конфиги от чего именно?
Да от всего, что коммитится через uci commit. И прочие файлы и скрипты из /etc, /root. К сожалению, тут с новым апдейтом что-то может упасть. Да тот же bird, насколько я помню, в какой-то новой версии резко начал требовать новый формат конфиг-файла.
> что ни одна софтина из этого набора не перейдёт на другой синтаксис конфига к следующей версии
Так для этого, по идее, придумали NixOS, nix, GNU Guix System, ansible, также uci в openwrt. Но я не смог придумать, как это всё использовать.
> Нет-нет, а временами таки возникает несовместимость конфига при очередном обновлении прошивки
Я слышал, что люди на ноутбуке настраивали NixOS на авто-апдейты и потом годами ничего не меняли, всё работало. Надо только было периодически перезагружать ноутбуки, вручную, раз в недельку, например.
Reply
Какие там нафиг RCE для решения, единственная задача которого цеплять Wi-Fi клиентов и перекидывать пакетики с интерфейса на интрерфейс? А если хочется на него навесить что-то сверх того, ну дык "жираф большой", сам должен понимать что творит.
Что касается перечисленных инструментов... ну да, они решают проблему X, но при этом добавляют новых проблем Y, Z, A, B, C. И потом, не надо забывать, что изначально OpenWRT создавался под устройства с лютым дефицитом CPU / RAM / HDD, да и архитектура у них немного не x86_64.
А если речь идет не про embedded-устройства, дык зачем тогда вообще связываться с OpenWRT, когда есть куча других вариантов?
Reply
> Поэтому приходится инкостылировать.
Хм. "Инкостыляция и фалломорфизм"?
Reply
Три принципа костыльно-ориентированного программирования: костылирование, инкостыляция, поликостылизм.
Reply
Leave a comment