KorDen

Да, первый хоп (локальный роутер) проходит, со второго обрывается, но в паре случаев (если маршрут уходит в WAN с кучей хопов) видел что с этак пятого узла начинается нормальная трассировка (за вычетом пропущенных хопов).

Для этого есть opkg. Вставляете флешку, ставите на нее entware, кидаете скрипт с нужными действиями в /opt/ets/ndm/wan.d/ и хоть на имейл, хоть в телеграм, хоть на сирену через подключенную к роутеру звуковушку xD Флешка должна быть всегда воткнута. Если выткнуть, или она сдохнет - роутер продолжит работу, но уже без фич, что были на ней типа уведомлений

Ага. А еще, если рассматривать 5GHz-устройства, то там отдельный клиент для 2.4 и 5, ну т.е. можно на одного соседа по пятерке зацепиться, на другого по двойке Пара-тройка проводных каналов с горстью 4G-модемов при этом никуда не деваются. Но и сидеть приходится на каналах соседа, что может быть не очень хорошо (сильно зависит от местности конечно) Было время, делал мегосхему (ну как, все достаточно банально) на Giga II из двух проводных провайдеров и двух модемов с пингами каждые 2 секунды кажется. Плюс рядом в качестве холодного резерва лежал Keenetic 1 с аналогичным конфигом - простой должен был быть минимальным, все были обучены на быстрое перетыкание. В боевом режиме реально только раз перешло на другого проводного провайдера, модемы не понадобились, хотя тестировалась имитация падения и того и другого. Необходимость минимального простоя была только в течение этак месяца, поэтому смысла покупать дорогие железки с горячим резервированием 1+1 всего и вся не было. Одно плохо - нет возможности переходить по порогу потерь или заданному таймауту пинга, для ситуаций когда интернет вроде есть, но очень фиговый (сильные потери или аномально высокий пинг) - но на этот случай можно просто выдернуть кабель или выключить в вебке интерфейс.

Со времен этой темы уже давно в новых прошивках возможно задавать все необходимые опции в штатном прошивочном DHCP

Вопрос к тем, кто использует IPIP. Вроде @r13, и возможно еще кто-то.. У вас ходит трассировка через туннель? Раньше как-то специально не разбирался, а теперь понимаю, что хотя все работает и пинги ходят (в том числе пинг IP туннельного интерфейса удаленной стороны), трассировка обрывается на ближайшем роутере и до удаленной стороны пакеты не добираются вообще. Один линк роутер-роутер, другой линк роутер-Linux (Strongswan + ip tunnel), в обоих случаях одинаково - по tcpdump на приходящем интерфейсе в этот момент ничего нет. Т.е.: имеем линк IPIP (192.168.0.1/24) [192.168.255.1/30]---[192.168.255.2/30](192.168.1.1/24). Со 192.168.0.2 пингуется 192.168.255.2 и все удаленные узлы и проблем нет, но если сделать трассировку до чего либо, на интерфейсе 192.168.255.1 уходящий icmp видно, на 192.168.255.2 тишина, трассировка соответственно не идет дальше 192.168.0.1 ICMP пробовал специально на всех интерфейсах разрешать, толку нет. private/protected/public - значения не имеет.

Эээм, а какие еще параметры, кроме reg-timeout, нужны? registration-retry как я понимаю юзается только при неуспешной регистрации, а других похожих параметров я не вижу.

Даешь policy-based routing! С verify-availability и прочими even-odd.

Локальные сервисы ходят через прошивочный сервер (он ведь остается в rpc-режиме). Если в DNS-серверах роутера прописать локальный IP самого же роутера и запретить получение DNS от провайдера (ip dhcp client no name-servers), или вручную их прописать только для резолвинга имен сервера подключения например, с указанием домена - роутуер будет ходить на локальный сервер: (config)> show ip name-server server: address: 192.168.0.1 domain: global: 0 (config)> tools ping www.google-analytics.com sending ICMP ECHO request to www.google-analytics.com... PING www.google-analytics.com (0.0.0.0) 56 (84) bytes of data. 84 bytes from www.google-analytics.com (127.0.0.1): icmp_req=1, ttl=64, time=0.41 ms. --- www.google-analytics.com ping statistics --- 1 packets transmitted, 1 packets received, 0% packet loss, 0 duplicate(s), time 600.33 ms. Round-trip min/avg/max = 0.41/0.41/0.41 ms.

