KorDen

Для большинства случаев использования туннелей в роутерах нужно фиксированное значение а-ля 64. По-умолчанию же идет inherit. По RFC2003 "The Time To Live (TTL) field in the outer IP header is set to a value appropriate for delivery of the encapsulated datagram to the tunnel exit point.", но linux ставит inherit если параметр ttl отсутствует при создании туннеля. В качестве быстрого фикса установка того же 64 закроет вопрос. Аналогично по идее и для GRE, за EoIP не скажу. Но в идеале бы хотелось бы видеть опцию для настройки, хоть и не обязательно..

Отвечу себе же на свой же вопрос: ipip0: ip/ip remote 1.2.3.4 local 5.6.7.8 ttl inherit Короче говоря, "ip tunnel change ipip0 ttl 64" решает проблему. Остается вопрос - как перманентно установить TTL для исходящего туннельного пакета из CLI? ip adjust-ttl устанавливает не то что нужно... Похоже это в фичреквесты добавления команды типа interface tunnel ttl как минимум для IPIP и GRE (с EoIP непонятно, поскольку RFC-подобного описания сходу не нашел), которая будет устанавливать TTL внешнего пакета. @Le ecureuil...? P.S.: временно решил проблему через /opt/etc/ndm/ifstatechanged.d: #!/bin/sh [ "$system_name" != "ipip0" ] && exit 0 ip tunnel change ipip0 ttl 64

Дано: туннель IPIP over IPsec через интернет. Туннель работает, но напрягает сломанная трассировка через туннель. На стенде из пары роутеров не воспроизводилось, начал ковырять дальше и таки выяснил причину - при трассировке через IPIPoverIPsec туннель TTL=1 выставялется для "внешнего" пакета, как следствие, time exceeded приходит от провайдера! На tcpdump ISP это выглядит условно так: 19:23:42.163312 IP (tos 0x0, ttl 1, id 0, offset 0, flags [DF], proto ESP (50), length 152) localrouter > remoterouter: ESP(spi=0x11111111,seq=0x11), length 132 19:23:42.164677 IP (tos 0x0, ttl 30, id 0, offset 0, flags [none], proto ICMP (1), length 56) isp-gateway > localrouter: ICMP time exceeded in-transit, length 36 IP (tos 0x0, id 0, offset 0, flags [DF], proto ESP (50), length 152, bad cksum 82e0 (->83e0)!) При этом при пинге удаленного конца туннеля видим, что внешний пакет приходит с TTL равен исходящему минус количество внешних хопов, однако в развернутом пакете TTL равен исходящему минус 1. Вопрос - возможно ли его изменить, чтобы исходящий пакет уходил с нормальным TTL, не взирая на TTL заворачиваемого пакета?

По pingcheck переключилось на резерв (понятное дело с обрывом вызова). Первую минуту после этого исходящих не было (хотя инет уже был), Nvox видимо ждал таймаута повтора регистрации, или что подобное. Для этого обычно есть таймеры ожидания хоть какого-либо ответа, составляющие буквально несколько секунд, и тут мне кажется тишина вполне уместна. КМК - если на INVITE не прилетает 100/401/... в течение условных 5-10 сек - значит что-то не так и отбиваем.

Словил тут в момент переключения провайдеров: nvox: Outgoing call from HS ... to ... was rejected. Lines were unavailable because of SIP registration failure. Хотелось бы напомнить, что регистрация не является обязательной для выполнения исходящего звонка.

В вашем случае либо а) IPsec в туннельном режиме, ориентировочно AES128-SHA1 / DH14 во второй фазе пожалуй будет достаточно, в первой максимум AES256/SHA256, выше смысла нет. Транспортный режим вручную настраивать смысла нет, если не понимаете до конца как это все работает. б) автоматический туннель IPIPoverIPsec, пример настройки скажем тут - https://forum.keenetic.net/topic/4562-объединение-2-ух-интернет-центров-какой-туннель-оптимальнее/?do=findComment&comment=53412 У Gre/EoIP оверхед выше, и в общем случае они не нужны Из моей практики - на Giga II IPIPoverIPsec IKEv2 спокойно жует чуть больше 100 мбит/с в обе стороны (по отдельности конечно).

А разве пчела уже перестала выдавать динамические беляки? Или это отголоски купленных сеток?

Речь про раздельные инстансы роуминга для каждого SSID (e.g. Main/Guest)

Роуминг будет отстрелом как я понимаю? Будет ли совместимость с Band Steering + учтено ли, что доп.точки могут быть 2.4-only например? Рассматривается ли роуминг для дополнительных SSID (гостевая)?

В компонентах прошивки есть сенсор Netflow, позволяющий сливать инфу по соединениям на внешний сервер.Теоретически коллектор можно поставить и на роутер. Вы же понимаете, что сейчас бОльшая часть трафика - HTTPS, максимум отслеживаемый по имени домена в SNI при установлении соединения?

У них поговаривают сегодня после вброса и выброса 1к IP что-то поплохело очень сильно.

Стоп. Речь про именно галку components auto-update, а не про components commit. Каково её поведение?

Предлагаю добавить возможность по нажатию кнопки делать usb power-cycle нужного порта (без привязки к интерфейсу модема, просто порт 1/2) и/или (re)mount устройства в указанном порту. Лично мне это надо для возможности примонтировать обратно флешку (и запустить сервисы на ней) без физического перетыкания (и входа в CLI). На практике так же может пригодиться для быстрого ручного ребута модема, если роутер и USB-удлинитель закреплены на стене и заходить в морду долго, а роутер вон на стенке висит

