KorDen

Вы, возможно, слишком идеализированного мнения о провайдерах провинций. Бывают конечно невезучие дома, где регулярно горят свичи/рвут кабели/..., но бывают и те, где ничего не отваливается месяцами. А вот проблемы по п.2 могут происходить чаще из-за постоянных улучшений/изменений в инфраструктуре. Да, такие проблемы быстрее чинятся, но, по крайней мере у нас, мелочи встречаются довольно часто. Обычно это не полный отказ, а некорректно отработавшее резервирование, например кривая балансировка после отвала магистрали. В итоге интернет вроде есть, но либо не везде, либо с большими потерями. Пока скорректируют, может пройти условно полчаса-час, а в это время есть более стабильный резерв. Кроме того, принципы работы сети разнятся - у одного провайдера коммутатор может сверять IP-MAC-Port каждый час и блокировать при недоступности биллинга, а у другого будет сохраняться последняя запомненная таблица до восстановления связи. А то и вообще может такой связки не быть, или она будет на более удаленном уровне (привязка только к дому/"лучу" оптики от районника или еще какая экзотика). В таких случаях вполне возможно сохранение связности в рамках [микро]района при проблемах чуть дальше. На мой взгляд, логичнее было бы видеть дополнительный параметр у каждого маршрута, оставлять ли конкретный маршрут при отвале по пингу. Хотя и предложенный вами в принципе сойдет, по крайней мере в моей текущей ситуации. Дополнительно хотелось бы видеть в пинговалке установку таймаута/размера пакета для отлавливания ситуаций, описанных выше, но это уже совсем другая история...

Ultra 2 / 2.07. Есть основной провайдер (IPoE), есть резерв (Yota либо 3G-модем), уходит на резерв по ping check. Есть несколько маршрутов до внутренних сетей провайдера IPoE (например 10.0.0.0/9), в том числе диапазоны беляков, пример: ip route 10.0.0.0 255.128.0.0 31.132.x.y ISP-IPTV auto (31.132.x.y -default gateway) По логике вещей, при уходе на 3G/4G по отвалу пинга у меня должен оставаться доступ к локалке IPoE согласно указанным маршрутам. На практике же получается что в этот момент через br2 роутится только дефолтный маршрут до подсети приходящего IP. В давние времена у меня была Giga 1 (еще кажется 2.01, 2012 год вроде), основным было PPTP/L2TP, резерв был IPoE, работало в обратную сторону - при основном соединении по PPTP у меня была доступна локалка провайдера IPoE, при падении PPTP маршрут перекидывался на резерв, но сохранялись маршруты до локалок обоих провайдеров. Думал сделать аналогично, с учетом текущих условий, но логика похоже поменялась, либо я что-то делаю не так.

FTP-сервер не имеет никакого внешнего вида. Надпись "Generated ... by nl5.brwsc.org (squid)" не намекает ни на что? Это генерирует ваш прокси

В случае с Ultra 2 (где WAN отдельная сетевушка) в данном случае не имеет значения, куда воткнут аплинк? Скажем, если у меня два гигабитных линка от двух разных провайдеров с IPoE, один воткнут в WAN, другой в LAN1, то железный PPE (для проводного клиента) будет одинаково хорошо работать для любого из них?

С новым делением разделов IMO перемудрили, даже теперь и не знаю, куда стоит о таком писать: как минимум профиль Sipnet не задает транспорт TLS и SRTP, по умолчанию так и остается UDP/RTP. Пощелкал - вроде профили вообще не задают тип транспорта, или я ошибаюсь? Как мне кажется, было бы логичнее сделать использование шифрования по умолчанию в профилях провайдеров, которые его поддерживают. PS: у меня нормально работает по крайней мере исходящая связь на сипнет с TLS (SIP-TLS)/SRTP

Где-то на этом форуме уже говорили, что чтобы работал HW, надо включить и HW и SW. У меня на Giga 2 спокойно качались-раздавались торренты при тарифе в 300 мбит/с (IPoE), нагрузка даже к 50% не подходила. В провайдерской локалке файлики гоняли на 500-700 мбит/с...

А бесконечное переподключение на Giga 2 будет поправлено?

Да, действительно, с IPSec это работает. В случае с PPTP, наверное, можно опрашивать подключенных к серверу пользователей (ndmq -P "tunnel/username" [ну или tunnel/clientaddress] -p "show vpn-server" ), дальше по своим соответствиям добавлять фильтры в iptables... Но хука никакого же нет на подключение/отключение клиентов VPN-сервера?

Интересует, какими способами можно заставить кинетик (Giga 2/2.06, Ultra 2/2.07) отвечать No route to host при обращении к сетям, которые должны быть доступны через туннель, но сейчас недоступны? Т.е. к примеру моя сеть 192.168.0.0/24, удаленная по IPSec 192.168.1.0/24 и удаленная по PPTP 192.168.2.0/24. Если туннель не работает, то пакеты на 192.168.x.0/24 пойдут через дефолтный маршрут в сеть провайдера, чего не хочется. Если no route to host нельзя сделать (было бы наиболее красивым вариантом), по идее можно запретить через iptables, в таком случае вопрос - netfilter.d вызывается и при поднятии/падении IPSec / L2TP/IPSec?

Можно банально открыть через межсетевой экран, указав только номер порта назначения и протокол Можно через iptables - ставим его (opkg install iptables), далее в /opt/etc/ndm/netfilter.d создать исполняемый sh-файл с любым наванием, содержимое вида: #!/opt/bin/sh [ "$table" != "filter" ] && exit 0 /opt/sbin/iptables -I INPUT -p udp --dport 12345 -j ACCEPT /opt/sbin/iptables -I INPUT -p tcp --dport 12345 -j ACCEPT

