Dorik1972

Вводная инструкция - https://xakep.ru/2011/08/23/58089/#toc02. + http://www.linuxcertif.com/man/8/xtables-addons/364384/ ... А дальше каждый "под себя" ... тут нет общего рецепта .. некой "кремлевской таблетки" от всех болезней p.s. на сколько я понимаю то с марта была добавлена поддержка на уровне ядра ... а вот остальное появилось чуть позже в виде opkg install xtables-addons_legacy

Можно и кнопкой )) А можно и по tftpd ему "впихнуть" прошивку для надеги .... НО! Комарады опосля сброса в "заводские" и пернастройки с "нуля" kernel panic больше не ловил ... Зато в 100% случаев из 100 поймал другую неприятность связанную с использованием сервиса DDNS. Трабла наблюдается только на Ultra II и только на текущей "крайней" 2.10.А.3 . Итак : 1) На страничке web-интефейса "Интернет"=>"DDNS" - заполняем свои учетные данные (я и спользую www.noip.com) 2) На страничке "Система"=>"Параметры" - тыцяем "гапочку" на "Доступ к веб-конфигуратору через Интернет:" - порт оставляем по умолчанию - 80-ый 3) Перегружаем (чисто для "самоуспокоения").... пытаемся ломануться на ВАСЯ.ddns.net - И НИФИГА )))) До этого все работало "как часики" ... и продолжает работать что на Giga II что на Extra .... 4) Идем на страничку "Безопасность"=>"Трансляция сетевых адресов (NAT)" ... Руцями рисуем правило проброса из-вне на 192.168.1.1:80 - И ВУАЛЯ ... все теперь работает .... Вроде как раньше при наличии "гапочки" на доступ ... сие правило добавлялось автоматом ? или ? Дальше веселее .... имея БЕЛЫЙ IP (при условии что гапочка разрешения доступа к веб-конфигуратору "ON")..... идем на страничку "Приложения"=>"KeenDNS" - заполняем ВАСЯ.mykeenetic.net .. и говорим - ПРЯМОЙ ДОСТУП (IP-то белый) ... тут же получаем предупреждение что "Прямой доступ невозможен с серым IP-адресом. Используйте режим «Через облако» или приобретите у провайдера белый IP-адрес." что нифига "не белый" .... Если проигнорить предупреждение то без правила проброса 80-ого порта работать НЕ БУДЕТ ..... А через "облако" - "как часы" ... В общем проверьте плиззз .... сдается мне что я не "уникальный" в описанной мной ситуации .....

