gaaronk

Ну у меня специфические задачи. Мне гарное аппарате (dect или проводной) довести до asterisk, который и держит все линии и сам везде маршрутизирует. С учетом что звонки внутренние, офис, РФ, Украина, то пока вот так: 2xxx|8[3-9]xxxxxxxxx|71[027]x|715xx|7[2-5]xxxxxx|70[1-9]xxxxxxxx|0441[027]x|04415xx|0[1-9]xxxxxxxx|9xxxx|(81038>)0[1-9]xxxxxxxx|810xxxxxxxx.

Обновил верси 3.1.12 до версии 3.4.6 на двух маршрутизатора Start и Giga III При доступе по HTTPS постоянная картина - web интерфейс не открывается какое то время, чего то ждет. Потом через пару минут - можно попасть в админку. Снял дам трафика. Начинается обычная TCP сессия, потом в какой то момент в пакетах от кинетика получаю TCP Spurious Retransmission. Дальше непрерывно DUP ACK и TCP Retransmission порядка минуты. Видно что броузер делает сессии reset и начинает заново. И сразу же DUP ACK и TCP Retransmission непрерывно. Снова рвет сессию и в третий раз все чудесно работает. Откатил на Giga III - все паузы ушли. Могу выложить dump трафика.

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

Скажите пожалуйста, почему "Правило набора" ограничено всего ста символами? У меня правило не влезает =(

А скажите, работа с iptables планируется к изменению? Версия 3.4.6 Вот простой скрипт #!/bin/sh [ "$table" != "mangle" ] && exit 0 echo `date` >> /tmp/mangle.tstmp exit 0 Вот вывод скрипта. Нормально и корректно добавить свои правила в таблицу mangle через хук реально невозможно. Или может есть вариант сказать прошивке что я хочу добавлять и она сама будет это вписывать при каждом передёргивании? Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:31 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:32 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020 Sun Jun 14 23:04:33 MSK 2020

Ну это тоже ответ. Если фича нужна одному пользователю - смысла тратится на нее действительно нет.

Хорошо. Насчет state я ошибся. Не проблема. Посмотрел не туда. Туда это вот - link: down. Не суть. Суть что пропадает маршрут, это да.

Для того что бы в интерфейс пошел трафик, он стал link up, connected yes надо что бы трафик туда попал. Хост изнутри пингует дальнюю с сторону. Маршрута нет, и пинг идет не в интерфейс wireguard, а в дефолт. Нет трафика - нет маршрута. А нет маршрута - нет трафика.

Изнутри инициируют соединение не в подсеть на интерфейсе, а сеть лежащую за интерфейсом. И это как раз проблема. Конечно пинги на стыковочные адреса работают.

Как же не идет, когда идет? было state: up стало state: down Это никак не связанно с netfilter. Вообще никак. А трафик изнутри не пойдет. Нет маршрута в интерфейс. Да, это видимо внутрення логика - state стал down - убрали маршрут. Тут два варианта - обвешивать эту логику всякими if на предмет - это интерфейс Wireguard или нет. Или отключить выключение состояния интерфейса, что проще, как мне кажется.

Ну тогда процитирую. PersistentKeepalive — a seconds interval, between 1 and 65535 inclusive, of how often to send an authenticated empty packet to the peer for the purpose of keeping a stateful firewall or NAT mapping valid persistently. Между пирами у меня нет ни NAT, ни stateful firewall.

Нет, Keepalives это для пробития NAT. А тут оба пира на белых адресах. На кинетике когда нет хендшейка - интерфейс идет в down, и из таблицы попадает маршрут привязанный к этому интерфейсу. На linux - нет хендшейка и нет себе. Хочется по ряду причин не использовать keepalive. Трафик бегает в этом туннеле очень редко. И хочется объем трафика минимизировать по максимуму.

А можно опцию для Wireguard интереса что бы не делать ему down, если не было хендшейка и не было трафика более 120 секунд?

Читаю читаю документации и пытаюсь понять. Если у меня на роутере два GRE туннеля, то мне аналогично надо будет сделать два wireguarg интерфейса (каждый на своем listen port), каждый с одним пиром и AllowedIPs 0.0.0.0 ? Потому что я не могу создать один wg интерфейс, с адресом с маской /24 и несколькими пирами у которых AllowedIPs 0.0.0.0 ? Потому что заранее казать какие чета лежат за пиром невозможно, как маршрутизация ляжет. Как то так interface Wireguard0 description "VPN 1" security-level public ip address 172.16.1.1 255.255.255.248 wireguard listen-port 1501 wireguard peer 11111.... endpoint 1.1.1.1:1501 keepalive-interval 15 allow-ips 0.0.0.0 0.0.0.0 interface Wireguard1 description "VPN 2" security-level public ip address 172.16.2.1 255.255.255.248 wireguard listen-port 1502 wireguard peer 2.2.2.2.... endpoint 2.2.2.2:1502 keepalive-interval 15 allow-ips 0.0.0.0 0.0.0.0 Ну а дальше рулить маршрутизацией?

Добрый день! Есть Kennetic Start KN-1110. Для соединения двух сетей сейчас используется GRE туннель с IPSec. Аппаратный ускоритель обрабатывает только шифрование, хэширование как я понимаю делается программно. Поэтому для ESP настроено AES128-SHA1 Если заменить IPSec на Wireguard (который полностью программный) - будет ли снижение нагрузки на систему? Проверить самостоятельно сложно - рутер стоит далеко с ограниченным доступом.

Недавно в entware обновился dropbear. Добавили поддержку ed25519. Вот только авторы dropbear для большей совместимости перешли для ecdsa на nistp256 вместо nistp512 В ходе обновления генерируется dropbear_ed25519_host_key, но не трогается существующий dropbear_ecdsa_host_key. А он уже не того формата. Dropbear его не грузит с ошибкой. В итоге вместо host key algorithms: ssh-ed25519,ecdsa-sha2-nistp256,ssh-rsa предлагается только host key algorithms: ssh-rsa Если dropbear_ecdsa_host_key перегенировать руками то все приходит в норму

Так в чем проблема делать через GRE туннели? У меня так и сделано. GRE интерфейсы, шифруются strongswan в транспортном режиме. Внутри GRE и статическая маршрутизация и динамическая.

Добрый день. Включён IPv6 segment в режиме mode dhcp Судя по всему разным клиентам выдаются одинаковые адреса. Как посмотреть dhcp6 lease для домашнего сегмента?

Вопрос. А зачем при включённом ipv6 firewall открыты все порты на вход со стороны оборудования провайдера? В цепочке INPUT есть правило разрешающее все для source fe80::/10 В том числе и со стороны WAN интерфейса. По сути с link local адресов провайдера есть полный доступ к маршрутизатору. версия 3.1.10

Прошу прощения за задержку с ответом. Нет, полиси роутинга нет, но есть IPSec site-to-site. Такое впечатление что дергается в момент перестроения IKE SA, а не IPSec SA. Насчёт -w спасибо, попробую.

Забыл добавить - прошивка 2.15.C.5.0-0

Подскажите пожалуйста, как правильно добавлять правила в цепочку PREROUTING в таблицу mangle ? Надо добавить три правила. Через скрипт в /opt/etc/ndm/netfilter.d/ это сделать НЕ ПОЛУЧАЕТСЯ. Скрипт дергается 5-6 раз в секунду. Вот например время когда вызывался скрипт. Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:36 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:49 MSK 2019 Mon Jul 8 06:10:50 MSK 2019 В итоге получается полная каша. Правила или дублируются, или не вставляются. Или вставляется 1-2 из трех. Как ПРАВИЛЬНО это делать?

Нет не надо. В центре для удаленных точек которые за NAT можно не указывать адрес удаленной точки. tunnel source <WAN> или tunnel source auto а tunnel destination вообще не выставляем. Именно так все и работает, адрес автоматически выставляется на основе политики, полученной от IPsec. Можно даже автотуннели настроить, главное что бы имена интерфейсов на разных концах туннеля совпадали. То есть центре создаете интерфейсы Gre1 и Gre2. На первой удаленной точке делаете Gre1 интерфейс, на второй соотвественно Gre2 Все работает. Все описано. Каждая точка стучится в центр, при смене адреса у нее туннель переподнимается автоматом.

bird лучше Белый адрес нужен только для центра звезды.

Натяните везде GRE туннели и их шифруйте IPSec'ом. А там внутрь туннеля по маршрутизации что хотите то и отправляйте. У меня внутри туннелей бегает ospf на базе bird.