Такс.. Я в принципе ковыряюсь с PPTP/OpenVPN только потому, что мне крайне желательно иметь возможность маршрутизировать некоторые IP в интернете через этот туннель, а IPSec этого не позволяет (в случае кинетиков)... Подумалось тут - запустил на компе за Giga 2 PPTP-соедиение на внутренний IP Ultra 2 (192.168.0.1) - а ведь работает, и даже 60 мбит выдает, и это я MPPE не отключал еще... Костыль конечно, но зато штатными средствами интернет поверх IPSec, без OPKG.. Вот только поднять это самое PPTP до внутреннего IP ультры на гиге нельзя - он упорно добавляет статический маршрут до 192.168.0.1 через шлюз IPoE-соединения

Вот оно че! Вот теперь ощущается - по HTTP ~80 Мбит/с, Giga 2 CPU ~80-90%, морда не зависает... Копирование по самбе между компьютерами по туннелю вообще под 13 МБ/с (сеть гигабитная), но тогда морда перестает отвечать. Самое главное, что подтверждена, а не очередной Шредингер... Теперь руки чешутся поставить на Ultra 2 L2TP/IPSec-сервер...

Поэкспериментировал с PPTP vs IPSec (Giga 2 - Ultra 2) на последних прошивках, в первом приближении: PPTP MPPE128 - скорость около 45-50 Мбит/с, нагрузка на ЦП Giga 2 100%, вебморда подлагивает. IPSec AES128/SHA1/DH14 - около 25 Мбит/с, нагрузка на ЦП Giga 2 100%, вебморда вообще не отвечает в момент передачи. Экспериментировал с разными параметрами шифрования SA, особого прироста не дало. Что-то аппратное шифрование как-то не чувствуется... OpenVPN пока не получилось протестировать - почему-то туннель между роутерами падает при передаче, хотя с внешним сервером на Linux оба работают нормально, расковырять причину пока не удалось. [Ранее между Giga 2 и Giga 1 (оба на NDMS 1.11 / Entware) на AES128/SHA1 скорость была 10-12 Мбит/с, упиралось в процессор Giga 1.]

opkg dns-override переводит его в RPC-режим, т.е. освобождает 53 порт для возможности запуска dnsmasq/bind/unbound из OPKG, но ndnproxy остается работать для штатной системы (проверка обновлений, NTP, ...). Для резанья рекламы у меня стоит Unbound, по совместительству - полноценный рекурсивный резолвер. На этом форуме есть мануал по настройке dnsmasq

teodorre, у хромбука L2TP over IPSec, NDMS его только в качестве клиента поддерживает. Кроме того, IPSec у кинетиков в любом случае только в локалку, доступа в интернет через него нет. Вроде в хромбуке есть OpenVPN - смотрите в сторону OPKG.

В динамическом режиме (SOCKS-прокси) у меня нормально работало на Entware наружу, но не проверял доступность внутренних узлов. Вы какой opkg-то ставили? Keenopt / Entware / Entware-Keenetic?

Хм. Есть подозрение, что по истечении часа (т.е. по истечении времени жизни SA) Как минимум при SA lifetime 3600 спустя некоторое время (несколько часов) начинается бесконечное пересогласование. Лог начинает забиваться подобными сообщениями:

Хм,а у вас страница состояния на 2.07 отображается, или тоже виснет?

Если клиент на 2.05, то IPSec не вариант, смотрите в сторону штатного VPN(PPTP)-сервера.

Да, с SHA1 все заработало. Ох уж это 2.6.22... Как я понимаю, для Giga 2 на этом ядре все и закончится (вроде, 2.06 последняя для поколения Keenetic 2/Giga 2?), до новых версий обновлений не будет?

Хм, что-то не устанавливается соединение Ultra 2 (2.06(AAUX.6)B2) - Giga 2 (2.06(AAFS.3)B2) На "сервере" в логах 13[KNL] unable to add SAD entry with SPI cd97ff8d 13[KNL] unable to add SAD entry with SPI c36be550 13[iKE] unable to install inbound and outbound IPsec SA (SAD) in kernel 13[iKE] closing IKE_SA due CHILD_SA setup failure На "клиенте" 06[iKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built 07[iKE] closing IKE_SA due CHILD_SA setup failure IpSec::Configurator: remote peer of crypto map "KD" returned proposal mismatch for IPsec phase 2.

Какая логика проверки email для идентификатора, почему нельзя использовать выдуманные внтренние зоны типа router@router1.home?

А зачем вешать dnscrypt на другой порт и перехватывать через iptables, если можно сделать opkg dns-override и повесить на 53 порт?

А, т.е. он все же вызывается именно при смене дефолтного маршрута, ясно. После прочтения мне казалось что вызов идет в момент поднятия любого интерфейса, а не в момент изменения главного. Тогда да, можно сохранять текущий wan в файл и сравнивать с ним.. Правильно ли я понимаю "When the internet connection is down...", что wan.d вызывается с неустановленными переменными только когда больше нет вариантов для маршрута по умолчанию, т.е. либо отвалился и резерв, либо упавшее соединение было единственным с галкой "использовать для доступа в интернет"?

А нет возможности ловить не только поднятие, но и момент переключения между основным/резервным? В идеале туда передавать названия откуда и куда переключилось (и причину, если возможно), например (названия с потолка): $old_interface - с которого уходим $new_interface - на который уходим $reason: ethdown - отвал физического линка timeout - отвал VPN/PPP по таймауту terminated - закрытие VPN/PPP сервером pingfailed - неуспешная проверка ping check recovery - возврат с резерва при восстановлении основного линка