IMQ+NAT

[Miroslaw Dyduch]

Dnia środa, 21 września 2005 11:14, Jarek Poplawski napisał:
> Miroslaw Dyduch wrote:
> > Dnia wtorek, 20 września 2005 15:16, Jarek Poplawski napisał:
> > ....
> >
> >>Chyba się powtórzę:
> >>Jeśli na eth0 działa NAT (SNAT lub MASQUERADE) pakietów
> >>wychodzących do internetu, to pakiety przychodzące (-i eth0) w
> >>fazie PREROUTING mają ip interfejsu eth0 i dopiero po
> >>"zdenatowaniu", czyli w FORWARD lub INPUT można będzie odróżnić
> >>ip lanu lub ip serwera (który najczęściej pozostanie zgodny z ip
> >>eth0). Nie ma to żadnego związku z ustawieniami IMQ.
> >
> > Dziękuje za wyprowadznie mnie z błędu w którym tkwiłem.
> >
> > ...
> > Na FORWARD -i eth0 -o eth1 idziesz wszystko ładnie rozpoznaje adresy
> > lanu- jest tak jak ma być ;)
> >
> > Problem się zaczyna z INPUT w mangle.
> > iptables -F -t mangle
> > iptables -t mangle -A INPUT -i eth0 -j IMQ --todev 0
> > wget http://plik_testowy
> > prawie nic nie idzie do imq0 (nload -m -u K imq0)- " od czasu do czasu
> > coś bardzo małego skoczy"
> > ifconfig imq0- od czasu do czasu wpadnie jakiś pakiet
> > watch -n1 iptables -L INPUT -t mangle -nv natomiast licznik pokazuje
> > prawidłowo scigąniete okolo 14M.
> > dydko root # iptables -L INPUT -t mangle -nv
> > Chain INPUT (policy ACCEPT 48747 packets, 70M bytes)
> >  pkts bytes target     prot opt in     out     source
> > destination
> > 10283   14M IMQ        all  --  eth0   *       0.0.0.0/0           
> > 0.0.00/0 IMQ: todev 0
> > dydko root #
> >
> > Co może byc przyczyną ze nie łapie w INPUT do lokalnej maszyny??
>
> Może to, że IMQ ma swoje ograniczenia i powinno być stosowane w
> PREROUTING lub POSTROUTING.
Zasugerowałem się tym że na OUTPUT działa a na INPUT nie
>
> > Dlatego własnie kombinowałem z PREROUTING -d ip_lan_serwera.
>
> Być może czegoś nie mogę zrozumieć, ale:
>
> iptables -t mangle -A PREROUTING -i eth0 -j IMQ --todev 0
>
> przy domyślnym w PLD (ale niedomyślnym w oryginalnym IMQ)
> ustawieniu w konfiguracji jądra CONFIG_IMQ_BEHAVIOR_AB pozwoli
> przy pomocy:
>
> tc filter add dev imq0 ... u32 match ip dst \
>   ip_lan_serwera_na_eth0
>
> (i ew. na wszelki wypadek powtórzone z ip_lan_serwera_na_eth1)
>
> skierować ruch przychodzący z internetu przeznaczony dla
> serwera(routera)  do odpowiedniej klasy, a
>
> tc filter add dev imq0 ... u32 match ip dst \
>   ip_lan_komputera ...
>
> zadziała podobnie dla komputerów w sieci z adresami lokalnymi.
>
> Jarek P.
>
> _______________________________________________
> pld-users-pl mailing list
> pld-users-pl w lists.pld-linux.org
> http://lists.pld-linux.org/mailman/listinfo/pld-users-pl

Dziękuje za szczegółowe i wyczerpujące odpowiedzi, oraz za poświęcony czas.
Teraz już jest wszytko dla mnie jasne.
Chciałem poprostu uniknąć od samego początku u32
(na iptables jedna linijka z multiport, druga z ipp2p i jest po "krzyku"), a 
jednak będe musiał przeprosić u32.
A przez ciekawość (u mnie nie ma to znaczenia), co jest "szybsze" u32 czy 
iptables-y??
-- 
Pozdrawiam 
Miroslaw Dyduch
gg 3936429, email 	dydko1 w o2.pl