KorDen

После одного из обновлений этак с месяц назад у меня на Ultra II (сейчас 2.09.A.4.0-1) упал Unbound и больше не поднимался... Первоначально грешил на глючную флешку, сейчас руки дошли переставить на другую.. Имеем чистую установку Entware-3x, установлены mc и unbound. Конфиг unbound - дефолтный, только порт заменен (чтобы dns-override не прописывать на время тестирования), отключен DNSSEC и поправлены пути. С моим конфигом, с которым работало до этого год картина аналогична На Giga II (2.08) с Entware-Keenetic нормально стартует с этим же конфигом. Наверняка что-то не то в -3x, но что, куда копать?

http://www.sipro.com/G729.html Очень жду! Наконец-то можно будет полностью уйти от цифра-аналог-цифра (SIP-шлюз -> DECT-база), истории очень не хватает.

Нужно использовать туннели (например IPIP) поверх IPsec, голым IPsec это не получится, IPsec-туннели нельзя маршрутизировать. В простейшем режиме можно два автоматических туннеля (по одному серверу на каждой ультре, клиенты на средней ультре и 4g), либо полностью ручной режим, т.е. создавать транспорты и затем уже IPIP-туннели. PS: у меня несколько похожая ситуация (но чуть заморочнее), было вот тут:

Неужели пришел и на нашу улицу праздник...?

@r13, да, автоматический сервер только один

Ручное управление с нюансами :\ Лично у меня от текущего варианта CLI Guide уже в голове появляется каша без примеров (которых в гайде толком и нет), а с нюансами типа "синтаксис не работает так, как ожидается" и совсем путаница. Надо все-таки что-то с этим делать... Еще до кучи к этому всему напрягает проблема невозможности применения правил фаервола для транслируемых портов. Еще бы выводить в WEB что-то типа "внимание, текущая конфигурация может быть несовместима с настройкой через Web-интерфейс"

Правила действительно пропали из Web-интерфейса, но в CLI они отображаются и работают, иначе бы я узнал об этом несколько часов назад. на данный момент у меня пока только ip nat udp-port-preserve ip nat vpn ip static Home ISP ip static Guest ISP И кучка правил типа ip static tcp ISP 12345 192.168.1.50 !service Кстати говоря, udp-port-preserve будет работать в такой конфигурации же как и раньше?

Вообще, обычно 66 - адрес сервера, 67 - имя файла. ----------------------- Возможно ли передать индивидуальные опции одному клиенту (по маку) или группе клиентов (по диапазону IP/списку маков)? Или пока только костылем в виде отдельного пула на один (несколько) IP и ip dhcp host для всех хостов в этом пуле (чтобы IP из пула не прилетели случайному клиенту)? Edit: Стоп, из CLI Manual: "В текущей версии системы реализована поддержка не более одного пула на интерфейс" (ну и там же "Можно создать не больше 32 пулов") - это актуально?

Нет описания ip nat udp-port-preserve, по крайней мере для Ultra II

А если прилетит на открытый порт? Например: 192.168.2.1/24 - маршрутизируется через туннель, со стороны ISP разрешен доступ, скажем, к порту udp/12345, из-за неполадок у ISP дефолтный маршрут через LTE, прилетает пакет со 192.168.2.3 со стороны ISP на myip:12345 - не уйдет ли вдруг на LTE с моим же внешним IP ISP или через Nat Loopback прилетит на сервис на 12345, но с IP роутера, а не с реальным? Понятно, что ответ никуда не уйдет..

Еще вопрос: Если к примеру есть домашняя сеть 192.168.0.1/24, гостевая (.1.1/24), и два туннеля (за ними .2.1/24 и .3.1/24) (выход через ISP и резерв на LTE) - правильно ли понимаю, что вместо описывания "матрицы интерфейсов" можно сделать что-то вроде: ip static 192.168.0.0/22 ISP ip static 192.168.0.0/22 UsbLte0 Или в таком виде могут быть скрытые сюрпризы, если например со стороны ISP вдруг прилетит пакет с IP из этого диапазона?

@Le ecureuil, для клиентов PPTP-сервера (при 'ip nat vpn') как пойдут пакеты в случае перехода на статику?

YAY! 2.09.A.4.0-1:

Поскольку мое предложение затерялось в теме о туннелях, решил вынести отдельно. На данный момент настройка ручного транспорта IPsec для туннеля, если делать основную настройку IPsec через веб (чтобы не запутаться во всех этих map/policy/profile/transform-set), приходится вначале указывать фиктивный IP, а затем через cli править access-list для транспорта, делая permit ipip (gre/eoip) вместо permit ip - если сделать сразу правильные IP можно потерять доступ к удаленному роутеру. Соответственно, и обновление параметров IPsec через веб требует обратной смены IP на фиктивный с последующим обновлением access-list вручную. Предлагаю сделать при выборе транспортого режима галки навроде: Если галки не стоят - то делается permit ip.