Похоже, разобрался. Если при создании дефолтного маршрута не указывать интерфейс (т.е. оставить "любой"), то оно как бы добавляет 0.0.0.0/0 via 192.168.0.1, и в таблице маршрутов корректно отображает что маршрут через Home, но при этом обновления не работают: [I] Jan 1 03:02:01 ndm: Dns::Manager: name server 192.168.0.1 added, domain (default). [I] Jan 1 03:02:01 ndm: Core::ConfigurationSaver: saving configuration... [I] Jan 1 03:02:05 ndm: Core::ConfigurationSaver: configuration saved. [I] Jan 1 03:02:06 ndm: Network::RoutingTable: added static route: 0.0.0.0/0 via 192.168.0.1. [I] Jan 1 03:02:06 ndm: Core::ConfigurationSaver: saving configuration... [E] Jan 1 03:02:08 ndm: Core::Ndss: [406] no internet connection. [E] Jan 1 03:02:24 ndm: Core::Ndss: [524] no internet connection. [I] Oct 21 11:28:52 ndm: Core::System::Clock: system time has been changed. [I] Oct 21 11:28:52 ndm: Ntp::Client: time synchronized with "3.pool.ntp.org". [E] Oct 21 11:28:53 ndm: Core::Ndss: [545] no internet connection. А вот если указывать интерфейс Home - тогда обновления работают. Причем похоже если туда-сюда переключать без ребута, то начинаются странности, я тогда вначале добавил через "любой", а затем изменил на "Home", но оно все равно ругалось. А сейчас вроде воспроизвести не получилось, все работает.

А вот кстати интересно. DNS-то добавлен, и маршрут похоже таки работает: (config)> tools ping ndss.11.zyxel.ndmsystems.com sending ICMP ECHO request to ndss.11.zyxel.ndmsystems.com... PING ndss.11.zyxel.ndmsystems.com (88.198.177.100) 56 (84) bytes of data. 84 bytes from ndss.11.zyxel.ndmsystems.com (88.198.177.100): icmp_req=1, ttl=50, time=54.86 ms. 84 bytes from ndss.11.zyxel.ndmsystems.com (88.198.177.100): icmp_req=2, ttl=50, time=54.25 ms. --- ndss.11.zyxel.ndmsystems.com ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss, 0 duplicate(s), time 1654.51 ms. Round-trip min/avg/max = 54.25/54.55/54.86 ms. (config)> components preview preview: Core::Ndss error[9240615]: [507] no internet connection. И я ведь совсем забыл - время-то устанавливается по NTP.. Т.е. походу это чисто бага апдейтера...

Режимы работы а-ля ТД и прочие репитеры-клиенты урезают слишком много функционала, поэтому ТД работает в режиме роутер, но с отключенным ISP, DHCP и NAT. Однако в таком виде сам роутер не может связаться с интернетом для обновлений и прочего, а добавление настоящего шлюза ничего не дает, т.к. Home у нас не global. Как можно заставить сам роутер в режиме роутера ходить на шлюз в сети Home? Это же касается и бриджевания EoIP в Home. Edit: похоже, только обновление компонентов ругается на отсутствие интернета (Core::Ndss error[9240615]: [507] no internet connection), при этом время по NTP синхронизируется, пинг того же ndss проходит.

Немножко поворчу, "незаметно" с маленькой оговоркой - при каждой проверке перестраиваются правила iptables, и при настройке своих правил через OPKG это таки может быть заметно. По крайней мере так было этак в 2.09 и раньше, не знаю как сейчас дела обстоят. Пинг-чек надо включать на обоих каналах. Проверка на модеме позволит модем перезагрузить (вплоть до передергивания USB-порта и даже ребута всего роутера, если настроить) в случае проблем, вне зависимости от того, кто сейчас основным каналом.

