XomA

Спасибо за ответы! Действительно дело оказалось в настройке Freeradius, в файле /etc/freeradius/3.0/mods-enabled/eap поменял в двух местах: в секции eap и подсекции ttls значение "default_eap_type = md5" на "default_eap_type = peap" и авторизация прошла. Минимальный рабочий конфиг коммутатора получился такой: radius-server authentication host 192.168.1.55 key 0 test123 aaa enable dot1x enable interface ethernet 1/0/3 dot1x enable dot1x port-method userbased standard exit interface Vlan1 ip address 192.168.1.1 255.255.255.0 exit

Добрый день! Пытаюсь проверить функционирование 802.1x на коммутаторе SNR-S2982G-8T. Не получается настроить рабочий конфиг. Есть следующая схема: Конфигурация коммутатора: radius-server authentication host 192.168.1.55 key 0 test123 aaa enable dot1x enable Interface Ethernet1/0/3 dot1x enable dot1x port-method portbased exit interface Vlan1 ip address 192.168.1.1 255.255.255.0 exit Настройка freeradius: Файл Clients.conf ... client private-network-1 { ipaddr = 192.168.1.0/24 secret = test123 shortname = net192 } ... Файл users nag Cleartext-Password := "nag" Tunnel-Type = 13, Tunnel-Medium-Type = 6, Tunnel-Private-Group-ID = 1 tcpdump на linux в момент авторизации, приходит Access-Request от коммутатора, уходит Access-Challenge в стороону коммутатора, на этом все. #tcpdump udp -n 10:04:59.256743 IP 192.168.1.1.3071 > 192.168.1.55.1812: RADIUS, Access-Request (1), id: 0x02 length: 109 10:04:59.257769 IP 192.168.1.55.1812 > 192.168.1.1.3071: RADIUS, Access-Challenge (11), id: 0x02 length: 80 На АРМ авторизация не происходит, идут постоянные запросы логина/пароля и в конце неудачная аутентификация. Если в данной схеме коммутатор SNR заменить на Русьтелетех со следующим конфигом, то все работает. dot1x system-auth-control radius-server host 192.168.1.55 key test123 interface gigabitethernet1/0/3 dot1x port-control auto exit interface vlan 1 ip address 192.168.1.1 255.255.255.0 exit Удачная авторизация на коммутаторе: 14~01-Dec-2020 14:28:23 %LINK-W-Down: gi1/0/3 01-Dec-2020 14:28:26 %SEC-W-PORTUNAUTHORIZED: Port gi1/0/3 is unAuthorized 01-Dec-2020 14:28:26 %LINK-I-Up: gi1/0/3 01-Dec-2020 14:28:30 %STP-W-PORTSTATUS: gi1/0/3: STP status Forwarding 01-Dec-2020 14:28:33 %SEC-I-PORTAUTHORIZED: Port gi1/0/3 is Authorized #show dot1x users MAC Auth Auth Session VLAN Filter Port Username Address Method Server Time -------- ---------------- ----------------- ------ ------ -------------- ---- ------ gi1/0/3 nag 70:8b:cd:8e:ef:e6 802.1X Remote 00:01:17 Лог на radius сервере: Thu Apr 18 06:41:30 2024 : Info: Ready to process requests Thu Apr 18 06:42:10 2024 : Auth: (8) Login OK: [nag/<via Auth-Type = eap>] (from client net192 port 0 via TLS tunnel) Thu Apr 18 06:42:10 2024 : Auth: (9) Login OK: [nag/<via Auth-Type = eap>] (from client net192 port 51 cli 70-8B-CD-8E-EF-E6) т.е. настройки клиента на винде и freeradius корректные и отрабатывают на другом коммутаторе. Настройка 802.1x на SNR пробовал разные. И с документации и с wiki - результат всегда одинаковый. Как еще можно попробовать настроить? Может у кого есть рабочий конфиг для данной связки. p.s. задача не использовать 802.1x в работе, а просто показать, что функционал рабочий и забыть о нем.

Была такая проблема, писал тут На новых версиях фильтра так и не заработало как у вас на схеме, работало только на 0.89. В итоге пришлось отправлять на mac другого маршрутизатора внутри сети, у которого есть маршруты к абонентским сетям.   Ну так вроде все логично. Если зеркало снимается уже после ната, то в заголовках пакетов все ip адреса отправителей будут подменены на белый ip через который происходит нат. В итоге фильтр отсылает rst не на серый ip абонента, а на внешний ip на нате, который не знает, что с ними делать.

