Владимир320

Делал я такой вариант и мне стали быть доступны все команды. Непонятно, что тут можно еду было упустить

Видел тема уже обсуждалась, но подходящего не нашел поднял такакс+, создал группу и юзера group = support { default service = deny service = exec { priv-lvl = 2 } cmd = show { permit .* } cmd = configure { permit terminal } cmd = interface { permit .* } cmd = shutdown { permit .* } } user = test { member = support login = cleartext 12345678 } cisco WS-C2960-24TT-L aaa group server tacacs+ tac_test server name Tacacs_Server aaa authentication login default group tac_test local aaa authorization console aaa authorization exec default group tac_test local aaa accounting update newinfo aaa accounting commands 0 default start-stop group tac_test aaa accounting commands 15 default start-stop group tac_test tacacs-server directed-request tacacs server Tacacs_Server address ipv4 10.10.10.10 key 12345678 Цель давать доступ на некоторые команды, но работает только show, видимо не отрабатывает: cmd = show { permit .* } cmd = configure { permit terminal } cmd = interface { permit .* } cmd = shutdown { permit .* } Перечитал уже все маны и пока застыл на месте. Подскажите чего я упускаю?

больше вопрос к такому виду правила PSH,ACK PSH,ACK. рассматриваем покеты с флагами PSH,ACK и в тоже время они должны быть установлены, а значение остальных флагов SYN,RST,FIN,URG нам не важно, оно может иметь значение либо 0 либо 1...?

Как работает эта запись? Ведь слева мы указали те флаги, которые мы рассматриваем и которые должны быть неустановлены, с справа список установленных флагов. Тут какое-то противоречие получается. Или слева список, который мы просто рассматриваем

к примеру я хочу ловить трафик где установлены PSH, ACK флаги я могу написать правила согласно инструкции: -p tcp --tcp-flags ALL ACK,PSH -j LOG -p tcp --tcp-flags FIN,SYN,RST ACK,PSH -j LOG -p tcp --tcp-flags RST ACK,PSH -j LOG и этот пакет, будет попадать под эти три правила или же не будет? Смысл вообще в первой части правила? Типа рассматриваем пакеты в которых есть такие флаги, если всегда во всех пакетах есть все флаги)) взрыв мозга

1 syn/fin=1, urg/ack/psh/rst=любые 2 syn/fin=1, urg/ack/psh/rst=0 3 syn/fin=1, rst/ack=0, psh/rst=любые Спасибо за ответы, но все же я не понимаю разницы в правилах этих, так как в пакетах всегда есть все флаги, но установлены некоторые. Зачем тогда мне указывать какие то флаги, когда будет равнозначное правило --tcp-flag all какой то флак

данная комбинация флагов мне не нужна) Мне нужно понять как эти правила работают) допустим такое правило -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP тут дропаем трафик с установленными флагами syn,fyn, а как понять первую часть правила?? так как если ваершарком развернуть пакет, то там всегда будут все флаги и установлены тока некоторые, в зависимости от трафика в чем тогда разница если я напишу такие правила: -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP -p tcp --tcp-flags ALL SYN,FIN -j DROP -p tcp --tcp-flags FIN,SYN,RST,ACK SYN,FIN -j DROP мы по сути всегда смотрим в покет со всеми флагами, но выбираем тока нужные установленные флаги. Либо я чет не понимаю

а тут разве не один из трех установлен? Или правильней любые из FIN,PSH,URG установлены

а в этом случаем? --tcp-flags ALL FIN,PSH,URG -j DROP - тое есть берем все пакеты где есть любой из флагов и дропаем где есть один из трех FIN,PSH,URG?

С чего это я перестал мочь отвечать с цитированием в этом форуме???? не работает кнопка. Ок, если взять правило из мана: --tcp-flags SYN,ACK,FIN,RST SYN зачем нам рассматривать пакеты с флагами SYN,ACK,FIN,RST в котором должен быть установлен тока SYN. Как вообще формируется первый список? У меня же в голове что я могу написать какие флаги установлены и далее дропать или нет

