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