Как уже писал выше, прероутинг пустой, в построут только правила для ната с опцией -o $PROV_INT. Подружить брасы, как вариант, можно, но думаю проще поднять виртуальный сервер с правильной таблицей маршрутизацией и на него слать rst. Ответы и не натятся, правило по маку срабатывает. Redirect пакеты версии 0.89 нормально передаются как надо, а вот redirect версии 0.95 изменяются. Сервер называется нат т.к. это одна из его функций, а по факту для внутренних сетевух это обычный маршрутизатор (все рулится правилами iptables). На днях сделаем резервный нат сервер. Прогоню на нем без всякого тюнинга редиректы от фильтра, тогда будет понятно это нат трансляции или какая-то опция тюнинга влияет. Смущает-то во всем этом тот факт, что при одинаковых условиях версия 0.89 работает, а 0.95 нет. Поэтому и задал вопрос здесь. По самой схеме вопросов нет, сделать могу чтобы работало несколькими вариантами. Тут уже спортивный интерес разобраться с нат-ом почему так получается.

Сейчас так и сделано, но надо же слать на mac каждого шлюза.. Вот упрощенная схема: Сейчас фильтр v0.89 шлет все mac 33:33:33:33:33:33, а он уже по своей таблице маршрутизации пересылает пакет или на брас1 или на брас2. Все четко. Если слать rst на брас1, то у него нет маршрутов к абонентам, обслуживаемым брас2 и наоборот соот-но. Топологию менять не вариант, как говориться работает - не трогай. Тут или разбираться с нат (он кромсает rst пакеты от фильтра версии 0.95) или использовать виртуальный маршрутизатор у которого будут полные маршруты до абонентов.

А кто-нибуть делал 2 sender порта? Оно работает вообще? А то в лог пишет, что много sender портов.. 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: extFilter 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: -n 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: 2 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: -c 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: 0x07 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: --master-lcore 2018-05-07 15:57:26.354 [10662] Debug Application - DPDK command line: 0 2018-05-07 15:57:29.671 [10662] Fatal Application - Too many senders ports upd: посмотрел исходник, только 1 сендер порт может быть

В iptables все норм, PREROUTING пустой, в FORWARD в самое начало добавлена запись target prot opt in out source destination ACCEPT all -- vlan20 * 0.0.0.0/0 0.0.0.0/0 MAC F4:CE:46:B1:09:CD где F4:CE:46:B1:09:CD - мак sender port есть подозрения что что-то в sysctl.conf не так но сервер боевой, особо сильно не поэкспериментируешь. Пока решили на фильтре сделать еще один sender port и слать редиректы сразу на два браса.

Локализовал свою проблему. Фильтр через sender порт шлет пакеты на нат сервер (ubuntu 16.04), а тот уже пересылает на брасы. Нормальная работа. v0.89 Пакет от фильтра на нат: Нат дальше передает его: Не нормальная работа. v0.95 Пакет от фильтра пришел на нат: Нат дальше передает его, но меняет src port с 80 на 314 и тип не HTTP ?? Вот тут какая-то засада, не могу понять На след маршрутизаторе вижу этот неправильный пакет: Ну и как итог до абонента доходит этот неправильный пакет и ничего не редиректит: Рядом с натом есть свободный сервер ubuntu, для теста отправляю через sender порт все на него. v0.95 и все работает норм. т.е. проблема в первом nat сервере Получается текущий нат сервер изменяет src port у редирект пакетов от фильтра версии 0.95, а от версии 0.89 все норм. На фильтре при out_mtu = 1500 измененный src port = 311, при out_mtu = 1460 измененный src port = 314. Какие настройки в linux могут так влиять и изменять src port? Бьется пакет? Куда смотреть? Тюнинг ната:

да мак правильный, rp_filter 0 да и схема-то не меняется, я прямо на боевом фильтре запускаю 0.95 версию вместо 0.89 с тем же самым конфигом..

Добрый вечер. Не могу разобраться почему на exp ветке 0.95 не доходят редиректы до абонентов, на main 0.89 все работает. С тестовой машины 10.100.0.1 делаю curl -v -4 http://rutracker.org на брасе в tcpdump смотрю пакет от фильтра (188.170.161.253 это ip заглушки) версия фильтра 0.89 версия фильтра exp 0.95 соотв-но на тестовой машине в tcpdump смотрю ответы от сайта (195.82.146.214). При версии 0.89 приходит редирект от фильтра, следом оригинальный ответ с сайта. тут все ок при версии 0.95 ответ от фильтра не доходит, только ответ от сайта По приведенным данным можно как-то понять почему редирект от 0.89 версии доходит, а от 0.95 нет? Конфиг фильтра одинаковый для обеих версий:

Спасибо, все работает

Такие же ошибки Eval: Can't call method "binip" on an undefined value at zapret.pl line 868. Use of uninitialized value $ip in hash element at ./zapret.pl line 856. Use of uninitialized value $ip in hash element at ./zapret.pl line 864. Use of uninitialized value $data in pattern match (m//) at /usr/local/share/perl/5.22.1/Net/IP.pm line 1885. Use of uninitialized value $data in pattern match (m//) at /usr/local/share/perl/5.22.1/Net/IP.pm line 1915. Use of uninitialized value $data in pattern match (m//) at /usr/local/share/perl/5.22.1/Net/IP.pm line 1927. Use of uninitialized value $ip in pattern match (m//) at /usr/local/share/perl/5.22.1/Net/IP.pm line 956. Use of uninitialized value $ip in pattern match (m//) at /usr/local/share/perl/5.22.1/Net/IP.pm line 973. Use of uninitialized value $ip in concatenation (.) or string at /usr/local/share/perl/5.22.1/Net/IP.pm line 974. Use of uninitialized value $ip in transliteration (tr///) at /usr/local/share/perl/5.22.1/Net/IP.pm line 1032.