Всем салют, мучает вопрос с правила iptables + tcp flag из официально прочитанного мануала как-то я до сих пор не догоняю как правильно писать правила с различными флагами, подскажите плиз, кто разобрался с этим) Для примера есть такого рода правила, которые гуглятся везде, но мне пока ещё не совсем понятны: /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN,RST,PSH,ACK,URG NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,SYN FIN,SYN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,RST SYN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,ACK FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,URG URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,FIN FIN -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ACK,PSH PSH -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL ALL -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL NONE -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,FIN,PSH,URG -j DROP /sbin/iptables -t mangle -A PREROUTING -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP как бы есть офицbальный мануал по этим флагам: --tcp-flags mask comp Match when the TCP flags are as specified. The first argument mask is the flags which we should examine, written as a comma-separated list, and the second argument comp is a comma-separated list of flags which must be set. Flags are: SYN ACK FIN RST URG PSH ALL NONE. Hence the command iptables -A FORWARD -p tcp --tcp-flags SYN,ACK,FIN,RST SYN will only match packets with the SYN flag set, and the ACK, FIN and RST flags unset. Что здесь является первым аргументом?, то что идет сразу после --tcp-flags и до первой запятой? а следующий аргумент это все остальное? Для примера возьму в разбор это правило iptables -t mangle -A PREROUTING -p tcp --tcp-flags FIN,RST FIN,RST -j DROP Что я тут проверяю? пакет с установленным флагом FIN и неустановленными влагами RST FIN,RST?

Это все понятно. Меня мучает вопрос как длина при разборе tcp может так прыгать? Слушаю трафик на проксмоксе с другой тачкой и вижу нормальную картину: где len имеет одинаковое значение. У меня остается мысль это насильно изменять mss, чтобы чудес не прилетало...

если посмотреть поток tcp, то такая картина: страсти какие-то. на сколько я понимаю len должет быть в пределах mtu, а тут постоянно космические значения

инфо о сервере: Manufacturer: Supermicro Product Name: SYS-5019P-MR cpu: Model name: Intel(R) Xeon(R) Bronze 3204 CPU @ 1.90GHz ОЗУ: 32 гига сетевая карта: b5:00.0 Ethernet controller: Intel Corporation Ethernet Connection X722 (rev 09) b5:00.2 Ethernet controller: Intel Corporation Ethernet Connection X722 for 1GbE (rev 09) b5:00.3 Ethernet controller: Intel Corporation Ethernet Connection X722 for 1GbE (rev 09) Поднят Proxmox на GNU/Linux и с недавнего времени на одной из виртуалок стала очень низкая скорость передачи ну и записи файлов. Файлы передает рабочая станция, которая включена в тот же свич(cisco 2960), никаких ошибок на портах свича нету. решил послушать трафик на самом proxmos и вот, что обнаружил: бесконечные ретрансмиты. С такого рода странностью пока ещё не сталкивался, наведите на мысль, плиз). файл с дампом могу отправить

да, все норм, спасибо

НЕ стал создавать новую тему, продолжение к старому). В общем сливаю трафик с фортигейтов и ловлю его на сервере с помощью nfdump. Трафик ловится, складурется, но если я просто сделаю просмотр файла командой "nfdump -r nfcapd.202310060700" то вижу: 1970-01-01 03:00:00.000 INVALID Ignore TCP 10.154.14.130:60150 -> 10.40.1.9:445 0.0.0.0:0 -> 0.0.0.0:0 5123 5123 1970-01-01 03:00:00.000 INVALID Ignore UDP 10.154.14.130:52540 -> 10.154.16.32:389 0.0.0.0:0 -> 0.0.0.0:0 202 202 1970-01-01 03:00:00.000 INVALID Ignore TCP 10.154.14.130:60152 -> 92.118.67.2:443 212.164.74.147:60152 -> 0.0.0.0:0 2280 2280 вопрос к времени, время не меняется в дефолте стоит, как я понимаю. но если сделать просмотр трафика более умный, к примеру "nfdump -r nfcapd.202310060700 -s srcip 'host 10.154.14.130'", то со временем все норм: Date first seen Duration Proto Src IP Addr Flows(%) Packets(%) Bytes(%) pps bps bpp 2023-10-06 06:35:23.770 01:24:22.740 any 10.154.14.130 1450(50.0) 65652(25.2) 13.8 M(20.5) 12 21794 210 2023-10-06 06:57:04.450 00:59:53.570 any 10.154.17.37 418(14.4) 418( 0.2) 55256( 0.1) 0 123 132 2023-10-06 07:15:31.760 00:44:06.110 any 10.40.1.106 77( 2.7) 2052( 0.8) 1.2 M( 1.8) 0 3595 579 втф? так как мне чаще нужно использовать обычный вывод, как в первом случае настройка nfcupd: options='-z -T all -S 7 -l /srv/netflow/nfcap -t 3600 -p 2055'