Проверил - на сервере свой таймаут не стоит. Пример конечного 200 цепочки Register - 100 - 401 - Register - 100 - 200, которая повторяется каждые 2 минуты SIP/2.0 200 OK Via: SIP/2.0/UDP 5.6.7.8:5060;rport=5060;branch=<...>;received=5.6.7.8 From: "0071234567890" <sip:0071234567890@servername>;tag=<...> To: "0071234567890" <sip:0071234567890@servername>;tag=<...> Call-ID: <...> CSeq: 18770 REGISTER Contact: <sip:0071234567890@1.2.3.4:5070>;expires=1261, <sip:0071234567890@5.6.7.8:5060;ob>;expires=1800 Server: kamailio (5.0.0-dev6 (x86_64/freebsd)) Content-Length: 0 Конфиг линии sip 2 name <...> login 0071234567890 password <...> domain servername identity 0071234567890 display-name 0071234567890 registration-uri servername proxy servername incoming-mask <...> outgoing-mask <...> reg-timeout 1800 disable-stun priority 2 codec g711u codec g711a !

У сервера таймаут однозначно больше, либо его вообще нет - не помню сходу, сколько там стоит, но по крайней мере другие SIP-железки с таймаутом 3600 нормально обновляют регу только раз в час.

В настройках линии стоит таймаут регистрации в 1800 сек, keepalive 15, NAT нет. При этом на сервер летят регистрации приблизительно каждые 2 минуты. self-test/дампы скину при необходимости позже.

Одновременно могут работать несколько туннелей IKEv2 и сервер VirtualIP. Если попытаться настроить туннели IKEv1 и VirtualIP - будет работать только одно (приоритеты сходу не помню)

Да, и тоже с аппаратной разгрузкой, хоть и более слабой. Я думал у вас железки постарее будут, или других производителей. Ситуация приблизительно такова: на PPTP вы получаете до 30-40 мбит суммарно, плюс PPTP небезопасен, на IPsec при покдлючении пары Extra II к Ultra II во всех направлениях (вплоть до передачи Extra -> Ultra -> Extra) порядка 50-60 мбит/с, причем с более гибкими возможностями настройки Если нужно связываться только с основным офисом - берете чистый Ipsec-туннель, если нужно ходить всем друг к другу (включая связь между 2 и 3) - смотрите в сторону туннелей IPIP/GRE, ну а посредством EoIP можно вообще сделать абсолютно прозрачную локалку, как будто вы и не разъезжались (в этом случае скорость будет поменьше из-за увеличения служебного трафика, но в некоторых случаях это вполне вариант)

А роутеры в других точках умеют в IPsec? Он куда лучше PPTP, причем Ultra 2 имеет аппаратный криптомодуль, и спокойно может гонять 150+ мбит/с (на PPTP около 30-40 мбит вроде). Netbios между сегментами L3 не ходит, как вариант можно прописать необходимые имена в DNS каждого роутера (для кинетиков команда ip host). Если вдруг очень нужен единый широковещательный сегмент - можно посмотреть в сторону EoIP (поверх IPsec).

Тогда увы, на чужих серверах без возможности настройки такого скорее всего не сделать.

Если вам не нужно, чтобы ходил broadcast-трафик и был единый сегмент (обычно это нужно для какого-нибудь старого софта, не умеющего обращаться на указанный IP), то вам нужен OpenVPN tap или EoIP. В большинстве случаев же будет достаточно либо OpenVPN tun, либо IPIP/GRE-туннеля. На OpenVPN, при условии что оба клиента подключены к одному серверу, навскидку: - раскомментируйте в конфиге опцию client-to-client, назначьте клиентам статические адреса (например, 192.168.255.2 и 192.168.255.3, сервер скажем 192.168.255.1 255.255.255.240) - настройте на роутерах разные подсети.Например, на одном 192.168.0.1/24, на другом 192.168.1.1/24 - добавьте на каждом роутере маршруты до другого клиента через его IP в туннеле, отключите isolate-private (можно настроить фаервол, но это надо заморачиваться) Для уменьшения служебного трафика можно использовать IPIP поверх IPsec, но это потребует более заморочной настройки сервера. Кроме того, встречались причуды у операторов с глюками IPsec, это уже надо будет проверять самому.

