alexdirty
-
Публикации
55 -
Зарегистрирован
-
Посещение
Сообщения, опубликованные пользователем alexdirty
-
-
Возможно это даёт отсрочку 60 дней на реализацию, после первого получения перечня.
Постановление Правительства РФ от 29 декабря 2021 г. № 2531 “Об утверждении Правил ведения перечня отечественных социально значимых информационных ресурсов” - Федеральная служба по надзору в сфере связи, информационных технологий и массовых коммуникаций не позднее 7-го календарного дня со дня утверждения или актуализации перечня направляет его посредством информационной системы взаимодействия операторам связи, указанным в пункте 53 статьи 46 Федерального закона "О связи", для осуществления технических настроек, необходимых ввиду актуализации перечня, в течение 60 календарных дней со дня получения перечня. -
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
У меня по 221 приказу в ЛК единого портала пользователей ЦМУ ССОП вдруг пропала информация по ранее загруженным файлам. А так же, похоже, что появилась возможность передать информацию путём заполнения WEB форм.
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
Да, спасибо. И правда. Сразу не проверил.
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. Весело.
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
А ни у кого нет пропусков от 22.10.2020 по https урлам смотретьвидео.рф ?
Какие то непонятки. В реестре нет (который я получаю), в отчётах от ревизора есть. -
51 минуту назад, alexdirty сказал:
Интересно, а как понимать поле "Обяз" с пустым значением, т.е. не "0..." и не "1" ?
Ответили из ЦМУ ССОП
ЦитатаДанные поля опциональны для заполнения. Так как форма универсальная не все поля актуальны для каждого пользователя.
-
В 02.06.2020 в 07:27, bos9 сказал:
Я правильно понимаю, что элементы, содержащие в поле "Обяз" значение "0...", являются не обязательными (указываются ноль или более раз)?
Интересно, а как понимать поле "Обяз" с пустым значением, т.е. не "0..." и не "1" ?
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
В 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, количества трансляций в эти моменты может что-то подскажут.
-
В 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... Весело.
-
В 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.
-
В 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 трансляция никогда не освободится и исчерпание пула не за горами.
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
Обновился на 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.
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
Коллеги, прошу подсказать, какой софт показал себя более стабильным и без багов для 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).
-
Успешно ли в таком случае блокируется HTTPS ?
-
-
35 минут назад, yKpon сказал:
не подЕелитесь скриптом для проверки? =)
Subscribe to @rknshowtime in Telegram.
-
Только что много чего убрали https://pastebin.com/66CUnCDD
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
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?
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
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 в котором часть заблочена, а другая часть нет.
-
7 часов назад, swsn сказал:
тоже сегодня автоматизировал формирование конфига private-address из дампа и завернул трафик на unbound, активно тестирую уже на юзерах. Спасибо за идею, изящное решение.)
А как unbound по производительности в отличии от Bind себя поведёт при большом количестве юзеров >10k ?
-
Умственные способности "блокировщиков" не перестают удивлять.
Что они хотели добиться этими 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 после редиректа.
-
Опубликовано · Изменено пользователем alexdirty · Жалоба на ответ
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)
Была необходимость на несколько секунд роуты погасить (((
-
Ревизор нашёл пропуск в виде https://www.mepin.com
Я в реестре не нашёл его. Есть ли такой в реестре? -
Опубликовано · Изменено пользователем alexdirty
UPD2 · Жалоба на ответextFilter проработал почти сутки и упал.
При запуске:
Syntax error: Cannot convert to boolean: none
Подскажите пожалуйста, куда смотреть.
UPD1: сейчас пересмотрю конфиг, т.к. с дефолтным конфигом уже другие, соответствующие ошибки.
UPD2: пардон, всё летатет ;) Сам в конфиг вписал none, там где должно быть false.
max197616, спасибо огромное за твой труд!
-
2 часа назад, yKpon сказал:
@arhead благодарю, теперь блокирует нормально, но! прошу не пинать за то, что я до сих пор сижу на nfqfilter, в общем нет блокировки по домену, допустим telegramproxy.com и hello.opentg.us есть в domains, но они не блокируются
да и ещё много таких
Тоже самое было на nfqfilter. Запустил extFilter, стало норм. Теперь оба молотят.
Оборудование Juniper Network. Отзывы, реальная производительность.
в Активное оборудование Ethernet, IP, MPLS, SDN/NFV...
Опубликовано · Жалоба на ответ
В закрытый раздел ещё кто-то добавляет?