В общем перепрошил я Huawei P7 и все стабильно

Пользуясь случаем, озвучу вопрос по поводу site-id. (исходя из официального описания, он должен быть уникальным для каждого сайта) То есть уникальный site-id для одного vpls или достаточно использовать один site-id на всех vpls в сторону одного соседа? Из моего примера, между PE1 и PE2 поднята bgp сессия и поднято три bgp vpls интерфейса, и в каждом vpls я указал одинаковые site-id. Пример: PE1: /interface vpls bgp-vpls add bridge=bridge_vpls_vlan53 bridge-horizon=5 export-route-targets=65530:53 import-route-targets=65530:53 name=vpls_53 route-distinguisher=65530:53 site-id=50 add bridge=bridge_vpls_vlan800 bridge-horizon=5 export-route-targets=65530:800 import-route-targets=65530:800 name=vpls_800 route-distinguisher=65530:800 site-id=50 add bridge=bridge_vpls_vlan85 bridge-horizon=5 export-route-targets=65530:85 import-route-targets=65530:85 name=vpls_85 route-distinguisher=65530:85 site-id=50 PE2: /interface vpls bgp-vpls add bridge=bridge_vpls_vlan53 bridge-horizon=5 export-route-targets=65530:53 import-route-targets=65530:53 name=vpls_53 route-distinguisher=65530:53 site-id=51 add bridge=bridge_vpls_vlan800 bridge-horizon=5 export-route-targets=65530:800 import-route-targets=65530:800 name=vpls_800 route-distinguisher=65530:800 site-id=51 add bridge=bridge_vpls_vlan85 bridge-horizon=5 export-route-targets=65530:85 import-route-targets=65530:85 name=vpls_85 route-distinguisher=65530:85 site-id=51 Это нормальная практика? или все-равно лучше указывать разные site-id даже между двумя соседями? У меня как бы все работает при такой схеме, но не совсем понятен этот site-id

После переключения PE7 на P1 пока полет нормалаьный, так долго сессии ещё не держались). P7 чет химичит

забыл проверял это или нет, припоминается, что долетал пинг, но не уходил

Откуда бы я не запустил трассировку, рвется она на P7 всегда. Доходит до адрес 172.17.250.169 и все В оспф при этом все сдается и адрес 172.17.254.113 разлетается по всей сети Думал, что косяк с bgp да врятли дело с ним, как-то же оно работает пол дня потом падает замертво и помогает тока передёргивание loopback или порта. Гигантского трафика в сети нет, ошибок на портах никаких нет. Может я чет упускаю, по этому и создал тему. Пока временно переключил PE7 в P1, P7 вообще отрубил. Жду 12 часов)