Там в идеале не только шторку, а надо все padding'и уменьшать вдвое и так далее, потому что даже на FullHD дашборд занимает три экрана, а можно было уместить всё в одном 1366*768. Но этот чертов тренд win10 чтобы скороллить-скроллить-скроллить и поменьше текста на квадратный сантиметр, иначе хомячки выпадают от переизбытка информации.

В последней прошивке поломан TypeError: f.getComponentsList is not a function at new e (http://192.168.0.1/scripts/app-07faaf8788.js:16:12241) at Object.u [as instantiate] (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:21637) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:16401 at Object.<anonymous> (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:32:16587) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:5956 at bt (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:11367) at h (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:3774) at a (http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:31414) at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:12:30945 at http://192.168.0.1/scripts/vendor-5e0d2f978f.js:13:1708

Насколько мне известно, роутер сам после автоматического обновления в перезагрузку не уходит.

А, как я понимаю, каждая копия смотрит на DNS, доступные конкретной политике? Т.е. если политика на IPIP0, то нужны либо глобальные DNS (без "on ISP"), либо "on IPIP0", чтобы работали девайсы в политике?

В курсе. Решается прописью в качестве name-server 192.168.1.1. Но каким тут боком это? Ничего не понял, что вы хотели всем этим сказать, и как это опять же относится к политикам? Собственно нюанс, что все локальные сервисы продолжают работать с прошивочным резолвером - известен. Что еще-то?

Хм. На роутере включен opkg dns-override и стоит свой DNS-сервер в Entware. Попробовал сейчас создать политику и закинуть в него смарт - у него отвалился DNS, после прописки вручную внешнего DNS-сервера всё заработало... Откуда начинать копать..?

В частности S850HX сохраняет несколько баз (работает только одна выбранная), и при выборе есть настройка "Лучший блок", но на практике я её не проверял.

Я говорил про чистый IPsec-туннель site-to-site, он через NAT ходит Классический IPsec-туннель, который настраивается из web-интерфейса, работает через политики. Как следствие, нельзя нормально настроить взаимодействие более двух сетей (например, если у вас два роутера подключаются к третьему-серверу и надо чтобы все могли заходить ко всем), нельзя сделать нормально проброс порта с белого IP за серый и проч. Оно пока возможно вам не нужно, но потом обязательно что-нибудь может захотеться Поэтому проще сразу сделать туннель на классической маршрутизации.

IPIP over IPsec, нацеленный на KeenDNS-имя Keenetic II (он будет работать в прямом режиме т.к. IP белый). Прошивка естественно должна быть минимум delta. В общем случае, скажем локалка Keenetic II - 192.168.1.1/24, локалка Giga II - 192.168.2.1/24, если не заморачиваться с фаерволом: Keenetic II: interface IPIP0 description Giga security-level private ip address 172.31.255.1 255.255.255.252 ip tcp adjust-mss pmtu ipsec preshared-key <ключ> ipsec ikev2 tunnel source <имя интерфейса с интернетом> up ! ip route 192.168.2.0 255.255.255.0 172.31.255.2 IPIP0 auto no isolate-private Giga II: interface IPIP0 description Keen2 security-level private ip address 172.31.255.2 255.255.255.252 ip tcp adjust-mss pmtu ipsec preshared-key <ключ> ipsec ikev2 tunnel destination <keendns-имя Keenetic II> up ! ip route 192.168.1.0 255.255.255.0 172.31.255.1 IPIP0 auto no isolate-private ну и на всякий случай выполнить на обоих "crypto engine hardware" хотя должно быть по-умолчанию включено Можно и просто IPsec-туннель без маршрутизации, но у него есть ограничения

Возможно соглашусь, хотя при наличии OPKG... (Впрочем, OpenVPN тоже издавна был сторонним пакетом..) Поддержу. Как минимум section/begin нужны, у некоторых Cisco-like интерфейсов еще есть универсальный поиск "show run <...>" типа "show run interface" Фломастеры. Мне например вообще больше нравится D**'ая простейшая идеология tagged/untagged, без всяких излишних переключений trunk/access Я бы еще добавил в хотелки исправление старой болячки - автодополнение второго и последующих уровней не работает, если предыдущие написаны сокращенно: sh -> show show run -> show running-config sh run -> сейчас ничего, а хотелось бы как в предудщем, чтобы по 10 раз tab не жать.

Чисто по VPN - напрямую нельзя, но при наличии где-то (с той стороны VPN например) socks-прокси (1.2.3.4:5678) можно по идее сделать такое вот (0.0.0.0 0.0.0.0 - подсеть и маска) ip static tcp 0.0.0.0 0.0.0.0 80 1.2.3.4 5678

Со стороны сервера - возможно. Со стороны роутера - в последних прошивках туннели уже упрощены максимально tap tcp/443 имеет смысл только если выходите в интернет через http-прокси или еще через какую-то "трудную" сеть. В остальных случаях лучше udp на любом нестандартном порту В последних прошивках уже давно есть OpenVPN из коробки ... а маршруты были всегда. Маршруты через OPKG имеют смысл только при использовании ipset и прочей экзотики.