|
Титла: Управление на VLAN-ни Публикувано от: mystical в Jul 20, 2013, 23:44 Имам Cisco 2950, на който за момента са дигнати няколко VLAN-а:
Цитат Port Name Status Vlan Duplex Speed Type На линукса също са вдигнати съответните VLAN-ни: Цитат 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc htb state UP qlen 1000 eth0 е свързан към Gi0/1 на cisco-то. За момента експериментирам с две мрежи 10.111.1.1/24 и 10.111.2.1/24 Идеята ми е vlan-ните, да не са обвързани с кокретни мрежи. Във всеки VLAN да има IP адреси от различни мрежи (10.111.1.1/24 и 10.111.2.1/24). Защо? Едва ли има интернет доставчик, който се съобразява с VLAN-ните, за да даде съответното IP-пи на клиентите си, от съответния VLAN и порт, ако изобщо знае какви VLAN-ни са дигнати. Предполага се, че ще има и tc (шейпър): iptables -t mangle -A FORWARD -s 10.111.1.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000 iptables -t mangle -A FORWARD -s 10.111.2.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000 tc qdisc add dev eth1 root handle 1: htb tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw ... Въпроса ми е как мога да събера много VLAN-ни на едно място, без да омажа нещата, за да пусна рутиране? Ако успея с това начинание си мисля и за статични arp таблици. Пробвах да направя bridge, между двата в-лан-а и нещата се омазаха: Цитат 04:31:36: %SPANTREE-2-BLOCK_PVID_PEER: Blocking GigabitEthernet0/1 on VLAN0010. Inconsistent peer vlan. Титла: Re: Управление на VLAN-ни Публикувано от: edmon в Jul 21, 2013, 00:03 Не, че съм го правил но предполагам само, че ако с ДХЦП раздадеш на съответните влан-и адреси от съответните мрежи и нещата ще се опростят от самосебе си ! :)
Титла: Re: Управление на VLAN-ни Публикувано от: sudo в Jul 21, 2013, 12:22 За какво са ви VLAN-и ако няма да се съобразявате с тях??? Има си Default Vlan 1.
Постановката на Линукса също не ви е правилна. За бриджа пък въобще да не говорим, не знаете за какво е, но го ползвате ... Това което всъщност ви трябва е inter-vlan routing (router on a stick). Титла: Re: Управление на VLAN-ни Публикувано от: mystical в Jul 21, 2013, 13:11 Ще се опитам да обесня идеята с два примера:
1 Cisco 2950-24 портов без вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На eth0 са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет. Много грозна картина! 2 Cisco 2950-24 портов с вдигнати vlan-ни, който е свързан към eth0 на линукс рутер. На линукския рутер също са вдигнати две мрежи 10.111.1.1/24 и 10.111.2.1/24. Идеята е за всеки порт - отделен vlan, който идва до рутера. В рутера vlan-ните да не се смесват, но и да не са обвързани с конкретна мрежа. Всеки vlan да комуникира с един общ интерфейс, но да не може да комуникира с останалите vlan-ни, без да мине през общия интерфейс. По този начи го изброените недостатъци се свеждат до отделен порт - vlan. inter-vlan routing (router on a stick) не е проблем да се направи, ако всеки vlan се обвърже с конкретна мрежа или част от мрежа. Това е неприемлив вариант. Титла: Re: Управление на VLAN-ни Публикувано от: balaban в Jul 21, 2013, 19:31 Add-ваш VLAN-ите на eth0, например eth0.10, eth0.11 и т.н., вкарваш ги в бридж например br0 и после с ebtables (не iptables) даваш политиката по дефаулт на br0 да е DROP за FORWARD! По този начин няма да loop-неш VLAN-ите помежду им, защото ако направиш това ще стане грозна картинка. След това вече на br0 интерфейса си вдигай каквито искаш адреси, така ще бъдат достъпни от всеки VLAN.
Титла: Re: Управление на VLAN-ни Публикувано от: sudo в Jul 21, 2013, 20:16 Перфектно !!! и "... Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет..." Опааа, забравих, ние ще филтрираме по MAC, чудесно докато сме аз, Грую и брат му. А като станат 500 клиента ???
Айде по-сериозно, а? Титла: Re: Управление на VLAN-ни Публикувано от: balaban в Jul 21, 2013, 20:53 Перфектно !!! и "... Всичко работи, но има една голяма LAN мрежа, в която циркулира всичко - Broadcast, arp заявки от всеки до всеки, всичко каквото се сетите и всеки прави каквото си иска. Включително ако на някой му изтече интернета сканира за IP и MAC, сменя си IP-то и MAC-а и продължава да има интернет..." Опааа, забравих, ние ще филтрираме по MAC, чудесно докато сме аз, Грую и брат му. А като станат 500 клиента ??? А ти да си видял някъде да съм писал че това е най-интелигентното решение? Човека има конкретен въпрос и му давам конкретен отговор. Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика? Титла: Re: Управление на VLAN-ни Публикувано от: sudo в Jul 21, 2013, 21:53 Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика? Още по-чудесно: сходни arp-ове, сходни broadcast-и само че този път в два сегмента. Проблеми ^2 :) Титла: Re: Управление на VLAN-ни Публикувано от: balaban в Jul 21, 2013, 22:11 Айде сега ако можеш обясни как по-точно ще мине Layer2 трафика през въпросния bridge със зададена DROP политика? Първо се изказваш неподготвен, второ не ми отговори на въпроса, и трето какво разбираш под "сходни"? Титла: Re: Управление на VLAN-ни Публикувано от: sudo в Jul 21, 2013, 23:45 ... второ не ми отговори на въпроса, и трето какво разбираш под "сходни"? Когато срежеш на две една тръба пълна с боклуци ... имаш вече ДВЕ тръби пълни с боклуци. Айде стига толкова вече, че ми се спи. MOD: Момчета, няма ли да е по-добре да обсъдите каквото имате на лично, вместо да спамите темата. Коментара се отнася и за двама ви. Защо трябва да се закачате публично, след като за всички ще е по-добре да се разберете с ЛС и темата да съдържа само полезна информация. Толкова ли е трудно? Благодаря за разбирането. МОД веднага те послушвам и пълня темата със знания. Въпрос към знаещите: Какво ще стане ако взема аз като клиент на VLAN 11 да си сложа съществуващо IP от VLAN 10 и напукам една злобна ARP с destination FF:FF:FF:FF:FF:FF ??? Легнах си вече (човече спи) Титла: Re: Управление на VLAN-ни Публикувано от: netgraph в Jul 22, 2013, 02:58 Ще се опитам да обесня идеята с два примера:Здравей, Едно от решенията на проблема ти се нарича proxy arp. Има много документация за това из интернет, няма да пресъздавам обяснения на български тук. На кратко идеята: Вдига се IP адрес X на N интерфейси (примерно в/у VLAN интерфейсите, които ти разделят мрежата) и се пуска proxy arp на същите интерфейси. След това чрез добавяне на статични пътища до използваните адреси по интерфейсите се постига свързаност м/у рутера и клиентите. Идеята на proxy arp е, че ако клиент от сегмент 1 търси клиент от сегмент 2, който е в същия subnet, то рутера ще се представи за търсения клиент (чрез ARP отговор) пред търсещия от сегмент 1 и ще започне да получава пакетите за него и да ги рутира към него в сегмент 2 (естествено ip_forwarding трябва да е пуснат). По този начин дори можеш да ограничиш скоростта м/у клиенти от един и същи IP subnet, които са в различни сегменти (VLAN-и). Ще ти дам една примерна конфигурация, която изпълнява това, което се опитваш да постигнеш ако съм те разбрал правилно. Можеш много лесно да постигнеш конфигурацията по точка 2. Ето един пример с мрежа 10.246.243.0/24 и VLAN 20 и 30: Рутер: echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv4/conf/eth0.20/proxy_arp echo 1 > /proc/sys/net/ipv4/conf/eth0.30/proxy_arp # Вдигаме адреса на рутера и на двата VLAN-а ip addr add 10.246.243.1/32 dev eth0.20 ip addr add 10.246.243.1/32 dev eth0.30 # Добавяме пътища до два клиента - единия във VLAN 20 (.2), другия в 30 (.3) ip route add 10.246.243.2/32 dev eth0.20 src 10.246.243.1 ip route add 10.246.243.3/32 dev eth0.30 src 10.246.243.1 След това можеш да пробваш от 10.246.243.2 зад VLAN 20 да достигнеш 10.246.243.3 във VLAN 30 и в ARP таблицата на клиентите ще забележиш, че .2 вижда .3 с MAC адрес рутера и същото за .3 към .2. Това е добре да го комбинираш със статичнa ARP таблица. За scale-ване, в момента в мрежа с 15000 клиента и ~ 2000 VLAN-a, подобна схема работи перфектно като в един broadcast domain има не повече от 10 човека. Не си защитен с/у крадене на интернет в отделните сегменти, но обикновено лесно се хваща крадеца ако е проблем. Ако в един сегмент някой си сложи адрес на клиент от друг сегмент, то той няма да постигне нищо, единствения проблем ще е, че хората от засегнатия сегмент няма да виждат въпросния адрес (тъй като вероятно крадеца ще отговаря с ARP отговори първи), което пак е доста лесно да се провери. Надявам се това да ти помогне [_]3 Поздрави Титла: Re: Управление на VLAN-ни Публикувано от: balaban в Jul 22, 2013, 07:59 Цитат Когато срежеш на две една тръба пълна с боклуци ... имаш вече ДВЕ тръби пълни с боклуци. Ти си един страхотен млад човек, но пишеш доста странни и несвързани неща. Ти тези "две тръби" (VLAN 10,11) така или иначе вече ги имаш. Какво значи в случая една тръба да я срежеш на две? Как ще разрешеш нещо на две което вече си е на две? Цитат Въпрос към знаещите: Какво ще стане ако взема аз като клиент на VLAN 11 да си сложа съществуващо IP от VLAN 10 и напукам една злобна ARP с destination FF:FF:FF:FF:FF:FF ??? Пак не се разбира какво имаш предвид. В случая с бриджа всички клиенти са в един или повече subnet-и, което означава че клиент от VLAN10 може да има адрес 192.168.1.22, а клиент от VLAN11 адрес 192.168.1.252. Какъв е смисъла от това което пишеш? Правиш ли разлика между Layer2 и Layer3 трафик? Ако mystical е наясно с Cisco IOS там мможе да направи допълнителни настройки за по-голяма сигурност. Титла: Re: Управление на VLAN-ни Публикувано от: sudo в Jul 22, 2013, 11:41 Такааа, ето доста изход + конфигурации щото ми писна от въпроси "това разбираш ли?" "онова разбираш ли?" "отговори ми на въпроса..."
1. рутер ОС Линукс Ubuntu 13.04 root@ubuntu:~# ifconfig br1 Link encap:Ethernet HWaddr 00:23:54:9c:69:89 inet addr:10.240.12.6 Bcast:0.0.0.0 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4074 errors:0 dropped:0 overruns:0 frame:0 TX packets:1110 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:218930 (218.9 KB) TX bytes:93157 (93.1 KB) eth6 Link encap:Ethernet HWaddr 00:23:54:9c:69:89 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:5626 errors:0 dropped:31 overruns:0 frame:0 TX packets:2461 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:986405 (986.4 KB) TX bytes:365796 (365.7 KB) eth6.1010 Link encap:Ethernet HWaddr 00:23:54:9c:69:89 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1345 errors:0 dropped:0 overruns:0 frame:0 TX packets:1636 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:390407 (390.4 KB) TX bytes:150117 (150.1 KB) eth6.1030 Link encap:Ethernet HWaddr 00:23:54:9c:69:89 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3471 errors:0 dropped:0 overruns:0 frame:0 TX packets:409 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:200086 (200.0 KB) TX bytes:111951 (111.9 KB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:1194 errors:0 dropped:0 overruns:0 frame:0 TX packets:1194 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:117512 (117.5 KB) TX bytes:117512 (117.5 KB) root@ubuntu:~# ebtables -L Bridge table: filter Bridge chain: INPUT, entries: 0, policy: ACCEPT Bridge chain: FORWARD, entries: 0, policy: DROP Bridge chain: OUTPUT, entries: 0, policy: ACCEPT root@ubuntu:~# arping -I br1 -b 10.240.12.2 ARPING 10.240.12.2 from 10.240.12.6 br1 Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.769ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 1.785ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 0.671ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.704ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.756ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 1.733ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.737ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 1.720ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 0.657ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.740ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.749ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 1.730ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 0.666ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.697ms Unicast reply from 10.240.12.2 [00:E0:18:55:4B:FC] 0.668ms Unicast reply from 10.240.12.2 [18:03:73:6F:4B:F1] 0.749ms ^CSent 8 probes (8 broadcast(s)) Received 16 response(s) root@ubuntu:~# ssh 10.240.12.2 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is e8:73:5a:3e:36:db:a2:67:0e:06:5c:c2:4b:6c:a1:9c. Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending RSA key in /root/.ssh/known_hosts:11 remove with: ssh-keygen -f "/root/.ssh/known_hosts" -R 10.240.12.2 RSA host key for 10.240.12.2 has changed and you have requested strict checking. Host key verification failed. root@ubuntu:~# Двата хоста с IP 10.240.12.2 са Убунту и Дебиан съответно във VLAN1010 u VLAN1030. Горните резултати са постигнати единствено и само с програмно осигуряване инсталирано от официалните хранилища на Дебиан и Убунту. Всичко това колега показва че онова което сте написали работи, само че е ГРОЗНО и не решава проблема с краденето на Интернет, а и както е видно и много други проблеми създава. ПП Не ми пишете на ЛС къде греша :) Титла: Re: Управление на VLAN-ни Публикувано от: mystical в Jul 22, 2013, 23:08 Благодаря на всички, които взеха участие за решаване на проблема! Специални благодарности на GytOS!
Като се има в предвит и че някой друг може да се сблъска с подобен проблем, ще опиша под формата на copy-paste, реализацията на задачата от първия ми пост. Като следвам идеята на GytOS. Основни настройки на Cisco 2950: en conf t interface FastEthernet0/1 switchport access vlan 10 switchport mode access switchport block unicast switchport port-security maximum 16 switchport port-security switchport port-security aging time 240 switchport port-security violation restrict switchport port-security aging type inactivity no cdp enable spanning-tree bpduguard enable ip dhcp snooping limit rate 50 end conf t interface FastEthernet0/2 switchport access vlan 11 switchport mode access switchport block unicast switchport port-security maximum 16 switchport port-security switchport port-security aging time 240 switchport port-security violation restrict switchport port-security aging type inactivity no cdp enable spanning-tree bpduguard enable ip dhcp snooping limit rate 50 end conf t interface GigabitEthernet0/1 switchport trunk native vlan 2 switchport trunk allowed vlan 10-33 switchport mode trunk switchport nonegotiate end show interfaces g0/1 trunk copy running-config startup-config Линукс: apt-get update apt-get install vlan echo 1 > /proc/sys/net/ipv4/ip_forward ip link add link eth0 name vlan10 type vlan id 10 ip link set dev vlan10 up ip address add 10.111.1.1/32 dev vlan10 ip address add 10.111.2.1/32 dev vlan10 echo 1 > /proc/sys/net/ipv4/conf/vlan10/proxy_arp ip link add link eth0 name vlan11 type vlan id 11 ip link set dev vlan11 up ip address add 10.111.1.1/32 dev vlan11 ip address add 10.111.2.1/32 dev vlan11 echo 1 > /proc/sys/net/ipv4/conf/vlan11/proxy_arp ip route add 10.111.2.2/32 dev vlan10 src 10.111.2.1 root@debian:/home/mystical# ping 10.111.2.2 PING 10.111.2.2 (10.111.2.2) 56(84) bytes of data. 64 bytes from 10.111.2.2: icmp_req=1 ttl=64 time=0.148 ms 64 bytes from 10.111.2.2: icmp_req=2 ttl=64 time=0.154 ms 64 bytes from 10.111.2.2: icmp_req=3 ttl=64 time=0.142 ms 64 bytes from 10.111.2.2: icmp_req=4 ttl=64 time=0.145 ms ^C --- 10.111.2.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.142/0.147/0.154/0.009 ms ip route add 10.111.2.3/32 dev vlan11 src 10.111.2.1 root@debian:/home/mystical# ping 10.111.2.3 PING 10.111.2.3 (10.111.2.3) 56(84) bytes of data. 64 bytes from 10.111.2.3: icmp_req=1 ttl=128 time=0.162 ms 64 bytes from 10.111.2.3: icmp_req=2 ttl=128 time=0.156 ms 64 bytes from 10.111.2.3: icmp_req=3 ttl=128 time=0.161 ms 64 bytes from 10.111.2.3: icmp_req=4 ttl=128 time=0.156 ms ^C --- 10.111.2.3 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2998ms rtt min/avg/max/mdev = 0.156/0.158/0.162/0.015 ms tc eth1 - интерфей свързан към интернет eth0 - интерфей свързан към вътрешната мрежа iptables -t mangle -A FORWARD -d 10.111.2.0/24 -j IPMARK --addr=dst --and-mask=0xffff --or-mask=0x10000 iptables -t mangle -A FORWARD -s 10.111.2.0/24 -j IPMARK --addr=src --and-mask=0xffff --or-mask=0x10000 tc qdisc add dev vlan11 root handle 1: htb tc filter add dev vlan11 parent 1:0 protocol ip prio 1 fw #Отнася се за IP 10.111.2.3 Download tc class add dev vlan11 parent 1: classid 1:0203 htb rate 4Mbit tc qdisc add dev eth1 root handle 1: htb tc filter add dev eth1 parent 1:0 protocol ip prio 1 fw #Отнася се за IP 10.111.2.3 Upload tc class add dev eth1 parent 1: classid 1:0203 htb rate 4Mbit Никога не съм реализирал нещо подобно и малко се притеснявам, дали ще има допълнителен товар върху машината от индивидуалното маршрутизиране за всяко IP. Повече се притеснява, че за всеки vlan интерфейс трябва да се вдигне tc qdisc и tc filter за да се ограничи скороста за сваляне. Има ли допълнителен товар от това нещо и евентуално колко? Титла: Re: Управление на VLAN-ни Публикувано от: netgraph в Jul 23, 2013, 03:35 <snip>Здравей отново, Радвам се, че си успял да си решиш проблема и си споделил подробно как за останалите. Относно въпросите ти - да, има допълнително натоварване разбира се. Рутирането на индивидуални адреси няма да ти е проблем, а ограниченията и правилата ще ти натоварят най - много машината. Всичко е относително и зависи от конфигурацията на филтрите, правилата, мрежовите настройки и естествено способностите на хардуера. Вероятно си стигнал до http://lartc.org/howto/ ($2) - това е един от най - изчерпателните ресурси за Линукс по тези теми :) Наблюдавай си натоварването както и броячите за различни грешки, закъснения на пакети в час пик и т.н. |