Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
W chwili obecnej stawiam 1 interfejs IMQ. Na ten interfejs przekierowuje cały ruch przychodzący do maszyny (interfejs eth1 do którego podpięty jest modem DSL). IMQ widzi ruch już za NATem (ponieważ jest podpięty przed odpowiednią tablicą netfilter'a - wybieramy to podczas kompilacji, na pewno wiecie o co mi chodzi) , dlatego na tym jednym interfejsie mogę ograniczać jednocześnie ruch do LANu i do usług udostępnianych na serwerze (to ta sama maszyna).
Do ruchu wychodzącego nie potrzebuję IMQ/IFB - tutaj mogę spokojnie kolejki zakładać na rzeczywistym intefejsie (eth1 do którego podpięty jest modem DSL) - ponieważ tam widzę adresy IP jeszcze przed NAT'em.
Teraz o ile mi wiadomo, nie da się za pomocą ifb zrealizować na 1 interfejsie tego, co robię teraz za pomocą IMQ, ponieważ ifb widzi ruch za wcześnie. Tak? Widzi ruch jeszcze przed NAT'em, czyli na tym "zewnętrznym" IP (testowałem). Jeśli się myślę, to proszę poprawcie mnie.
W każdym razie do czego zmierzam - jeśli na powyższe postawione przeze mnie pytanie jest odpowiedz rzeczywiście negatywna, to znaczy że imq nie da się gładko zastąpić za pomocą ifb. Przypomnę, że nie mam noża na gardle - u mnie imq działa świetnie.
Ostatnio edytowany przez urug (2009-02-25 15:19:45)
Offline
urug napisał(-a):
W chwili obecnej stawiam 1 interfejs IMQ. Na ten interfejs przekierowuje cały ruch przychodzący do maszyny (interfejs eth1 do którego podpięty jest modem DSL). IMQ widzi ruch już za NATem (ponieważ jest podpięty przed odpowiednią tablicą netfilter'a - wybieramy to podczas kompilacji, na pewno wiecie o co mi chodzi) , dlatego na tym jednym interfejsie mogę ograniczać jednocześnie ruch do LANu i do usług udostępnianych na serwerze (to ta sama maszyna).
nie rozumie, w jakim trybie odpalasz IMQ? dobrze rozumiem że wrzucasz do imq download usera
urug napisał(-a):
Do ruchu wychodzącego nie potrzebuję IMQ/IFB - tutaj mogę spokojnie kolejki zakładać na rzeczywistym intefejsie (eth1 do którego podpięty jest modem DSL) - ponieważ tam widzę adresy IP jeszcze przed NAT'em.
no to ruch do kolejek wrzucasz za pomocą MARK lub IPMARK?
Offline
IMQ odpalam w trybie AB:
IMQ driver loaded successfully.
Hooking IMQ after NAT on PREROUTING.
Hooking IMQ before NAT on POSTROUTING.
(Ruch przychodzący za NATem ruch wychodzący przed, ale to akurat dla mnie jest nieistotne. Następnie cały ruch przychodzący na interfejs eth1 (to u mnie świat jest) przekierowuje do interfejsu IMQ i na nim dokonuje kształtowania ruchu przychodzącego - zarówno usług serwera (pop3, smtp, http etc.) jak i LANu (192.168.1.0/24).
Co do drugiego, to używam CLASSIFY, bo jest bardzo wygodne :-) Nie mam tak dużo regułek by się martwić wydajnością.
Ostatnio edytowany przez urug (2009-02-25 16:17:49)
Offline
Fsck IMQ, fsck IFB :)
Osobiście używam IMQ i jestem zadowolony (robi obecnie 120/40 Mbps przy 20/20 kpps).
Problem w tym, że projektowi brak wsparcia deweloperów jądra.
Problemem w IFB jest nat i ruch generowany lokalnie.
Jest rozwiązanie pozbawione wad IMQ i IFB: http://groups.google.com/group/pl.comp.os.linux.sie … 47e7fc3482ee4
modprobe ipip ip addr add 127.0.0.3 dev lo ip addr add 127.0.0.2 dev lo ip tunnel add koniec1 mode ipip remote 127.0.0.3 local 127.0.0.2 ip tunnel add koniec2 mode ipip remote 127.0.0.2 local 127.0.0.3 ip link set up dev koniec1 ip link set up dev koniec2 ip addr add 10.0.0.1 dev koniec1 ip addr add 10.0.0.2 dev koniec2 ip route add default dev koniec1 table 10 ip rule add iif eth0 lookup 10 ip route add default dev koniec2 table 20 ip rule add iif ath0 lookup 20 echo 0 >/proc/sys/net/ipv4/conf/koniec1/rp_filter echo 0 >/proc/sys/net/ipv4/conf/koniec2/rp_filter ip route flush cache
Na interfejsie lo mamy ładny tunelik i widac enkapsulację:
huj ~ # tcpdump -i lo -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on lo, link-type EN10MB (Ethernet), capture size 96 bytes 23:50:10.163662 IP 127.0.0.2 > 127.0.0.3: IP 172.16.1.7.32805 > 10.1.1.201.53: 61030+ A? onet.pl. (25) (ipip-proto-4) 23:50:10.167872 IP 127.0.0.3 > 127.0.0.2: IP 10.1.1.201.53 > 172.16.1.7.32805: 61030 1/5/5 (230) (ipip-proto-4) 23:50:10.168205 IP 127.0.0.2 > 127.0.0.3: IP 172.16.1.7 > 213.180.138.148: ICMP echo request, id 53025, seq 1, length 64 (ipip-proto-4) 23:50:10.178139 IP 127.0.0.3 > 127.0.0.2: IP 213.180.138.148 > 172.16.1.7: ICMP echo reply, id 53025, seq 1, length 64 (ipip-proto-4) 23:50:10.178340 IP 127.0.0.2 > 127.0.0.3: IP 172.16.1.7.32805 > 10.1.1.201.53: 42281+[|domain] (ipip-proto-4) 23:50:10.192051 IP 127.0.0.3 > 127.0.0.2: IP 10.1.1.201.53 > 172.16.1.7.32805: 42281[|domain] (ipip-proto-4) 23:50:11.167900 IP 127.0.0.2 > 127.0.0.3: IP 172.16.1.7 > 213.180.138.148: ICMP echo request, id 53025, seq 2, length 64 (ipip-proto-4) 23:50:11.178714 IP 127.0.0.3 > 127.0.0.2: IP 213.180.138.148 > 172.16.1.7: ICMP echo reply, id 53025, seq 2, length 64 (ipip-proto-4) 23:50:11.178930 IP 127.0.0.2 > 127.0.0.3: IP 172.16.1.7.32805 > 10.1.1.201.53: 16453+[|domain] (ipip-proto-4) 23:50:11.182718 IP 127.0.0.3 > 127.0.0.2: IP 10.1.1.201.53 > 172.16.1.7.32805: 16453[|domain] (ipip-proto-4)
Na końcu tunelu mamy już gołe IP:
huj ~ # tcpdump -i koniec1 -n tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on koniec1, link-type RAW (Raw IP), capture size 96 bytes 23:51:00.640062 IP 172.16.1.7.32805 > 10.1.1.201.53: 15124+ A? onet.pl. (25) 23:51:00.644357 IP 10.1.1.201.53 > 172.16.1.7.32805: 15124 1/5/5 A 213.180.138.148 (230) 23:51:00.644641 IP 172.16.1.7 > 213.180.138.148: ICMP echo request, id 64545, seq 1, length 64 23:51:00.655113 IP 213.180.138.148 > 172.16.1.7: ICMP echo reply, id 64545, seq 1, length 64 23:51:00.655308 IP 172.16.1.7.32805 > 10.1.1.201.53: 27360+ PTR? 148.138.180.213.in-addr.arpa. (46) 23:51:00.658890 IP 10.1.1.201.53 > 172.16.1.7.32805: 27360 1/3/3 PTR[
Działa to dobrze z NAT:
huj ~ # iptables -t nat -L -vn Chain PREROUTING (policy ACCEPT 17562 packets, 1470K bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 17524 packets, 1466K bytes) pkts bytes target prot opt in out source destination 328 20288 MASQUERADE all -- * ath0 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 330 packets, 20408 bytes) pkts bytes target prot opt in out source destination huj ~ # ip addr list 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 brd 127.255.255.255 scope host lo inet 127.0.0.3/32 scope host lo inet 127.0.0.2/32 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:11:43:3d:dc:e2 brd ff:ff:ff:ff:ff:ff inet 172.16.1.1/16 brd 172.16.255.255 scope global eth0 (...) 3: wifi0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast qlen 199 link/ieee802.11 00:0b:6b:86:28:cf brd ff:ff:ff:ff:ff:ff 4: ath0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue link/ether 00:0b:6b:86:28:cf brd ff:ff:ff:ff:ff:ff inet 192.168.252.99/24 brd 192.168.252.255 scope global ath0 (...) 9: koniec2@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 16416 qdisc noqueue link/ipip 127.0.0.3 peer 127.0.0.2 inet 10.0.0.2/32 scope global koniec2 10: koniec1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 16416 qdisc noqueue link/ipip 127.0.0.2 peer 127.0.0.3 inet 10.0.0.1/32 scope global koniec1
Na dniach przetestuję sobie to na produkcyjnym routerku :)
Pozdrawiam.
Offline
Wydaje się działać:
huj ~ # cat htb.ipip alias tc=/usr/local/2.6.24.7-grsec/sbin/tc tc qdisc add dev koniec2 root handle 1: htb tc class add dev koniec2 parent 1: classid 1:1 htb rate 1Mbit ceil 1Mbit tc class add dev koniec2 parent 1:1 classid 1:2 htb rate 500kbit ceil 500kbit tc filter add dev koniec2 parent 1: protocol ip prio 1 u32 match ip dst 172.16.1.7/32 flowid 1:2 tc qdisc add dev koniec1 root handle 1: htb tc class add dev koniec1 parent 1: classid 1:1 htb rate 1Mbit ceil 1Mbit tc class add dev koniec1 parent 1:1 classid 1:2 htb rate 500kbit ceil 500kbit tc filter add dev koniec1 parent 1: protocol ip prio 1 u32 match ip src 172.16.1.7/32 flowid 1:2
huj ~ # tc -s filter show dev koniec1 filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 (rule hit 92194 success 92194) src 172.16.1.7/32 (success 92194 ) huj ~ # tc -s filter show dev koniec2 filter parent 1: protocol ip pref 1 u32 filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 filter parent 1: protocol ip pref 1 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:2 (rule hit 46407 success 46407) dst 172.16.1.7/32 (success 46407 ) huj ~ # tc -s class show dev koniec1 class htb 1:1 root rate 1000Kbit ceil 1000Kbit burst 1600b cburst 1600b Sent 6081494 bytes 44975 pkt (dropped 0, overlimits 0 requeues 0) rate 187848bit 32pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: 12000 ctokens: 12000 class htb 1:2 parent 1:1 prio 0 rate 500000bit ceil 500000bit burst 1600b cburst 1600b Sent 6081494 bytes 44975 pkt (dropped 47187, overlimits 0 requeues 0) rate 187464bit 32pps backlog 0b 0p requeues 0 lended: 44975 borrowed: 0 giants: 0 tokens: 24000 ctokens: 24000 huj ~ # tc -s class show dev koniec2 class htb 1:1 root rate 1000Kbit ceil 1000Kbit burst 1600b cburst 1600b Sent 11639883 bytes 42975 pkt (dropped 0, overlimits 0 requeues 0) rate 210232bit 32pps backlog 0b 0p requeues 0 lended: 0 borrowed: 0 giants: 0 tokens: -4457 ctokens: -4457 class htb 1:2 parent 1:1 prio 0 rate 500000bit ceil 500000bit burst 1600b cburst 1600b Sent 11639883 bytes 42975 pkt (dropped 3426, overlimits 0 requeues 0) rate 210784bit 32pps backlog 0b 0p requeues 0 lended: 42975 borrowed: 0 giants: 0 tokens: -15083 ctokens: -15083
Offline
no to chyba najlepszym rozwiązaniem jest ifb a squid przed routerem na bridge z tproxy4.1
Ostatnio edytowany przez siarka2107 (2009-03-06 08:52:12)
Offline
zlyZwierz napisał(-a):
A dlaczego na bridge ?
niekoniecznie w bridge, no ale wydaje mi się wygodniej niż stawiać squida obok i z routera 80 port kierować na maszynę ze squidem, jak postawie to w bridge to nic nie muszę przekierowywać
Offline
drodzy koledzy, sposób opisany tutaj jako realizacja IMQ bez IMQ jest czymś czego normalnie szukałem, testuję to na maszynie specjalnie do tego celu postawionej bo muszę sobie podzielić nerwostradę z sąsiadem i chcę mieć limitowanie ruchu dla świętego spokoju działania tego :)
no to tak.. póki co utknąłem (mentalnie :( ) na poziomie tego "jak puścić ruch po tych stworzonych rurkach?" przez prerouting? czy jak? tak żeby to nie było "od dupy strony" :P z góry dziękuję za poradę praktyczną :)
z góry wielkie dzięki :)
Offline