Первое "падение" Jun 24 20:42:29 Keenetic_Ultra kernel: AP 5GHz: run channel auto-switch Jun 24 20:42:39 192.168.2.1 ndm: kernel: ACS result: primary channel 36, 80 MHz spectrum min dirty (with CCA) = 0 Jun 24 20:42:40 192.168.2.1 wmond: WifiMaster1/AccessPoint0: (MT76x2) BSS(rai0) channel switched to 36. Jun 24 20:45:58 192.168.2.1 ndm: Process: "ARP ping check" has been killed. Jun 24 20:46:37 192.168.2.1 ndm: kernel: AP 2.4GHz: run channel auto-switch Jun 24 20:46:43 192.168.2.1 ndm: kernel: 6>C eut rmr hne ,4 H pcrmmndry(ihCA 4 Jun 24 20:46:43 192.168.2.1 wmond: WifiMaster0/AccessPoint0: (MT76x2) BSS(ra0) channel switched to 1. Jun 24 20:46:48 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0} (t=15000 jiffies) Jun 24 20:46:48 192.168.2.1 ndm: kernel: Call Trace: Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<802d9120>] dump_stack+0x8/0x34 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8007af9c>] __rcu_pending+0x1e0/0x544 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8007bee4>] rcu_check_callbacks+0x118/0x180 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80035b40>] update_process_times+0x48/0x74 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80067a6c>] tick_sched_timer+0x7c/0x34c Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8004c308>] __run_hrtimer.isra.5+0x68/0x138 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8004cdc4>] hrtimer_interrupt+0x1b4/0x4dc Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800119f0>] c0_compare_interrupt+0x64/0x90 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800742ac>] handle_irq_event_percpu+0x70/0x1fc Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80077eec>] handle_percpu_irq+0x8c/0xbc Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80073908>] generic_handle_irq+0x3c/0x54 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8000cb4c>] do_IRQ+0x18/0x2c Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8000af70>] ret_from_irq+0x0/0x4 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8014d8d4>] prio_tree_remove+0x18/0x13c Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800a2360>] unlink_file_vma+0x44/0x80 Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<8009c3f4>] free_pgtables+0xac/0x16c Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<800a4bc8>] exit_mmap+0x108/0x14c Jun 24 20:46:48 192.168.2.1 ndm: kernel: [<80025a90>] mmput+0x44/0x130 Jun 24 20:46:48 192.168.2.1 ndm: kernel: Jun 24 20:49:48 192.168.2.1 ndm: kernel: INFO: rcu_sched self-detected stall on CPU { 0} (t=60003 jiffies) Jun 24 20:49:48 192.168.2.1 ndm: kernel: Call Trace: Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<802d9120>] dump_stack+0x8/0x34 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8007af9c>] __rcu_pending+0x1e0/0x544 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8007bee4>] rcu_check_callbacks+0x118/0x180 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80035b40>] update_process_times+0x48/0x74 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80067a6c>] tick_sched_timer+0x7c/0x34c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8004c308>] __run_hrtimer.isra.5+0x68/0x138 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8004cdc4>] hrtimer_interrupt+0x1b4/0x4dc Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800119f0>] c0_compare_interrupt+0x64/0x90 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800742ac>] handle_irq_event_percpu+0x70/0x1fc Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80077eec>] handle_percpu_irq+0x8c/0xbc Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80073908>] generic_handle_irq+0x3c/0x54 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8000cb4c>] do_IRQ+0x18/0x2c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8000af70>] ret_from_irq+0x0/0x4 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8014d634>] get_index.isra.0.part.1+0x4/0x2c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8014d970>] prio_tree_remove+0xb4/0x13c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800a2360>] unlink_file_vma+0x44/0x80 Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<8009c3f4>] free_pgtables+0xac/0x16c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<800a4bc8>] exit_mmap+0x108/0x14c Jun 24 20:49:48 192.168.2.1 ndm: kernel: [<80025a90>] mmput+0x44/0x130 Jun 24 20:49:48 192.168.2.1 ndm: kernel: Второе "падение" - точно такое же ... Пока что сбросил в "заводские" и перенастроил все с "нуля" .... Мало ли "криво" прошивка лягла ... еще раз помрет - сброшу и селф-тест и собственно лог ...

НЕТ. На USB 3.0 "навешен" HDD c Etnware 3x .

Завтра до 13-00 по MSK сделаю . Не на "базе" .... после перегруза по питанию пару часов "живет нормальной" жизнью )) Так что self-test - не проблема. Заметил что пациент "перед смертью" переставал откликаться на 80-ом порту. Чрез DDNS напрочь не хотел давать доступ. При этом IP пингуется и в "рабочем кабинете" на no-ip рефрешится из web-интерфейса Ultra II. Тест "из вне" говорит что 80 порт открыт. Перешел на XXXX.mykeenetic.net - не дает "прямого доступа" , только через облако. Хотя IP - "белый". Через "облако" - работало ... но и в итоге "помер" . Провайдеру "мозг вынес" , клянется что изменений НОЛЬ .... за 2-ое суток просмотрели лог подключений - ошибок нет. Было одно "мусорное" подключение когда вместо родного IP была попытка подключения роутера с IP 78.47.125.180 . Подозреваю что это XXXX.mykeenetic.net в момент попытки "прямого доступа" - по времени в аккурат совпало с перенастройкой с DDNS на mykeenetic.net) . От прова - тоже пинговался, пока не "помер". IP- неизменен на протяжении 5-ти лет . p.s. Мобильное приложение My.Keenetic (android) - показывает что роутер в сети но при попытке войти - "Подключение отклонено Интернет-центром, не включен модуль удаленного доступа" . При этом "родной" IP - не пингуется ......

