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

Huko

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

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

  • Посещение

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


  1. Spoiler
    
    # uname -a
    Linux nat 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux
    
    
    # make
    make -C /lib/modules/4.19.0-8-amd64/build/ M=/usr/local/src/xt_NAT modules CONFIG_DEBUG_INFO=y                                                                                   
    make[1]: Entering directory '/usr/src/linux-headers-4.19.0-8-amd64'
      CC [M]  /usr/local/src/xt_NAT/xt_NAT.o
    /usr/local/src/xt_NAT/xt_NAT.c: In function ‘stat_seq_show’:
    /usr/local/src/xt_NAT/xt_NAT.c:1547:43: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Active NAT sessions: %ld\n", atomic64_read(&sessions_active));
                                             ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                             %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1548:42: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Tried NAT sessions: %ld\n", atomic64_read(&sessions_tried));
                                            ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                            %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1549:44: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Created NAT sessions: %ld\n", atomic64_read(&sessions_created));
                                              ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                              %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1550:41: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "DNAT dropped pkts: %ld\n", atomic64_read(&dnat_dropped));
                                           ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1551:39: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Fragmented pkts: %ld\n", atomic64_read(&frags));
                                         ~~^     ~~~~~~~~~~~~~~~~~~~~~
                                         %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1552:41: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Related ICMP pkts: %ld\n", atomic64_read(&related_icmp));
                                           ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                           %lld
    /usr/local/src/xt_NAT/xt_NAT.c:1553:36: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘s64’ {aka ‘long long int’} [-Wformat=]               
         seq_printf(m, "Active Users: %ld\n", atomic64_read(&users_active));
                                      ~~^     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                      %lld
    /usr/local/src/xt_NAT/xt_NAT.c: In function ‘nat_tg_init’:
    /usr/local/src/xt_NAT/xt_NAT.c:1664:5: error: implicit declaration of function ‘setup_timer’; did you mean ‘sk_stop_timer’? [-Werror=implicit-function-declaration]              
         setup_timer( &sessions_cleanup_timer, sessions_cleanup_timer_callback, 0 );
         ^~~~~~~~~~~
         sk_stop_timer
    cc1: some warnings being treated as errors
    make[4]: *** [/usr/src/linux-headers-4.19.0-8-common/scripts/Makefile.build:315: /usr/local/src/xt_NAT/xt_NAT.o] Error 1                                                         
    make[3]: *** [/usr/src/linux-headers-4.19.0-8-common/Makefile:1537: _module_/usr/local/src/xt_NAT] Error 2                                                                       
    make[2]: *** [Makefile:146: sub-make] Error 2
    make[1]: *** [Makefile:8: all] Error 2
    make[1]: Leaving directory '/usr/src/linux-headers-4.19.0-8-amd64'
    make: *** [Makefile:11: xt_NAT.ko] Error 2

     

    ld поменять на lld ума хватило, но дальше уже не осилил.

     

    У вас все по дефолту собралось, т.е. без изменений модуля ?

     

  2. За последние 2 дня в отчете всплывают IP которых в реестре вообще нет, по крайне мере на момент времени когда проходила проверка, например 193.104.14.202,  77.238.185.35 основание для блокировки решение номер 894386 , специально руками проверил реестр на предмет наличия этих IP в момент пропусков - нету их там.

    Только у нас так ?

  3. 51 minutes ago, ixi said:

    52.58.0.0/15

     

    Раз в час уже давно недостаточно проверять. Как минимум, 2 раза в час, в 15 и 45 минут; а лучше постоянно проверять getLastDumpDateEx

    До всего этого цирка с телегой - все было норм, отчеты нулевые.

    А есть какой-то вариант дергать zapret.pl каждые 10 минут проверять его exit status и если допустим реестр обновился - запускать остальные скрипты ?

  4. Начали появляться такие ошибки:

     

    2018-04-22 00:50:02 | INFO  | main  | Starting RKN at Sun Apr 22 00:50:02 2018
    2018-04-22 00:50:03 | ERROR | main  | Soap result not defined, retrying...
    2018-04-22 00:50:03 | ERROR | main  | Soap result not defined, retrying...
    2018-04-22 00:50:03 | ERROR | main  | Soap result not defined, retrying...
    2018-04-22 00:50:03 | ERROR | main  | Soap result not defined, retrying...
    2018-04-22 00:50:03 | FATAL | main  | 3 attempts failed, giving up.

    С чем это может быть связано ? Сервер РКН загибается ?

     

    upd: Обратил внимание, что в отчете начали появляться пропуски IP. Алгоритм примерно такой - в 01:00  IP добавляется в реестр, в 02:00 забор реестра обламывается с ошибкой выше, в 03:00 мы видим в отчете пропуск по этому IP,  в 04:00 реестр таки выгружается и IP блочится :-/.. 

  5.  

    2 minutes ago, flow-control said:

    Вчера кучу пропусков получили, после получения реестра в 15:30...

     

    Там вчера выгрузка в это время сломалась, @max1976 оперативно патч сделал, пролистай пару страниц назад.

     

  6. ...и как следствие такой глобальной зачистки листа - Ревизор не успел обновить свой лист и поймал кучу пропусков по тем ресурсам которых уже нет в свежем реестре.

    Сначала нас мурыжили за то, что обновлять реестр надо чаще, теперь будут отчитывать за то что обновляем слишком часто ?.. :-/

  7. Оттепель v.2018:

    2018-03-30 17:52:09 | INFO  | main  | Added: domains: 0, urls: 0, IPv4 ips: 14, IPv6 ips: 0, subnets: 0, records: 0
    2018-03-30 17:52:09 | INFO  | main  | Deleted: old domains: 4323, old urls: 31, old ips: 4367, old only ips: 4279, old subnets: 0, old records: 4500
    2018-03-30 17:52:09 | INFO  | main  | Stopping RKN at Fri Mar 30 17:52:09 2018

    Или мне кажется, или Амазон из реестра выпилили.

     

  8. 4 minutes ago, ixi said:

    И тем не менее, в статистике есть хосты, где [без интервала между запросами] после N блокировок идут сплошные таймауты на connect

     

    Не все процессоры поддерживают 1G

    А как узнать сколько поддерживает Intel(R) Xeon(R) CPU  E5520  @ 2.27GHz ?

  9. 16 hours ago, max1976 said:

    Остается только один вариант - нет свободной памяти (обычной, не для DPDK).

    Подскажите, а что должен показывать вывод 

    # hugeadm --pool-list

    Такое впечатление, что у меня не отработали параметры загрузки "default_hugepagesz=1G hugepagesz=1G hugepages=4" и hugepages установлены по дефолту на 2Мб

  10. Версия с гита от 16 февраля. В последние время почти раз в сутки уходит в coredump :(

    Не могу понять в чем причина. Трейс такой:

     

    Spoiler
    
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
    Core was generated by `/usr/local/bin/extFilter --daemon --pidfile=/var/run/extFilter.pid --config-fil'.
    Program terminated with signal SIGABRT, Aborted.
    #0  0x00007fe9d2b95428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
    54    ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
    [Current thread is 1 (Thread 0x7fe9d166d700 (LWP 7853))]
    (gdb) bt
    #0  0x00007fe9d2b95428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
    #1  0x00007fe9d2b9702a in __GI_abort () at abort.c:89
    #2  0x00007fe9d3afb365 in Poco::SignalHandler::handleSignal(int) () from /usr/local/lib/libPocoFoundation.so.46
    #3  <signal handler called>
    #4  0x0000000000592740 in ac_trie_settext(ac_trie*, ac_text*, int) ()
    #5  0x000000000058f6b8 in WorkerThread::checkHTTP(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, dpi_pkt_infos*) ()
    #6  0x000000000059063e in host_cb(dpi_http_message_informations*, unsigned char const*, unsigned int, dpi_pkt_infos*, void**, void*) ()
    #7  0x00000000005aec3c in on_value ()
    #8  0x00000000005b1a25 in http_parser_execute ()
    #9  0x00000000005af312 in check_http ()
    #10 0x00000000005ade5a in dpi_stateless_get_app_protocol ()
    #11 0x000000000058949d in WorkerThread::getAppProtocol(unsigned char*, unsigned long, unsigned int, dpi_pkt_infos*) ()
    #12 0x000000000058ad8d in WorkerThread::identifyAppProtocol(unsigned char const*, unsigned int, unsigned int, unsigned char*, unsigned int) ()
    #13 0x000000000058c3bd in WorkerThread::analyzePacket(rte_mbuf*, unsigned long) ()
    #14 0x000000000058d80b in WorkerThread::run(unsigned int) ()
    #15 0x00000000005858a4 in dpdkWorkerThreadStart(void*) ()
    #16 0x00000000005528fb in eal_thread_loop ()
    #17 0x00007fe9d2f316ba in start_thread (arg=0x7fe9d166d700) at pthread_create.c:333
    #18 0x00007fe9d2c673dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:74
    #19 0x0000000000000000 in ?? ()
    (gdb) 


     

     

  11. 11 minutes ago, max1976 said:

    Проверьте чтобы был установлен последний апдейт peafowl и фильтр был собран с этой версией. Проверьте объем свободной оперативной памяти.

    Брал билд с исправлениями по win=2, я так понимаю он с гита вытягивает последний peafowl.

    Памяти 16 Гиг, CPU Xeon E5520, карта Intel 82576, трафика немного совсем ~25Kpps

    Конфиг:

    Spoiler
    
    lower_host = true
    domainlist = /opt/zapret/domains
    urllist = /opt/zapret/urls
    ssllist = /opt/zapret/ssl_host
    hostlist = /opt/zapret/hosts
    sslips = /opt/zapret/ssl_ips
    http_redirect = true
    redirect_url = http://denied
    http_code = 302 Found
    url_additional_info=url
    rst_to_server = false
    statistic_interval = 300
    match_url_exactly = false
    block_undetected_ssl = false
    core_mask = 255
    statisticsfile = /var/run/extFilter_stat
    num_of_senders = 1
    url_normalization = true
    remove_dot = true
    memory_channels = 2
    [port 0]
    queues = 0,1; 1,2
    [dpi]
    max_active_flows_ipv4 = 1000000
    fragmentation_ipv4_state = true
    fragmentation_ipv4_table_size = 512
    tcp_reordering = true

     

     

  12. Вторые сутки подряд наблюдаю, что перестают блокироваться ssl ресурсы, при том, что остальное отрабатывается нормально.

    extFilter релоадится в 50 минут каждого часа, обратил внимания что на следующем релоаде после пропусков extFilter вылетает с ошибкой, systemd его растартует и все ОК, кроме пропусков в отчете :(

    Никто не сталкивался ?

     

    Spoiler

    Zabbix_server.thumb.png.1e37d733c5cc72271624c917286abe25.png

     

  13. 3 minutes ago, arhead said:

    А такой вопрос. Сколько zapret.pl должен обрабатывать принятый дамп? Просто что то около 45 минут работает. Это нормально?

    Старая версия скрипта (начало осени)  у меня тоже отрабатывала примерно час, новая пару минут.