Использовал ранее 6to4, одна из фич - доступ к заблокированным ресурсам, которые доступны по v6, без всяких проксей-впн-etc. От идеи пришлось отказаться, поскольку в какой-то момент 192.88.99.1 вместо пинга в 50 стал с пингом 100+ и все начало заметно тормозить. А так остальные фичи v6 (исходящие из "всем по беляку") сильно ограничиваются распространенностью v6 У меня так RB750Gr3 (который на MT7621A) лежит - поигрался и забросил, WiFi нет, SFP нет, плюсы только в очень шустром IPsec Ultra II<->RB750Gr3, но пока достаточно и сотки (Giga II)

Я бы попробовал ответить на этот вопрос, но в моем случае мысль выливается в комплексную идею расширения поддержки IPv6, что пока все еще малоактуально. Сейчас устройства берут адреса хаотично - кто на основе мака, кто просто случайный, что не позволяет нормально управлять сетью в том виде, к которому уже давно привыкли в v4. Но мало раздавать адреса - нужно иметь еще и возможности по использованию этого - в частности, настройку фаервола и так далее. В v4 к примеру, можно иметь привычку настраивать 1 - роутер, 2-99 - постоянные домашние устройства (компьютеры-ноуты-плееры, для которых забит постоянный IP), 100-199 - общий DHCP-пул, 200-254 - служебные устройства (свичи-камеры-утюги). Если эти диапазоны распределить грамотнее (скажем, 1-64, 64-128, 128-192, 192-254) и если такая идеология например поддерживается в нескольких сетях, которые связаны всевозможными туннелями - можно гибко строить правила доступа и маршрутизации. Если задаться целью перехода на v6, то сохранение такой идеологии логично (особенно чтобы не светить все подряд в интернет), но тут мы наталкиваемся на скудную поддержку v6. И я не виню Zyxel в этом - все трубят о v6 уже лет 6 (), а воз и ныне там...

Первая мысль была что это регулярка или brainfuck Но у самого реакция "пересобирать мир на кинетике уже можно, осталось запилить чертей с пересборкой ядра и компиляцией из портов прямо на роутере". Правда, из-за chroot в моей конфигурации приходится так и оставаться на Entware

Я бы все же хотел иметь возможность сделать что-то вроде "ip nat from Home to ISP" с возможностью сделать условно "ip nat from all to ISP" или "ip nat from Guest to all" (запахло IPFW ) Пока же проще, если на каком-то интерфейсе динамический IP, скриптом добавлять ip static для нынешнего IP

В свете моей попытки собрать общие параметры воедино, хотелось бы уточнить про RT63368 - правильно ли я понимаю, что EIP93 в нем есть? (2.08+) (и на LTE можно получить схожие с Giga II результаты?)

Это уже какой-то NanoStation, и надо тогда уж реквестировать PoE в кинетик. Причем по мотивам K.Plus DSL это должна быть мегакомба "802.3af/at + надцать вариантов пассивного 100/1000 (фантом/не фантом) с настройкой полярности и напряжения per-port". Ой, кажется это уже не про домашний роутер. Хотя, кто отменял дома наличие тех же IP-камер?

Сигнал от адаптера явно слабее будет, чем от полноценной ТД в роутере. А вот режим клиента через адаптер был бы кстати IMO, чтобы например поставить роутер поближе к центру квартиры и повесить на свободный канал, а ловить резервный WiFi-аплинк через USB-адаптер на окне. Тогда уж и поддержку USB-Ethernet нужно, об этом уже как-то говорили

Чего? [2] Еще раз, dns-override убирает штатный DNS-прокси с 53 порта когда вставлена флешка, на которую ссылается OPKG, и только. Никаких других эффектов вроде неработающего DHCP или проблем с работой штатного функционала прошивки я не замечал и как-то специально не настраивал.

Чего? dns-override только освобождает 53 порт когда примонтирован opt, резолвер продолжает работать для RPC. У меня так Unbound (с DNSSEC) стоит уже год, и ничего. Если флешка выткнута - на 53 порт возвращается системный. В консоль ЦА можно и не лазить, есть ndmq же

Зачем проброс, не проще сделать 'opkg dns-override' в консоли? Тем более тогда при вытащенной флешке будет работать напрямую.

@JIABP, настраивайте PPTP-сервер/клиент, или попараноидальнее IPIP поверх IPSec (прямиком из шапки), дальше делаете соединение ip global 1000 и у вас резервирование интернета, т.е. трафик ходит через сервер до тех пор пока соединен с ним. Можно убрать галку доступа в инет с основного подключения и добавить ручной маршрут до сервера через основного ISP, тогда при падении туннеля интернета не будет совсем.