gaaronk
Участники форума-
Постов
343 -
Зарегистрирован
-
Победитель дней
3
Тип контента
Профили
Форумы
Галерея
Загрузки
Блоги
События
Весь контент gaaronk
-
Хорошая мысль, да. Проклятый Silicon Power. В помойку его.
-
Товарищи учёные! У меня в подвале происходит подземный стук... Keenetic DUO. 3.5.6 Пять раз ставил entware. На разные разделы. Форматировал ext2, ext3, ext4. Линуксом и самим entware. Флешка 8 гиг, раздел создается размером в 1 гиг. Ставится пачка пакетов. Занято порядка 40 мегабайт. Все хорошо. пакеты ставятся, все конфигурируется. Команда sync отрабатывает.В логах чисто. Каждый раз после смены перезагрузки файловая система разлетается на куски. Директория etc читается частично. Внезапно показывает занятого места 300-400 мегабайт Куча ошибок вида EXT4-fs error (device sda1): ext4_mb_generate_buddy:756: group 1, block bitmap and bg descriptor inconsistent: 30068 vs 30073 free clusters EXT4-fs (sda1): initial error at time 1610570814: ext4_lookup:1591: inode 15649 EXT4-fs (sda1): last error at time 1610573351: ext4_mb_generate_buddy:756 EXT4-fs error (device sda2): __ext4_new_inode:864: comm mkdir: reserved inode found cleared - inode=5 EXT4-fs error (device sda1): ext4_mb_generate_buddy:756: group 1, block bitmap and bg descriptor inconsistent: 29955 vs 29978 free clusters EXT4-fs error (device sda1): ext4_mb_generate_buddy:756: group 2, block bitmap and bg descriptor inconsistent: 32273 vs 32274 free clusters До ребута все хорошо. Делаешь sync - все хорошо. Перезагрузка и кранты.
-
Ох. Заголовок неверный. Так проблема только с HTTPS. Просто HTTP, ssh, telnet в тот же самый момент работают юзе проблем.
-
Ну у меня специфические задачи. Мне гарное аппарате (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 спасибо, попробую.
