Перейти к содержимому
Калькуляторы

alexdirty

Пользователи
  • Публикации

    55
  • Зарегистрирован

  • Посещение

Сообщения, опубликованные пользователем alexdirty


  1. Возможно это даёт отсрочку 60 дней на реализацию, после первого получения перечня.

    Постановление Правительства РФ от 29 декабря 2021 г. № 2531 “Об утверждении Правил ведения перечня отечественных социально значимых информационных ресурсов” - Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций не позднее 7-го календарного дня со дня утверждения или актуализации перечня направляет его посредством информационной системы взаимодействия операторам связи, указанным в пункте 53 статьи 46 Федерального закона "О связи", для осуществления технических настроек, необходимых ввиду актуализации перечня, в течение 60 календарных дней со дня получения перечня.

  2. У меня по 221 приказу в ЛК единого портала пользователей ЦМУ ССОП вдруг пропала информация по ранее загруженным файлам. А так же, похоже, что появилась возможность передать информацию путём заполнения WEB форм.

  3. Да, спасибо. И правда. Сразу не проверил.

     

    2020-10-17 11:00:14,705  New Item, IP, Domain, URL id: 2293300.
    2020-10-22 16:57:22,954  Full delete Item, IP, Domain, URL id: 2293300.

     

    А пропуск зафиксирован 22.10.2020 в 23:38:29. Весело.

  4. А ни у кого нет пропусков от 22.10.2020 по https урлам смотретьвидео.рф ?
    Какие то непонятки. В реестре нет (который я получаю), в отчётах от ревизора есть.

  5. 51 минуту назад, alexdirty сказал:

    Интересно, а как понимать поле  "Обяз" с пустым значением, т.е. не "0..." и не "1" ?

    Ответили из ЦМУ ССОП

     

    Цитата

    Данные поля опциональны для заполнения. Так как форма универсальная не все поля актуальны для каждого пользователя.

     

  6. В 02.06.2020 в 07:27, bos9 сказал:

    Я правильно понимаю, что элементы, содержащие в поле "Обяз" значение "0...", являются не обязательными (указываются ноль или более раз)?

    Интересно, а как понимать поле  "Обяз" с пустым значением, т.е. не "0..." и не "1" ?

  7. В 16.05.2020 в 18:51, ingvarrwvw сказал:

    Коллеги,добрый день.

     

    NAT на ASR 1006 наблюдаем такую штуку каждый день - в одно и тоже время падает трафик процентов на 30 кратковременно,потом снова восстанавливается. При этом потерь и задержек в это время нет, но в целом есть жалобы на услугу, появились именно с вводом в эксплуатацию 1006.

     

    Версия текущая asr1000rp2-adventerprisek9.03.16.08.S.155-3.S8-ext.b

     

    Только NAT BGP на ней. Настройки нат:

     

    ip nat settings mode cgn
    no ip nat settings support mapping outside
    ip nat settings pap limit 60 
    ip nat translation timeout 3600
    ip nat translation tcp-timeout 3600
    ip nat translation pptp-timeout 3600
    ip nat translation udp-timeout 60
    ip nat translation icmp-timeout 30
    ip nat translation max-entries 4000000
    no ip nat service all-algs
     

    В acl для nat отдельно протоколы - tcp udp и т.д. В пики количество сессий около 1 млн. В логах пусто.

     

    Может прошивку поменять? Поделитесь стабильной,если имеется. Спасибо заранее

    Вопросы из опыта эксплуатации 1004 (не знаю на сколько сильно отличается от 1006):

    1. В одно и тоже время, это в ЧНН?

    2. Общий rate на вход и выход перед "падением" и после "восстановления" насколько отличается?

    3. Нет ли ошибок/дропов на интерфейсах ASR и на железе до/после?

    4. Жалобы от клиентов какого рода?

    5. Начните "рисовать" график утилизации QFP. У меня на 1004 в CLI доступен по

    show platform hardware qfp active datapath utilization qfp 0

    а по SNMP iso.3.6.1.4.1.9.9.715.1.1.6.1.14.9027.1 на одной и iso.3.6.1.4.1.9.9.715.1.1.6.1.14.9037.1 на другой.

    6. Соответственно и графики трафика, cpu, количества трансляций в эти моменты может что-то подскажут.

  8. В 14.09.2019 в 06:29, zhenya` сказал:

    Это не езерченел падает, а QFP.

    Да, верно, QFP.   Кстати, как то раз после очередного Clear, QFP снова упал, и причём снова после того как clear был сделан для второго серого IP, а с первым всё было ОК.  На Cisco Bug`e позже увидел несколько багов, которые описывают crash после Clear трансляций. Один из них https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvn49911, т.е. временное решение это не делать show ip nat tra в течении первых 20 секунд после clear... Весело.

     

  9. В 22.04.2020 в 07:56, ShyLion сказал:

     

    Это SIP ALG так чудит

      

    
    no ip nat service sip tcp port 5060
    no ip nat service sip udp port 5060

    Очистить трансляции:

     

    
    clear ip nat translation inside REAL_IP PRIVATE_IP

     

    У меня это не SIP так чудит. У меня это GRE так чудит. Проверил, произвёл попытку поднять GRE туннель, освободил серый IP (т.е. на сером IP нет никакого хоста), и вот уже как месяц эта трансляция активна.
     

     

    В 22.04.2020 в 09:49, Andrei сказал:

    А просто

    ip nat translation timeout 400

    не спасает ситуацию?

    По таймауту трансляции сбрасываются, все, кроме проблемных с сессией GRE.

  10. В 08.02.2016 в 11:20, kvinogradov сказал:

    Приветствую, коллеги!

     

    Есть вопрос про PPTP через NAT. Если верить описанию ALG, то они не работают с CGN:

     

     

    Поэтому сразу:

     

     

    
    no ip nat service all-algs
     

     

     

    Без этого все вообще грустно.

     

    А абонентам нужно пользоваться PPTP (не смотри, что уже и сма Microsoft твердит, что протоколу давно пора на свалку истории). Естественно в режиме overload-NAT PPTP работает не очень, т.к. периодически управляющая TCP-сессия на порт 1723 транслируется в один "белый" адрес, а GRE-туннель в другой. Как решение, пробую выделить этот трафик (TCP/1723 и GRE) в отдельный NAT без overload. Выделяю "белых" адресов под это дело побольше (в моем случае 1024).

     

    Пока не весь пул утилизирован - все хорошо. PPTP поднимается. Весь остальной трафик идет через oveload-NAT. Что бы сессии не висели вечно ставлю тайм-аут в 8 минут.

     

    Вот тут и возникает проблема, которая, как я понял, в следующем "белые" адреса регулярно сканируются извне (раз в 1.5-2 минуты прилетает) различными искателями открытых уязвимостей. Получается что на любой адрес периодически прилетает пакет (порт не важен, так как трансляция не overloaded). Периодичность эта меньше, чем таймаут NAT-трансляции (стандартный keepalive interval для PPTP 60 секунд, таймаут 60*3=180 секунд).

     

    Получается что трансляция сама не умирает, адрес не высвобождается. Через какой-то время пул исчерпывается и новые сессии PPTP у абонентов перестают работать. За этим NAT-ом находятся абоненты с динамическими серыми адресами с таймаутом PPPoE 24 часа. Т.е. трафик "снизу" для трансляции точно прекращается максимум через сутки. При этом на ASR есть трансляции по несколько дней.

     

    Кто нибудь знает, как такое побороть можно?

     

    Заранее спасибо!

    Подскажите, как с аналогичной проблемой боритесь?

     

     

    Трансляции могут и больше недели висеть для протоколов отличных от icmp/tcp/udp (со стороны клиента и сервера активности никакой нет по этому соединению (это GRE)):

     

    ---  *.*.*.*         *.*.*.*           ---                   ---

      create: 04/13/20 02:26:03, use: 04/21/20 09:44:10, timeout: 00:01:59
      Map-Id(In): 1
      Appl type: none
      Mac-Address: 0000.0000.0000    Input-IDB: Port-channel3.22
      entry-id: 0x0, use_count:159

     

     

    Более того, трансляция создаётся по любому порту при получении любого пакета из WAN. Таким образом nonpat трансляция никогда не освободится и исчерпание пула не за горами.

  11. Обновился на asr1000rp2-adventerprisek9.03.16.07b.S.155-3.S7b-ext.bin

     

    1. ip nat translation max-entries all-host - заработал

     

    2. crash с падением Etherchannel после clear трансляций - остался

     

    По второму пункту дополню:

    Clear трансляций на конкретном Inside не работает если в этот момент у клиента ходит трафик. Shutdown`ишь порт клиенту, что бы трафика не было, и тогда Clear работает.

    Clear трансляций на конкретном Inside c указанием протокола и портов - работает.
    После Clear трансляций у двух абонентов, как раз и произошёл снова crash с падением Etherchannel, через 7 минут линки поднялись.

     

     

    Sep 13 12:47:40: %CPPHA-3-FAULT: F0: cpp_ha:  CPP:0.0 desc:DPE4_CPE_CPE_DPE_INT_SET_0_LEAF_INT_INT_S4_WPT_ERROR det:DRVR(interrupt) class:OTHER sev:FATAL id:1602 cppstate:RUNNING res:UNKNOWN flags:0x7 cdmflags:0x0
    Sep 13 12:47:40: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_ha:  cpp_ha encountered an error -Traceback= 1#a987b1e8e3da18d823a6a09623b64c75   errmsg:7F3D12288000+121D cpp_common_os:7F3D15D98000+DA3C cpp_common_os:7F3D15D98000+1B5AE cpp_drv_cmn:7F3D155C3000+285B7 :400000+244A9 :400000+23F6C :400000+23993 :400000+1374D :400000+1272C cpp_common_os:7F3D15D98000+11C20 cpp_common_os:7F3D15D98000+12306 evlib:7F3D11202000+B937 evlib:7F3D11202000+E200 cpp_common_os:7F3D15D98000+13E42 :400000+DA85 c:7F3D09A74000+1E514 :4000
    Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha:  CPP 0.0 unresolved fault detected, initiating crash dump.
    Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha:  CPP 0.0 unresolved fault detected, initiating crash dump.
    Sep 13 12:47:40: %CPPHA-3-FAULT: F0: cpp_ha:  CPP:0.0 desc:INFP_INF_SWASSIST_LEAF_INT_INT_EVENT0 det:DRVR(interrupt) class:OTHER sev:FATAL id:2121 cppstate:RUNNING res:UNKNOWN flags:0x7 cdmflags:0x8
    Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha:  CPP 0.0 unresolved fault detected, initiating crash dump.
    Sep 13 12:47:40: %CPPHA-3-FAULTCRASH: F0: cpp_ha:  CPP 0.0 unresolved fault detected, initiating crash dump.
    Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0:  CPP10(0) Interrupt : Last 16 Interrupts Since Boot 
    Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0:  CPP10(0) Interrupt : 19-Sep-13 12:47:40.093120 UTC+0300:DPE4_CPE_CPE_DPE_INT_SET_0_LEAF_INT_INT_S4_WPT_ERROR 
    Sep 13 12:47:40: %CPPDRV-6-INTR: F0: cpp_driver-0:  CPP10(0) Interrupt : 19-Sep-13 12:47:40.093120 UTC+0300:INFP_INF_SWASSIST_LEAF_INT_INT_EVENT0 
    Sep 13 12:47:40: %CPPDRV-3-LOCKDOWN: F0: cpp_cp:  QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt).
    Sep 13 12:47:40: %IOSXE_OIR-6-OFFLINECARD: Card (fp) offline in slot F0
    Sep 13 12:47:40: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_cp:  cpp_cp encountered an error -Traceback= 1#3379fd703db39406a2190384a97f7318   errmsg:7FF0960E8000+121D cpp_common_os:7FF09956F000+DA3C cpp_common_os:7FF09956F000+1B5AE cpp_nat_svr_lib:7FF0A2DC3000+2E86D cpp_nat_svr_lib:7FF0A2DC3000+1C770 cpp_nat_svr_lib:7FF0A2DC3000+1CAFE cpp_nat_svr_smc_lib:7FF0A306A000+1B61 cpp_common_os:7FF09956F000+11C20 cpp_common_os:7FF09956F000+12306 evlib:7FF0982E1000+B937 evlib:7FF0982E1000+E200 cpp_common_os:7FF09956F000+13
    Sep 13 12:47:41: %CPPDRV-3-LOCKDOWN: F0: fman_fp_image:  QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt).
    Sep 13 12:47:47: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Standby -> Active
    Sep 13 12:48:13: %CPPCDM-3-ERROR_NOTIFY: F0: cpp_cdm:  QFP 0 thread 9 encountered an error -Traceback= 1#6df0c3e14153553c3f59b148c44ae86f 8035F39B 80347CB4 8035F3BC 8033B2B0 8033B35C 8033B4A6 8043B8B1 8043CBF2 
    Sep 13 12:48:13: %IOSXE-3-PLATFORM: F0: cpp_cdm: CPP crashed, core file /tmp/corelink/ASR1004-NEW_ESP_0_cpp-mcplo-ucode_091319124813.core.gz
    Sep 13 12:48:51: TenGigabitEthernet1/2/0 taken out of port-channel1
    Sep 13 12:48:52: TenGigabitEthernet1/1/0 taken out of port-channel2
    Sep 13 12:48:55: %EC-5-MINLINKS_NOTMET: Port-channel Port-channel2 is down bundled ports (0) doesn't meet min-links
    Sep 13 12:48:55: TenGigabitEthernet1/3/0 taken out of port-channel2
    Sep 13 12:48:55: %EC-5-MINLINKS_NOTMET: Port-channel Port-channel1 is down bundled ports (0) doesn't meet min-links
    Sep 13 12:48:55: TenGigabitEthernet1/0/0 taken out of port-channel1
    Sep 13 12:48:57: %LINK-3-UPDOWN: Interface Port-channel2, changed state to down
    Sep 13 12:48:57: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Active -> Init
    Sep 13 12:48:57: %LINK-3-UPDOWN: Interface Port-channel1, changed state to down
    Sep 13 12:48:57: %HSRP-5-STATECHANGE: Port-channel1.22 Grp 1 state Active -> Init
    Sep 13 12:48:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel2, changed state to down
    Sep 13 12:48:58: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to down
    Sep 13 12:49:38: %CPPHA-3-FAULT: F0: cpp_ha:  CPP:0.0 desc:CPP Client process failed: FMAN-FP det:HA class:CLIENT_SW sev:FATAL id:1 cppstate:RUNNING res:UNKNOWN flags:0x0 cdmflags:0x0
    Sep 13 12:49:38: %CPPOSLIB-3-ERROR_NOTIFY: F0: cpp_ha:  cpp_ha encountered an error -Traceback= 1#a987b1e8e3da18d823a6a09623b64c75   errmsg:7F3D12288000+121D cpp_common_os:7F3D15D98000+DA3C cpp_common_os:7F3D15D98000+1B5AE cpp_drv_cmn:7F3D155C3000+285B7 :400000+24438 :400000+23C1A :400000+14617 :400000+C0DE :400000+129AD :400000+F9E6 :400000+13B62 cpp_common_os:7F3D15D98000+1257F evlib:7F3D11202000+B937 evlib:7F3D11202000+E200 cpp_common_os:7F3D15D98000+13E42 :400000+DA85 c:7F3D09A74000+1E514 :400000+83E9
    Sep 13 12:49:38: %PMAN-3-PROCHOLDDOWN: F0: pman.sh:  The process fman_fp_image has been helddown (rc 134)
    Sep 13 12:49:38: %PMAN-0-PROCFAILCRIT: F0: pvp.sh:  A critical process fman_fp_image has failed (rc 134)
    Sep 13 12:53:38: %IOSXE_OIR-6-ONLINECARD: Card (fp) online in slot F0
    Sep 13 12:53:56: TenGigabitEthernet1/1/0 added as member-1 to port-channel2
    Sep 13 12:53:57: TenGigabitEthernet1/2/0 added as member-1 to port-channel1
    Sep 13 12:53:58: TenGigabitEthernet1/0/0 added as member-2 to port-channel1
     Sep 13 12:53:58: %LINK-3-UPDOWN: Interface Port-channel2, changed state to up
    Sep 13 12:53:59: %LINK-3-UPDOWN: Interface Port-channel1, changed state to up
    Sep 13 12:53:59: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel2, changed state to up
    Sep 13 12:54:00: %LINEPROTO-5-UPDOWN: Line protocol on Interface Port-channel1, changed state to up
    Sep 13 12:54:05: TenGigabitEthernet1/3/0 added as member-2 to port-channel2
    Sep 13 12:54:21: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Standby -> Active
    Sep 13 12:54:22: %HSRP-5-STATECHANGE: Port-channel1.22 Grp 1 state Standby -> Active
    Sep 13 12:54:27: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Active -> Speak
    Sep 13 12:54:37: %HSRP-5-STATECHANGE: Port-channel2.23 Grp 1 state Speak -> Standby

     

     

    А теперь собственно, сама причина, зачем сбрасывал трансляции.

    sh ip nat statistics 
    Total active translations: 365689 (0 static, 365689 dynamic; 365372 extended)
    ....
    [Id: 1] access-list NAT-USERS pool Pool-1 refcount 194255
     pool Pool-1: id 1, netmask 255.255.255.0
        start *.*.*.* end *.*.*.*
        type generic, total addresses 256, allocated 256 (100%), misses 10
    [Id: 2] access-list NAT-USERS2 pool Pool-2 refcount 171434
     pool Pool-2: id 2, netmask 255.255.255.0
        start *.*.*.* end *.*.*.*
        type generic, total addresses 256, allocated 169 (66%), misses 0
    .....

     

     

    Из-за того что один из pool адресов на 100% был утилизирован из-за трансляций 1-to-1 по протоколам отличных от TCP/UDP/ICMP, и полетели тикеты на нерабочий GRE с вытекающей ошибкой 

    Sep 13 09:57:40: %IOSXE-6-PLATFORM: F0: cpp_cp: QFP:0.0 Thread:128 TS:00013985005758018400 %NAT-6-ADDR_ALLOC_FAILURE: Address allocation failed; pool 1 may be exhausted

    Количество таких трансляций было = 330 (sh ip nat translations | exclude tcp|udp|icmp)

     

     

     

    Количество используемых адресов в PAP было всего 107.

    show platform hardware qfp active feature nat datapath pap laddrpergaddr | count gaddr
    
    Number of lines which match regexp = 107

     

    Количество трансляций 1-to-1, отсутствующих по количеству используемых адресов в PAP, достигло 318 (256+169-107).

     

     

    Access листы для pool`ов были 

    permit ip ..... any

    Теперь сделал

    permit tcp ..... any
    permit udp ..... any
    permit icmp ..... any
    permit gre ..... any

     

    Ну собственно после чистки трансляций и crash`a стало:

     

    Total active translations: 362963 (0 static, 362963 dynamic; 362960 extended)
     

    [Id: 1] access-list NAT-USERS pool Pool-1 refcount 187744
     pool Pool-1: id 1, netmask 255.255.255.0
        start *.*.*.* end *.*.*.*
        type generic, total addresses 256, allocated 42 (16%), misses 0
    [Id: 2] access-list NAT-USERS2 pool Pool-2 refcount 175220
     pool Pool-2: id 2, netmask 255.255.255.0
        start *.*.*.* end *.*.*.*
        type generic, total addresses 256, allocated 36 (14%), misses 0

     

    Посмотрим как много будет трансляций вне PAP с применёнными access листами permit tcp/udp/icmp/gre... Пока, всего 15.

  12. Коллеги, прошу подсказать, какой софт показал себя более стабильным и без багов для ASR1004 (RP2) на данный момент?

     

    На древнем софте 15.4(3)S1 после нескольких лет стабильности столкнулись с:

    - не работающим  ip nat translation max-entries all-host;

    - %NAT-6-ADDR_ALLOC_FAILURE: Address allocation failed;
    - дропы GRE;

    - crash с падением Etherchannel после clear транслиций %CPPDRV-3-LOCKDOWN: F0: cpp_cp:  QFP0.0 CPP Driver LOCKDOWN encountered due to previous fatal error (HW: QFP interrupt).

  13. 1 час назад, ixi сказал:

    Нам на емейл с вопросом по этим пропусками ответили, что нарушений у нас нет (без деталей). Похоже, эти пропуски не засчитали

    А при этом в отчёте по пропускам в "Количество нарушений (записей реестра)" какая цифра стоит?

     

    blob.thumb.png.40ba2ea10bae1a1dbc34a5c00a6e774f.png

  14. 1 час назад, hsvt сказал:

    RKN last dump date: 1524739020 не меняется с 15:00 по мск и новых записей нет.

    Пришло https://pastebin.com/nh2aWTDb

    И Яндекс с ВК под раздачу попали. Да и чего там только нет. Обновление дампа от 00:06. Записи в реестр добавлены между 15:00 и 00:06, а ревизор уже пропусков нафиксил.

     

    А чем им NTP сервер 194.190.168.1 то помешал от MSK-IX?

  15. 17 часов назад, swsn сказал:

    тоже сегодня автоматизировал формирование конфига private-address из дампа  и завернул трафик на unbound, активно тестирую уже на юзерах. Спасибо за идею, изящное решение.)

    А как у Вас отработается запрос, например cdn.samsungcloudsolution.com, если

     

    Авторитативным DNS сервером отдаются заблоченные из 52.192.0.0/11:

    52.222.149.208
    52.222.149.73
    52.222.149.2
    52.222.149.142
    52.222.149.76
    52.222.149.145
    52.222.149.158
    52.222.149.106

     

    Но, мы знаем, что в интернете есть ещё другие авторитативные сервера которые отдают:

     

    13.33.23.230
    54.192.98.7
    54.192.98.82
    54.192.98.84
    54.192.98.139
    54.192.98.172
    54.192.98.216
    54.192.98.228
    54.192.98.231
    13.33.23.8
    13.33.23.85
    13.33.23.87
    13.33.23.138
    13.33.23.155
    13.33.23.156
    13.33.23.166

    Но, Вашему DNS серверу авторитатативный всегда отдаёт из 52.192.0.0/11.

     

    Другое дело когда на запрос получаем список IP в котором часть заблочена, а другая часть нет.

  16. 7 часов назад, swsn сказал:

    тоже сегодня автоматизировал формирование конфига private-address из дампа  и завернул трафик на unbound, активно тестирую уже на юзерах. Спасибо за идею, изящное решение.)

    А как unbound по производительности в отличии от Bind себя поведёт при большом количестве юзеров >10k ?

  17. Умственные способности "блокировщиков" не перестают удивлять.

     

    Что они хотели добиться этими url`ами в ресеетре?:
     

    http://1000symbols.ru/?utm_source=google.ru
    http://1000symbols.ru/?utm_source=www.google.ru

     

     

    В 24.04.2018 в 09:13, Antares сказал:

    Тоже со вчерашнего дня такие "пропуски"

    Это они так детектят пропуски по IP. Ломятся на IP, а там редирект. И в пропуск пишут уже domain после редиректа.

  18. 7 минут назад, swsn сказал:

    Нет, и в истории не наблюдаю такого url

    А, нашёл, это они так проверяют блокировку по подсетям. Ломанулись на http://18.197.0.0 и https://18.197.0.0 и получив редирект на www.mepin.com зафиксировали таким образом пропуск.

     

    Адрес перенаправления
    С: http://18.197.0.0 (18.197.0.
    0), https://18.197.0.0/ (18.
    197.0.0)

    Была необходимость на несколько секунд роуты погасить (((

  19. extFilter проработал почти сутки и упал.

    При запуске:

    Syntax error: Cannot convert to boolean: none

    Подскажите пожалуйста, куда смотреть.

     

    UPD1: сейчас пересмотрю конфиг, т.к. с дефолтным конфигом уже другие, соответствующие ошибки.

    UPD2: пардон, всё летатет ;)  Сам в конфиг вписал none, там где должно быть false.

     

    max197616, спасибо огромное за твой труд!

  20. 2 часа назад, yKpon сказал:

    @arhead благодарю, теперь блокирует нормально, но! прошу не пинать за то, что я до сих пор сижу на nfqfilter, в общем нет блокировки по домену, допустим telegramproxy.com и hello.opentg.us есть в domains, но они не блокируются

     

    да и ещё много таких

    Тоже самое было на nfqfilter. Запустил extFilter, стало норм. Теперь оба молотят.