Dotaz: iproute2 - ip rule - pravidlo pro odchozi lokalni pakety

[FF]

Dobrý den, jak odchytit pomocí ip rule pakety generované lokálními procesy ?? zkoušel jsem ip rule iif local coz sice sežere, ale ve vypisu ip rule je pak

0:      from all lookup local
99:     from all iif local [detached] lookup 90
100:    from all iif eth5 lookup tunnel
200:    from all iif download lookup tunnel-upload
32766:  from all lookup main
32767:  from all lookup default

a bohužel to nefunguje. Chci aby všechny lokalni paktety spadly do tabulky 90, kde je jen vychozi brana a pakety by tak meli timto interface odejit. Stejne ale odejdou do jineho interface uvedeneho v tabulce main. Zkousel jsem i ip rule from 0.0.0.0 take bez uspechu. Mam pocit ze pakety sebere uz tabulka local a na me pravidla uz nedojde. Jiz nyny by totiz vsechny pakety jdou do internetu meli jit pres zarizeni (tunel) upload tam se sice objevi ale uz se pak z tunelu neposlou dale do eth5. Lokalni paket tam ma src ip 10.0.3.254(ip jednoho z interface). Ale napriklad paket jdouci pres router z ip treba 10.0.3.100 do internetu projde do tunelu a take se pak korektne proroutuje do eth5. Tedy poslal se do zarizeni upload , prijde ze zarizeni download a tedy se pro nej vybere tabulka tunnel-upload kde je jen vychozi brana na eth5. Proc sem ale nepadnou i lokalni pakety netusim.

Vysledkem je ze vsechny site jsou routovany spravne, ale lokalni paktety se proste nedostanou ven do internetu.

---

---

Odpovědi

[FF]

Jeste je zajimave ze napriklad odchozi lokalni pakety z dns serveru maji odchozi IP(10.0.0.212) interfacu ktery je pripojen k vychozi brane a odesle se hned ani nevstupuje do upload tunelu. A timto interface v pohode odejde. Ale napriklad telnet 44.44.44.44 dostane zdrojovou adresu 10.0.3.254, projde tunelem a pak uz se nikde neobjevi.

[Filip Jirsák]

iif local podle mne vyhovuje rozhraní pojmenovaném local (jako je např. eth0). Zkuste iif lo (pokud máte loopback rozhraní pojmenované jako lo – zjistíte to z výpisu ip link). Alespoň já mám v man ip u ip rule add – iiftoto:

select the incoming device to match. If the interface is loopback, the rule only matches packets originating from this host. This means that you may create separate routing tables for forwarded and local packets and, hence, completely segregate them.

[FF]

funguje, dekuji. Akorat teda nachapu proc pakety pak nemaji src ip 127.0.0.1, kdyz vystupuji z lo. No vlastne obecne nechapu podle ceho se rozhoduje src adresa u lokalnich procesu. Proc je tomu jinak u dns serveru a jinak treba u toho telnetu.

[Filip Jirsák]

Já jsem tu dokumentaci pochopil tak, že použití loopback rozhraní je takový příznak, kterým se iproute2 řekne, že vás zajímají lokální procesy, tj. že to neznamená, že by pakety doopravdy pocházely z loopback rozhraní. Protože použít v těch pravidlech loopback jinak nedává smysl, tak se to použilo jako taková přezdívka.

Jinak o zdrojové IP adrese může rozhodnout samotný program. Pokud to nechá na OS, ten myslím určí odchozí adresu podle routovací tabulky (podle cíle určí příslušnou místní adresu) – např. pokud máte dvě rozhraní 192.168.0.1/24 a 192.168.1.1/24, je logické, aby paket s cílem 192.168.0.100 měl jako odchozí adresu 192.168.0.1, protože odejde rozhraním s touto IP adresou.

[Michal Kubeček]

Ale ony nevystupují z lo, to je jen taková vlastnost systému, že "iif lo" zabírá i lokálně generované pakety. Jejich zdrojová adresa není v tu chvíli ještě určena (jde-li o první paket) a určí se naopak až na základě zvolené položky směrovací tabulky.

[FF]

Ok, diky oboum lo v ip rule ma tedy "specialni ucel" a neznaci lokalni smycku. Jak pak ale vysvetlit ze lokalni pakety predtim byly smerovane do tunelu ale meli ip interface eth2 a ne ip tunelu tedy on vlastne svoji ip nema ale z konce tunelu pak zase ty pakety sly vychozi branou na eth5 ktera uz ip ma?? Proc si tedy nevzal zdrojovou ip az toho eth5?? nebo je to tak ze to routovani se vlasne dela 2x, poprve kdyz z lokalniho procesu vstupuje do tunelu upload a podruhe kdyz vystupuje druhym koncem tunelu download. A tak protoze tunel ip nema tak si vybral ip z eth2 protoze je prvni ve vypisu ?? vim ze uz sice nejak nesouvisi s dotazem, problem je vyresen, ale rad bych v tom mel jasno :) Jen pro info cilem tady toho je obejit nutnost rekompilace jadra kvuli IMQ, protoze debian jej nema. Shaspuju pak na koncich tunelu a do nich si poslu jen to chci shapovat :)

default routa byla vytvorena pomoci ip route add default dev upload

btv-router1:/home/frenk# ip addr
1: lo:  mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet 127.0.0.2/32 scope host lo
    inet 127.0.0.3/32 scope host lo
2: eth2:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 94:0c:6d:80:6f:43 brd ff:ff:ff:ff:ff:ff
    inet 10.0.3.254/24 brd 10.0.3.255 scope global eth2
3: eth5:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000
    link/ether 94:0c:6d:80:0d:7c brd ff:ff:ff:ff:ff:ff
    inet 10.0.0.212/24 brd 10.0.0.255 scope global eth5
4: eth3:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 94:0c:6d:80:5c:56 brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.254/24 brd 10.0.2.255 scope global eth3
5: eth4:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 94:0c:6d:80:6e:d7 brd ff:ff:ff:ff:ff:ff
    inet 10.0.1.254/24 brd 10.0.1.255 scope global eth4
6: eth1:  mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 94:0c:6d:80:5f:be brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.254/24 brd 192.168.1.255 scope global eth1
7: eth0:  mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether 6c:f0:49:71:63:66 brd ff:ff:ff:ff:ff:ff
    inet 10.0.4.254/24 brd 10.0.4.255 scope global eth0
8: tap0:  mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100
    link/ether 00:ff:6a:f4:99:45 brd ff:ff:ff:ff:ff:ff
    inet 172.20.120.1/24 brd 172.20.120.255 scope global tap0
9: tunl0:  mtu 1480 qdisc noop state DOWN
    link/ipip 0.0.0.0 brd 0.0.0.0
10: download@NONE:  mtu 16416 qdisc htb state UNKNOWN qlen 400
    link/ipip 127.0.0.2 peer 127.0.0.3
11: upload@NONE:  mtu 16416 qdisc htb state UNKNOWN qlen 400
    link/ipip 127.0.0.3 peer 127.0.0.2

[Michal Kubeček]

Nevím, jak konkrétně funguje ten váš tunel, ale např. u GRE nebo SIT to funguje tak, že jádro postupně zpracovává dva různé odcházející pakety: nejdřív "vnitřek" s tunelovanými adresami odcházející přes rozhraní tunelu, potom kompletní paket s adresami fyzických rozhraní konců tunelu. Takže se vlastně směruje (a preferovaná zdrojová adresa určuje) dvakrát.

[FF]

dotaz uz muzete oznacit za vyreseny :)