Сделать смогу завтра так как не дома. Поймал с утра ... дважды. В третий раз , судя по всему, "помер" уже на удаленке . Физически не доступен на данный момент". Ping-чекер не задействован. К сожалению писал "по памяти".

Поймал ТОЧНО такйю же "неприятность" после перехода на своей Ultra II на 2.10.A.3.0-0 .... Спасает только ребут по питанию ... Работает недолго 2-3 часа .. и снова ... бегом к роутеру "штепсель" выдергивать ..... Как побороть неприятность ?

2.10.A.2.0-0 В прошлый раз "не доглядели" в это раз "подзабыли" Отображение состояния IPSec VPN в web-интерфйесе не поправили. Не критично но .... так для порядку

Прежде всего СПС ! Разрабам за великолепный продукт А теперь немного картинок. Имеем связку Zyxel Ultra II и Giga II (Дом-Дача ...Классика )после обновления IPSec прекрасно работает но! На "Системный монитор"->"IPSec VPN" подключение не отображается ну никак ..... Это лог полключения "клиента" Giga II ("клиент") + лог Ultra II ("сервер") + "Состояние подключения" (одинаково на обоих устройствах)

Я в курсе .... тестировалось раздельно ..... это потом уже в качестве эксперимента - virtual ip ... Но чудо таки свершилось ... после 100500 перегрузок "сервера" и "клиента" , и НИЧЕГО не меняя в настройках соединения, все ожило ..... Продолжаю наблюдать .....

Я пробовал как IP так и e-mail и FQDN .... собственно это , если следовать "классике" не особо важно ... Главное чтобы совпадало на обоих устройствах ... Да и какое отношение имеет идентификатор к неработающей "связке" MacOS и Сервер IPsec Virtual IP ? Тут скорее всего дело в Apr 30 09:11:48ipsec07[IKE] linked key for crypto map '(unnamed)' is not found, still searching Apr 30 09:11:48ipsec07[IKE] no shared key found for 'UltraII-IP'[UltraII-IP] - '(null)'[GigaII-IP] Apr 30 09:11:48ipsec07[IKE] no shared key found for UltraII-IP - GigaII-IP Одинаково "грустно" в обоих случаях .... ибо до этого момента - все ОК, судя по логам .....