А при посылке rst через dpdk какие ip адреса будут подставлены в качестве отправителя? Адреса заблокированных урлов?

Я в свое время сделал +use Net::SMTP::SSL; -my $smtp = Net::SMTP->new($smtp_host.':'.$smtp_port, Debug => 0) or do { $logger->error( "Can't connect to the SMTP server: $!"); return; }; +my $smtp = Net::SMTP::SSL->new($smtp_host.':'.$smtp_port, Debug => 0) or do { $logger->error( "Can't connect to the SMTP server: $!"); return; }; и почта стала отправляться

Добрый день. В сервере E5530 стоит встроенная медная сетевая на 82576. TX трафик через оптический сплиттер подается на медиаконвертер и затем в сетевуху. Данная схема отлично работает. Решили избавиться от медюка, заказали оптическую двухголовую сетевуху на i350. Новая сетевая нормально биндится в dpdk, extfilter запускается, видит и старый port 0 и новый port 1. Но.. при бинде в дпдк линк на сетевой пропадает (типа так и должно быть), а вот при старте extfilter обратно не загорается, соот-но пакеты не ловит. Но если физически передернуть оптику, то линк загорается и все начинает работать. Пробовали разные sfp модули, вместо TX от сплиттера пробовали цельный линк с mirror порта с коммутатора. Всегда одно и то же. После запуска extfilter помогает только физическое передергивание коннектора. Никто не сталкивался с похожим? В какую сторону копать, сфп модули или такое поведение может быть и из за софта? uname -a Linux ExtFilter 4.9.0-1.el7.elrepo.x86_64 #1 SMP Sun Dec 11 15:43:54 EST 2016 x86_64 x86_64 x86_64 GNU/Linux startup /opt/dpdk-stable-17.05.2/usertools/dpdk-devbind.py --status extfilter.ini

Прогнал этот тест на домашнем билайне. Тариф 80 Мбит/с. Как видно BufferBloat очень плохой. Больше 3200 ms. На домашнем микротике сделал /queue simple add max-limit=80M/50M name=queue1 target=bridge_tv где bridge_tv - внешний интерфейс Результат: Тут BufferBloat уже в норме. Оклол 80 ms. При уменьшении скорости upload BufferBloat становится еще лучше (60 ms): Хз влияет ли это на игры, я в них не играю, но может ТС попробовать привести в норму BufferBloat и проверить?

Через extfilter блокируется. После отработки скрипта extfilter_maker.pl в файле ssl_host появилась запись leonbets-oring-app-mobile-test.dev.leoncorp.net ? Нет, не блокируется. В nDPI ошибка в разборе сертификата. Точно.. прошу прощения. У нас после extfiltra на выходе сети еще squid подстраховывает, вот он и заблокировал.

Через extfilter блокируется. После отработки скрипта extfilter_maker.pl в файле ssl_host появилась запись leonbets-oring-app-mobile-test.dev.leoncorp.net ?

может это поможет? diff --git a/Zapret.pm b/Zapret.pm index 22c992d..65adb12 100644 --- a/Zapret.pm +++ b/Zapret.pm @@ -19,6 +19,7 @@ sub new my $self={ service => SOAP::Lite->service($URL) }; + $self->{service}->envprefix('soap-ENV'); bless $self,$class; return $self; }

Antares, с ядром 4.4 какая версия dpdk собралась? 16.07.2 ? И PPP нормально собралось?

у меня при поднятии ppp выполняется такое /sbin/tc filter add dev $1 parent 1: protocol ip u32 match u32 0 0 flowid 1:11 action mirred egress redirect dev ifb0 по аналогии попробуйте добавить flowid 1:11. Помоему, когда тестировал, эти цифры (1:11) ни на что не влияли, но без этого flowid не срабатывало перенаправление.

как вариант на длинк2100 шлюзом указать ip роутера(192.168.1.1), на клиентах подсеть 192.168.1 убрать, роутер будет натить через свой адрес.

Если память не изменяет, то нужно в меню Port VID Settings пятому порту прописать 1008.

То ли я не так пишу, то ли Вы не прочтете вопрос )) С какой стороны грозозащиты надо втыкать внешнюю линию? Туда где дырочка или туда где пимпочка? )) В нашем случае удобно коннектор грозозащиты воткнуть в патч панель, а в ее жопу воткнуть коннектор от dslma. Но будет ли она защищать с таким способом подключения..

Не понял этого вопроса. Меня интересует с какой стороны в грозозащиту надо втыкать внешнюю линию.