Вы не поняли проблему. В сети проблем нет, голый EoIP с фрагментацией работает. Вроде бы если завернуть это в ручной транспорт - тоже проблем нет, но я такое проверял несколько месяцев назад. А сегодня я попытался сделать автотуннель, и тут уже фрагментация похоже не работает. Собрать стенд проверить напрямую еще не было времени.

Ну, не знаю - без ipsec у меня идут пинги по 1472, стоит включить ipsec - уже выше 1388 из присоединенного сегмента не проходят. Конфиг приблизительно такой system set net.core.eoip_allow_fragment 1 interface EoIP0 security-level private ip mtu 1500 ipsec preshared-key 12345678 ipsec ikev2 tunnel destination 1.2.3.4 tunnel eoip id 123 up ! interface Home include EoIP0 ip mtu пробовал не ставить. self-test с обоих сторон при необходимости скину вечером.

Попытался тут сделать EoIP-автотуннель (прямо как в шапке, только без IP) и засунуть его в Home (с фрагментацией), Ultra II @ 2.11.A.4.0-2 <-> Start II @ 2.10.B.0. Автоустановка mtu ставит принудительно 1416 и повлиять на это похоже никак нельзя, "ip mtu 1500" ничего не дает. Кстати, после этого отключил ipsec на туннеле, mtu (в show interface) остается 1416, и без удаления туннеля или ребута вернуть его обратно в 1500 не получилось ни перевключением туннеля ни принудительным "ip mtu 1500"

Уже объяснили, что автообновления пушатся позже. Кроме того, если даже прилетит автообновление, роутер сам не перезагрузится. В моделях на 7621/7628 с dual-image идет традиционная загрузка прошивки в неактивный слот. Т.е. прошивка скачается, но применится только после перезагрузки вами вручную, автоматом роутер в перезагрузку не уйдет. Условно, как обычно работает такой процесс (не знаю, насколько точно это относится к кинетикам, но суть схожа): Есть слоты/образы прошивок, OS1, OS2. Например, на текущий момент у нас в OS1 прошивка 2.09.C.1, в OS2 - 2.09.C.0, сейчас роутер настроен на загрузку с OS1 Руотер начинает автоообновление и закачивает прошивку в слот OS2. Если во время загрузку роутер ребутнуть, ничего не произойдет - да, в OS2 будет кривая прошивка, но в OS1 у нас рабочая, и грузимся мы именно с него После завершения загрузку образа в OS2 могут быть проведены какие-то внутренние проверки на целостность, после этого будет выставлен флаг загрузки с OS2, но текущая система еще работает с OS1. Дальше при перезагрузке, не важно - по питанию, или програмно - начнет грузиться прошивка из OS2, т.е. обновленная. Если вдруг произойдет бутлуп до завершения загрузки - в теории загрузчик должен будет переключить на OS1.

Ага, а потом выгребаем сюрпризы.. Это в минусы автообновления. Те же проблемы с WiFi на нексусах и некоторых других смартфонах, и так далее... Но все же про "работает - не трогай" я чуть бы поспорил. Во-первых - уязвимости. Во-вторых - ошибки, которые уже давно исправлены, но аукаются спустя несколько лет. Я вживую наблюдал проблему "работает - не трогай" по отношении к кинетикам, и кажется как-то уже рассказывал о ней здесь. После обновления DNS-серверов у провайдера, которое вроде бы ничего не должно было поломать, внезапно начали жаловаться люди на то что все сломалось и ничего не работает. Начали выяснять - казалось, что у всех жалующихся кинетики (впрочем, была еще пара роутеров других производителей, но это были буквально 1-2 человека). При этом никто из нас воспроизвести проблему на своих роутерах не мог. Оказалось - у людей так и стоит прошивка с завода, или обновленная один раз при настройке. Исправили тот баг с DNS кажется еще в 2.03, а у людей стояли куда более старые версии NDMSv2 (v1 вроде не задело) - и это в 2016 году!