Имеем связку Клиент - Giga II ("белый" IP) 2.09.A.6.0-3 "Сервер" - Ultra II ("белый" IP) 2.09.A.7.0-0 Все настроено согласно "предписаний" - https://help.keenetic.net/hc/ru/articles/214471405-Организация-туннеля-IPSec-VPN-между-двумя-интернет-центрами-Keenetic-Ultra-II-и-Giga-III "связка" никак не вяжется ни при каких "танцах с бубном" .... Фаза1 и Фаза2 настроены "один в один" , ключ PSK совпадает и проверялся 100раз , IKE v1 или v2 - безрезультатно ...... Посоветуте "таблетку" .... ибо все пропало ! в логе на Ultra II -> Apr 30 09:11:48ipsec08[IKE] received DPD vendor ID Apr 30 09:11:48ipsec08[IKE] received FRAGMENTATION vendor ID Apr 30 09:11:48ipsec08[IKE] received NAT-T (RFC 3947) vendor ID Apr 30 09:11:48ipsec08[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Apr 30 09:11:48ipsec08[IKE] GigaII-IP is initiating a Main Mode IKE_SA Apr 30 09:11:48ipsec08[CFG] received proposals: IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768/# Apr 30 09:11:48ipsec08[CFG] configured proposals: IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768/# Apr 30 09:11:48ipsec08[CFG] selected proposal: IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768/# Apr 30 09:11:48ipsec08[IKE] sending DPD vendor ID Apr 30 09:11:48ipsec08[IKE] sending FRAGMENTATION vendor ID Apr 30 09:11:48ipsec08[IKE] sending NAT-T (RFC 3947) vendor ID Apr 30 09:11:48ipsec07[IKE] linked key for crypto map '(unnamed)' is not found, still searching Apr 30 09:11:48ipsec07[IKE] no shared key found for 'UltraII-IP'[UltraII-IP] - '(null)'[GigaII-IP] Apr 30 09:11:48ipsec07[IKE] no shared key found for UltraII-IP - GigaII-IP В web-интерфейсе GigaII при попытке редактирования пропадают адреса -> Дальше - еще больше ))) Создаем на Ultra II - Сервер IPsec Virtual IP Подключаемся с компа (MacOS) Apr 30 09:39:17ipsec13[IKE] received NAT-T (RFC 3947) vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID Apr 30 09:39:17ipsec13[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID Apr 30 09:39:17ipsec13[IKE] received XAuth vendor ID Apr 30 09:39:17ipsec13[IKE] received Cisco Unity vendor ID Apr 30 09:39:17ipsec13[IKE] received FRAGMENTATION vendor ID Apr 30 09:39:17ipsec13[IKE] received DPD vendor ID Apr 30 09:39:17ipsec13[IKE] GigaII-IP is initiating a Main Mode IKE_SA Apr 30 09:39:17ipsec13[CFG] received proposals: IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_2048/#, IKE:AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_1536/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1536/#, IKE:AES_CBC=256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:AES_CBC=256/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:AES_CBC=128/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024/#, IKE:3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024/#, IKE:DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#, IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024/# Apr 30 09:39:17ipsec13[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# Apr 30 09:39:17ipsec13[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/# Apr 30 09:39:17ipsec13[IKE] sending XAuth vendor ID Apr 30 09:39:17ipsec13[IKE] sending DPD vendor ID Apr 30 09:39:17ipsec13[IKE] sending Cisco Unity vendor ID Apr 30 09:39:17ipsec13[IKE] sending FRAGMENTATION vendor ID Apr 30 09:39:17ipsec13[IKE] sending NAT-T (RFC 3947) vendor ID Apr 30 09:39:17ipsec14[IKE] remote host is behind NAT Apr 30 09:39:17ipsec14[IKE] linked key for crypto map '(unnamed)' is not found, still searching Apr 30 09:39:17ipsec14[IKE] no shared key found for 'mykeenetic.net'[UltraII-IP] - '(null)'[GigaII-IP] Apr 30 09:39:17ipsec14[IKE] no shared key found for ULtraII-IP - GigaII-IP И как теперь удаленно добираться в локальную сеть ? Заранее благодарен за помощь в решении описанных проблем ....

Если речь идет о edem, ott и т.д. - ДА там ссылка уже готовая.... В данном конкретном случае и в случае с acestream engine, для которого. тоже скриптик имеется, необходимо "формирование" плейлиста по шаблону под себя . Но это уже "разговор" из другой темы и не данного форума. Жму руку! p.s. Тут такое ... если пользователям сия инфа бесполезна .... УДАЛЮ ТЕМУ .... через недельку ! ОК? А вот если будут "Like"-и ... оставлю.

легко ... думаю "страждущие" и "нуждающиеся" сам под себя "подковыряют" готовое решение. Все же проще чем "с нуля" самому писать ... или ?

Спс за замечание .... заголовок заменю ... на "Автоматизация раздачи плейлиста для noxbit по расписанию" ? или предложите название темы. Думаю она представляет интерес "как готовое решение"