Ponywka

Окей, чуть подразобрался и похоже всё-таки придется поддержать хук "netfilter.d", ибо (как я понял) подобное есть и на OpenWRT: https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmnetfilterd

Немного поизучав исходники оригинального kvas обнаружил, что там это исправляется с помощью хука "netfilter.d": https://github.com/qzeleza/kvas/blob/3fdbbd1ace7b57b11bf88d8db3882d94a1d6e01c/opt/etc/ndm/netfilter.d/100-vpn-mark Опять же - печально, ибо я хочу по минимуму привязываться к связке "KeeneticOS + Entware" в своём проекте

Кто-нибудь знает почему правила в "iptables" пропадают? Запускаю скрипты - он заполняют "iptables". Делаю "iptables-save" - всё ок: ~ # iptables-save | grep "KVAS2" :KVAS2_ROUTING_1_POSTROUTING - [0:0] -A POSTROUTING -j KVAS2_ROUTING_1_POSTROUTING -A KVAS2_ROUTING_1_POSTROUTING -o nwg1 -j MASQUERADE :KVAS2_ROUTING_1 - [0:0] -A PREROUTING -m set --match-set kvas2_1 dst -j KVAS2_ROUTING_1 -A OUTPUT -m set --match-set kvas2_1 dst -j KVAS2_ROUTING_1 -A KVAS2_ROUTING_1 -m set ! --match-set kvas2_1 dst -j RETURN -A KVAS2_ROUTING_1 -j CONNMARK --restore-mark --nfmask 0xffffffff --ctmask 0xffffffff -A KVAS2_ROUTING_1 -m mark --mark 0x1 -j RETURN -A KVAS2_ROUTING_1 -m conntrack --ctstate NEW -j MARK --set-xmark 0x1/0xffffffff -A KVAS2_ROUTING_1 -j CONNMARK --save-mark --nfmask 0xffffffff --ctmask 0xffffffff Но стоит буквально самую малость подождать (например воспользоваться созданными правилами / потупить пару минут) и получаю следующее: ~ # iptables-save | grep "KVAS2" :KVAS2_ROUTING_1_POSTROUTING - [0:0] -A POSTROUTING -j KVAS2_ROUTING_1_POSTROUTING -A KVAS2_ROUTING_1_POSTROUTING -o nwg1 -j MASQUERADE Куда-то пропадает вся цепочка "KVAS2_ROUTING_1". Отдебажил свой код на всякий - он ничего не трогает. Мистика какая-то... Предполагаю, что сам NDM подтирает "iptables", однако ревёрсить бинарники не особо-то и хочется, чтобы найти виновника. Код для проверки: CHAIN_PREFIX=KVAS2_ ROUTING_ID=1 IPSET_TABLE=kvas2_1 MARK=1 INTERFACE=nwg1 ipset create ${IPSET_TABLE} hash:ip iptables -t nat -N ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING -o ${INTERFACE} -j MASQUERADE iptables -t nat -A POSTROUTING -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t mangle -N ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m set ! --match-set ${IPSET_TABLE} dst -j RETURN iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -j CONNMARK --restore-mark iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m mark --mark ${MARK} -j RETURN iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -m conntrack --ctstate NEW -j MARK --set-mark ${MARK} iptables -t mangle -A ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} -j CONNMARK --save-mark iptables -t mangle -A PREROUTING -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -A OUTPUT -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} # # --- Откат изменений --- # ipset destroy ${IPSET_TABLE} iptables -t nat -D POSTROUTING -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -F ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t nat -X ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}_POSTROUTING iptables -t mangle -D PREROUTING -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -D OUTPUT -m set --match-set ${IPSET_TABLE} dst -j ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -F ${CHAIN_PREFIX}ROUTING_${ROUTING_ID} iptables -t mangle -X ${CHAIN_PREFIX}ROUTING_${ROUTING_ID}

Здраствуйте! Использую KeeneticOS 4.2 Beta 2 на мониторе 2K разрешением (а у друзей вариант с 4K разрешением) и меня огорчает то, что интерфейс ограничили 1920px по ширине, хотя ранее таких ограничений не было и интерфейс растягивался на всю ширину (в моём случае 2560px). Планируется ли исправление ширины в будущем?