очень нужны советы или свежие мысли куда копать. Есть OSPF кольцо, построенное на HUAWEI S5720-36C-EI-AC / S6720-30C-EI-24S-AC, на карте отображены как "P" В качестве PE использую микроты CCR1009/1016/1036 BGP vpls На карте отобразил между кем и кем подняты bgp сессии, надеюсь читабельно. BGP подняты на loopback адресах. Узел P7, PE7 появился в сети буквально неделю назад и подняты сессии между: PE7<->PE3 PE7<->PE5 PE7<->PE2 vpls на PE7 пока не настроен. В общем раз в сутки, примерно через 12 часов работы начинают отваливаться bgp на PE7 со всеми тремя пирами одновременно, с логами HoldTimer expired. Начал копать и понял, что перестает пинговаться loopback на PE7 с любого из соседа, а также c PE7 не пингуются loopback адреса всех железок P, PE. bgp сессии падают и пока не передёрну порт на P7 в сторону PE7 сессии не поднимаются, иногда хватало передёрнуть loopback на PE7. Между P7 и PE7 была агрегация портов, разобрал ее и проблема осталась, поменял патчи и тоже самое. Никаких страшных логов на Железках нет, кроме HoldTimer expired. Во время отвала BGP, делаю пинг loopback адреса c P7 на PE7 и пинга нет, делаю пинг ptp интерфейса с P7 на PE7 и пинг есть. При пинге loopback адресов всегда указываю src loopback откуда делаю пинг На P везде прописана статика в сторону loopback PE и далее забираю все в оспф. Кидаю конфиги PE7 (CCR1036-8G-2S+): /ip address add address=172.17.250.170/30 interface=vlan90 network=172.17.250.168 add address=172.17.254.113 interface=loopback network=172.17.254.113 /interface bridge add name=loopback protocol-mode=none /routing bgp instance set default client-to-client-reflection=no router-id=172.17.254.113 /routing bgp peer add address-families=l2vpn name=m9-pe remote-address=172.17.254.198 remote-as=65530 update-source=loopback add address-families=l2vpn name=mssu-pe remote-address=172.17.254.111 remote-as=65530 update-source=loopback add address-families=l2vpn name=mspo-pe remote-address=172.17.254.109 remote-as=65530 update-source=loopback /mpls set dynamic-label-range=27000-29000 /mpls ldp set enabled=yes lsr-id=172.17.254.113 transport-address=172.17.254.113 /mpls ldp interface add interface=vlan90 /ip route add distance=1 dst-address=172.17.254.101/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.102/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.103/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.107/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.108/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.109/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.110/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.111/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.112/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.198/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.200/32 gateway=172.17.250.169 add distance=1 dst-address=172.17.254.201/32 gateway=172.17.250.169 P7(S6720-30C-EI-24S-AC): interface Vlanif90 ip address 172.17.250.169 255.255.255.252 mpls mpls mtu 1520 mpls ldp mpls ldp transport-address LoopBack0 interface LoopBack0 ip address 172.17.254.112 255.255.255.255 ospf 1 router-id 172.17.254.112 import-route static route-policy Static-to-OSPF area 0.0.0.0 network 10.1.217.0 0.0.0.255 network 172.17.250.160 0.0.0.3 network 172.17.250.164 0.0.0.3 network 172.17.250.168 0.0.0.3 network 172.17.254.112 0.0.0.0 route-policy Static-to-OSPF permit node 100 if-match acl 2220 acl number 2220 rule 5 permit source 172.17.254.113 0 mpls lsr-id 172.17.254.112 mpls lsp-trigger ip-prefix ldp # mpls ldp ip ip-prefix ldp index 10 permit 172.17.254.112 32 НА всех остальных узлах настроки примерно идентичные и проблем никаких на них нет, все работает. Начинаю грешить на Huawei P7(заменить?), может сума сходить начинает, непонятно На карте правильный адрес loopback PE7 - 172.17.254.113

Это я понимаю), у меня встал вопрос, почему я на компе вижу, что сети, полученные через vpn, маршрутизируются через динамический серый адрес. В моем случае 172.17.59.20. вот пример: 172.17.52.23 255.255.255.255 On-link 172.17.59.20 46 172.17.52.39 255.255.255.255 On-link 172.17.59.20 46 пул, который я настроил для пиров /ip pool add name=pool_ikev2 ranges=172.17.59.10-172.17.59.20 /ip ipsec mode-config add address-pool=pool_ikev2 address-prefix-length=32 name=IKEv2-cfg split-include=172.17.52.23/32,10.1.216.0/24

Я же правильно понимаю по поводу динамической этой сетки, что она нужна тока моему компу, чтобы комп направил нужный трафик на интерфейс ipsec и далее уже навесились политики шифрования и тд, и после этого через дефолт до адреса сервера?

отключил бридж и все работает) видимо я не до конца понимаю ipsec, буду читать. Поправил фазы и пока полет нормальный