KorDen

Если вам нужно просто доступ в удаленную локалку, то настраивайте просто IPIP, например: А если вам нужен единый broadcast-сегмент, то настраивать EoIP туннель из примера в шапке и добавлять в бридж. Только придется поправить MTU

Ну, техникой Apple я не пользовался, но всевозможные нокии и девайсы на Symbian и Android считают такой вызов принятым. Самсунги-звонилки не помню, но вроде тоже принятым. По крайней мере однозначно нелогично выводить уведомление о новом пропущенном, если на это возможно повлиять.

@des S850HX, Giga II @ 2.09.A.5.0-0. Сброшенный (красной кнопкой на трубке) вызов считается пропущенным, а не принятым - КМК не совсем логично, на всех мобильниках всегда сброшенный является принятым. Предлагаю все же считать 403 принятым, а не пропущенным. Удаление вызовов с трубки и чистка список удаляет/чистит журнал. С одной стороны логично, с другой - иметь бы признак удаления с трубки (типа в списке веб отображать бледным/серым/зачеркнутым, но чтобы вызов все еще оставался в логе роутера) Мелочи, табло активных звонков: Линия - line0, трубка - hs1, номер исходящего номера - с буквой "T" на конце. В истории все корректно. Звонок на удержании отображается как STATUS_NVOX_CALL_HOLD

VirtualIP - это IKEv1, одновременно IKEv2 и IKEv1 для разных подключений на одном роутере работать не будут.

С этим все абсолютно так же как и до обновления, или какие-то изменения в поведении относительно прошлой версии? Если в качестве временного варианта через CLI жестко задать только PCMA или только PCMU - работать будет, в SDP будет нормально? Или есть какая-то другая рабочая (из ваших тестов) комбинация, включающая эти два кодека?

Если кто-то напишет инструкцию по настройке RADIUS-сервера для Entware-*, заинтересованные наверняка подымут. Большинство даже дешевых роутеров WPA2-Enterprise поддерживает (насколько адекватно работает - это уже другой вопрос)

Как это выглядит сейчас: Как это может выглядеть: В последних трех столбиках данных можно добавить перенос, уменьшить th_rekey до 110-120px, th_remote_gateway до 90-100px, увеличить th_encryption до ~80-85px, th_local_remote_nets до 120-130px. Понятно, что это все сильно зависит от ОС+браузер+шрифты, но хотя бы массовому виндопользователю сделать нормальное отображение можно.

Эта инструкция актуальна только если у вас управляемый свич и на нем раскиданы VLANы. В вашем случае можно только без сегментов поставить ограничения для конкретного компьютера по связке mac:ip.

@zyxmon Базовая конфигурация............. ...Check! Своя конфигурация без adblock....Check! Полный конфиг с кучей хостов ....Check! Работает, спасибо. Edit: раз уж поднял бучу, в идеале бы поправить конфиг (unbound.conf), там чрут в /opt/var/lib/unbound идет, которого не существует. Чрутиться, если это имеет смысл, можно в /opt/etc/unbound по идее... Еще надо поправить auto-trust-anchor-file, опять же на /opt/etc/root.key

@Александр Рыжов, https://gist.github.com/korden32/53bb82066e79a504b5c27841d6a1c13f Кстати, не знаю, имеет ли это значение или нет, но ранее в логе постоянно при нормальном запуске проскакивало вот такое, я как-то не обращал внимания: [I] Feb 6 20:20:31 unbound: [769:0] notice: init module 0: validator [I] Feb 6 20:20:31 unbound: [769:0] notice: init module 1: iterator [I] Feb 6 20:20:31 ndm: kernel: warning: process `unbound' used the deprecated sysctl system call with 1.40.6. [I] Feb 6 20:20:31 unbound: [769:0] info: start of service (unbound 1.5.10). Попробую чуть попозже вернуться на 1.5.10 UPD: 1.5.10-5 по крайней мере с тем же почти дефолтным конфигом запускается.

Я в strace не умею (если нужны какие-то параметры), если просто запустить, то в конце: write(2, "[1490025631] unbound[3379:0] deb"..., 48[1490025631] unbound[3379:0] debug: donotq: ::1 ) = 48 time(NULL) = 1490025631 getpid() = 3379 getpid() = 3379 rt_sigprocmask(SIG_BLOCK, ~[RTMIN RT_1], [], 16) = 0 getpid() = 3379 gettid() = 3379 tgkill(3379, 3379, SIGKILL) = ? +++ killed by SIGKILL +++ Killed На Entware-keenetic вывод strace выглядит сосвсем по-другому, сравнить сходу сложно.

После одного из обновлений этак с месяц назад у меня на 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.