Делюсь опытом при переходе с Iskratel RT-GM-3 (Ростелеком, Воронежская область, г. Лиски): Настройки SFP-стика: Сам стик: DFP-34X-2C3 (как DFP-34X-2C2, только с зелёным разъемом без переходника) Прошивка: https://github.com/Anime4000/RTL960x/blob/main/Firmware/DFP-34X-2C2/M110_sfp_ODI_210702.tar Admin -> GPON Settings: Serial Number: ISKT0123ABCD (ISKT + из роутера последние 8 знаков 49534B540123ABCD) PLOAM Password: 0000000000 (там действительно такой пароль на моём роутере был) LOID: user (без него не даёт сохранить) Admin -> OCMI Information: OMCI Vendor ID: ISKT (*скорее всего не обязательно) WAN -> PON WAN: VLAN ID: 10 Connection Type: INTERNET Не забываем про Admin -> Commit/Reboot -> Commit and Reboot С такими настройками в Status -> PON -> ONU State получил O5 (Initial Status) На роутере: IPv4 Settings: IPv4 configuration: Automatic (DHCP) ISP Authentication: Type (protocol): PPPoE Username: abcdef01@vrn (см. в настройках роутера или звоните провайдеру, представленный - лишь пример) Password: Звоните провайдеру (88001000800), просите робота соеденить с оператором и просите у него "PPPoE пароль". Выдернутое из роутера "@&~*#()<>****@&^%*!####" - не пароль, Мне прислали 8-ми значный пароль вместо этого "нечто". Возможно потребуется после настроек перезагрузить питание роутера (перезапустить как и сам стик, так и роутер)

Отключи компонент "Фильтрация контента и блокировка рекламы при помощи облачных сервисов" ("Cloud-based content filtering and ad blocking")

Ага... Я вот купил второй Keenetic Giga (родствевнникам; из-за наличия SFP порта и желания иметь один висячий "коробок" вместо двух), ибо взял отпуск и планировал отвезти родственникам его. Только-только настроил WG как мост между двумя роутерами, а его на следующий день начали блочить 🤬

Ну, как вариант кстати 😕

Я имел ввиду про софт, который я пишу, который использует iptables и работает с UNIX'овыми названиями интерфейсов, но который запущен на роутерах Keenetic.

Хм... Ну с этой точки зрения конечно верно... Просто хотелось бы, если не иметь возможность встраивать какие-то настройки во внутрь самой веб-морды Keenetic, то хотя-бы иметь возможность дёргать с самого Keenetic какие-то данные (например тот же человеко-читаемое название интерфейса, добавленное из интерфейса самого Keenetic) и рисовать уже свой интерфейс на каком-то порту (что я и хочу сделать) Перезапускать все интерфейсы я ну очень не хочу, ибо это долгий процесс. В таком случае уж лучше просто вывести UNIX'овое имя интерфейса, а пользователь пускай сам разбирается. Вообще та штука, которую я хочу сделать реализовывается и через CLI Keenetic'а, однако это засрёт таблицу маршрутов на самом роутере, чего я делать тоже не очень хочу, ибо отслеживать изменения оттуда ещё сложнее, породит ещё больше костылей, а также будет медленно выполняться. iptables+ipset как-то быстрее с этой задачей справятся.

Здраствуйте! Разрабатываю демона по типу kvas и хочу в модальном окне выбора интерфейса выводить вместо какого-нибудь UNIX'ового названия "nwg0" или же "ovpn_br0" выводить человеко-читаемое название интерфейса по типу "WireGuard [Home] (nwg0)". К сожалению из запроса `GET http://192.168.1.1/rci/show/interface/Wireguard1` имею лишь такую структуру, где нет ни слова о UNIX'овом названии интерфейса: { "id": "Wireguard1", "index": 1, "interface-name": "Wireguard1", "type": "Wireguard", "description": "Home", "traits": [ "Ip", "Ip6", "Wireguard" ], "link": "down", "connected": "no", "state": "down", "mtu": 1324, "tx-queue-length": 50, "global": false, "security-level": "public", "ipv6": {}, "wireguard": {}, "summary": { "layer": { "conf": "disabled", "link": "disabled", "ipv4": "disabled", "ipv6": "disabled", "ctrl": "disabled" } } } Видел, что kvas решает эту проблему использованием хука iflayerchanged и перезапуском всех интерфейсов, что считаю это решение не очень то и хорошим, ибо подобная информация как по мне должна быть как и в CLI Keenetic (Telnet), так и в REST API (а по возможности, кстати, хотелось бы иметь документацию по REST API, ибо её нигде не нашел). Где можно достать UNIX имя интерфейса без использования подобных костылей (из-за текущих ограничений Keenetic'а)?