ip routing problema

 ( kbela | 2006. április 21., péntek - 12:05 )

Van egy gep amely gatewaykent mukodik, nem csinal semmi mast. Az eth0 nez ki az internetre, az eth1 pedig befele a belso halora. Mindket kartyan publikus ip cimek. Az eth0-an felepitettunk egy gre csatornat, ami a rendes internet kapcsolat mellett el. Ezt a csatornat szeretnem elso lepesben tesztelni a belso halozatrol, egy geprol. Tehat valahogy igy nez ki az egesz:

belso gep (publikus ip: ip1)
||
(eth1, publikus ip: ip2)
gateway
(eth0, publikus ip: ip3)---> internet + gre csatorna

A gre csatorna ket vege 192.168.100.1 es 192.168.2 (nalunk). A gatewayen Fedora Core, a csatorna tulso vegen Cisco router (hozzaferesem nincs). Azt szeretnem ha a belso geprol (es csak arrol) a forgalom a csatornan keresztul menjen. Ezert kivagtam ot a tuzfalbol:

iptables -A FORWARD -s ip1 -o eth0 -j DROP

A gatewayen beirtam a route tablaba:

ip route add 192.168.100.0/24 dev alagut

ahol alagut a gre csatorna neve. Es vegul atiranyitottam a belso geprol a forgalmat:
iptables -t nat -A PREROUTING -s ip1 -i eth1 -j DNAT --to-destination 192.168.100.2

A belso geprol a ping es a traceroute megy barhova a vilagon, de ha be akarok tolteni egy weboldalt a lynxel akkor azt mondja hogy nem lehet. A Cisco router gazdaja azt mondja, hogy szerinte minden rendben van, amiben en igazan nem vagyok meggyozodve.

Mit rontottam el? Vagy hogyan lehetne jobban csinalni? A Googlet es a TLDP-t mar kiolvastam egy parszor. Halas koszonet barmi tanacsert.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

ip route add via [dev ]
talán ezért nem megy.

a procfs-ben a forwarding engedélyezett?

A gep gatewaykent mukodik, tehat forward, tuzfal es hasonlok nem zavarnak be.

A ping es a traceroute atmegy.

Senkinek semmi otlet, javaslat, fikazas?

Csak egy kósza ötlet:
A ping és traceroute parancsok ICMP üzenetekkel működnek. Nem lehet, hogy a tűzfal letiltja a kommunikációhoz használt protokollokat (UDP, TCP)? Esetleg a Cisco Router-nél valami hasonló?

Zavard össze a világot: mosolyogj hétfőn.

Ez igy igaz. De a gepen nincs semmi a tuzfalban, tehat o net szur. Ezert mondtam en is, hogy szerintem a Cisco nincs rendesen beallitva.

pastezd be pls a "traceroute hup.hu" kimenetet. ne lepodj meg, a tenge1-1.core0.adatpark.hu (145.236.89.78) utan biztos el fog akadni (kis csillagok). ha el se indul, akkor probald ip-re (195.228.252.138).

lehet akar DNS is.

ha nem, kellene a kliens meg a GW routing tablaja (route -n).

Ime a traceroute a kliens gepen:

[root@kiralyko ~]# traceroute hup.hu
traceroute to hup.hu (195.228.252.138), 30 hops max, 46 byte packets
1 portal.fsn.hu (195.228.252.138) 0.977 ms 0.000 ms 0.000 ms

Ami a Cisco utan van azt nem mutatja meg, csak a vegpontot.

A route tabla a kliensen:

[root@kiralyko ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
193.16.218.64 0.0.0.0 255.255.255.240 U 0 0 0 eth0
192.168.114.0 192.168.110.1 255.255.255.0 UG 0 0 0 eth1
192.168.110.0 0.0.0.0 255.255.255.0 U 0 0 0 eth1
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 193.16.218.65 0.0.0.0 UG 0 0 0 eth0

Es a gatewayen:

[root@csalho ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
81.196.41.16 0.0.0.0 255.255.255.240 U 0 0 0 eth1
82.79.27.0 0.0.0.0 255.255.255.192 U 0 0 0 eth0
193.16.218.64 0.0.0.0 255.255.255.192 U 0 0 0 eth1
192.168.100.0 0.0.0.0 255.255.255.0 U 0 0 0 roedu
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 82.79.27.1 0.0.0.0 UG 0 0 0 eth0

Nem hiszem, hogy DNS lenne hiszen feloldja a neveket.

igaz, nem dns. Neked nem a dnat hanem a snat kell (souce routing, v. policy based routing - kinek hogy tetszik).

itt egy regebbi howto, ezen el lehet indulni:
http://www.linux.com/howtos/IP-Masquerade-HOWTO/iproute2.shtml

a lenyeg: a kliensen pucolj ki mindent, 1-az-1ben minden nem-lokalis forgalmat kuldje a GW-nek. A gateway funkcioja, hogy iranyitsa a forgalmat, a kliens szamara teljesen transzparens kell legyen az h. merre es hogyan lep ki a forgalma a halobol.

Ez most is igy van. A kliensnek a default cim a gateway (193.16.218.65).

Azt mondod hogy nem destination NAT kene hanem source. Ezt nem ertem.

Most olvasom a linket amit kuldtel.

Kiprobaltam amit ott ir es nem megy, mint ahogy gyanitottam. Ha SNAT-ot csinalok akkor mar a ping sem megy. Itt most nem arrol van szo, hogy egy belso halozatot szeretnek elrejteni.

ok, kicsit talan siettem reggel, a link csak valami hasonlo.

tehat, ha jol ertem, van 1 lan-od (ami route alapjan nem egeszen olyan mint ahogy mondtad az elso postban, pl kliensben 2 halokari meg 192.168-as foobarok, 2 GW ....) aminek 1etlen WAN kijarata van, a "csalho" doboz. a problema pedig az, h eddig minden cucc a belso kliensekrol a dobozra ment -- nat nem volt a publikus ip-k miatt nem is kellett -- onnan meg a nagyvilag fele. most ezzel a tunneles konfiggal azt szeretned, h csak a "kiralyko" ip-jevel mint forras/felado cimmel rendelkezo csomagok a tunnelen keresztul lepjenek ki, minden mas menjen arra, amerre eddig.

jol ertem?

ha igen, akkor azt kellene elerni, hogy a "csalho"-ra beerkezo, "kiralyko" forrasu csomagok a tunnel if-en keruljenek elkuldesre. ez pedig pontosan a fenti, source routing v. policy based routing esete, amikor szabalyokkal avatkozunk bele a route-olasi folyamatba.

a lartc.org-on van meg info amit erdemes lehet megnezni v. itt
http://www.linuxguruz.com/iptables/howto/2.4routing.html
lehet tampont a konfigban, kulonosen ez:
http://www.linuxguruz.com/iptables/howto/2.4routing-4.html#ss4.1

(ez mar tenyleg source routing, nem *nat )

A "kiralykonek" csak azert van belso halora is interface hogy bentrol el lehessen erni, nem megy at rajta semifele forgalom a belso halorol. A belso halorol a forgalom egy masik gepen megy keresztul, ahol megtortenik a natolas es onnan erkezik meg a "csalhora", majd kimegy az internetre ugy hogy nem tortenik semifele modositas. A "csalhon" most van a tunnel aminek a masik vege egy Cisco routerben van valahol az interneten. Tesztelesi celbol kenne az hogy minden forgalom a "kiralykorol" ezen a tunnelen menjen ki, teljesen fuggetlenul a tobbi forgalomtol.

Eddig az egyetlen beallitas amivel valami eredmenyt sikerult elerni az az amit mar leirtam. Sem a SNAT-al sem a source routinggal nem sikerult elerni azt, hogy mukodjon. Igy legalabb a ping es a traceroute megy, de a http es ftp mar nem. Barmi mast probaltam meg a ping sem ment.

hat ez mar tobb mint bosszanto :) tartsuk fent egy kicsit a topicot es ha lesz idom osszerakok egy tesz erejeig valamit...

Sikerult lokalizalni a problemat. Abban igazad van hogy source routing kelenne, csak az a gond hogy hogyan.

Tehat a "csalho" nevu gepnek van egy kulso csatlakozoja (IP: 82.79.27.9). A gepen nincs szures a tuzfalban, csak simma gateway. A hata mogott a belso halozatrol mar publikus ipvel jonnek a csomagok. Ugyanezen a csatlakozon epul fel egy gre tunnel (neve roedu) egy Cisco routerrel (IP: 213.157.167.254), a tunnel ket vege 192.168.100.1 es 192.168.100.2. A tunnel mukodik, a

ping -I roedu 213.157.167.254 es ping -I roedu 192.168.100.1 mennek.

Ha ellenben berakom a route tablaba a kovetkezo szabalyt:

ip route add 213.157.167.254 dev roedu

akkor mar a ping sem megy. Miert?

Hello,

Ez az egész alapvetően van elbaszva. Ping persze, hogy megy, a cisco routert pingeled bármilyen cim esetén, illetve a weblapot is a cisco routerről kéred le, ahol valszeg be van állítva a no ip http-server a konfigban.
Szal bármely IPre amit pingelsz a kliensről a linuxos gép lecseréli a cél IP-t a Cisco címére. A cisco megkapja, majd visszaválaszol. A linux visszaírja az IP-t és visszaküldi a kliensnek. A kliens meg azt hiszi, hogy az eredeti IP válaszolt vissza, holott csak a cisco router volt.
SNAT-ot kell használni, és a cisco-n is kell routingot állítani, ha nem csak a cisco-t akarod látni.
Üdv.

Hgy miért nem megy az SNAT-al?
Szeritem pulikus IP cimet akarsz pingelni. És mivel SNATolsz a 192.168 akármire, ami ugyebár nem publikus,az ICMP reply nehezen talál vissza.
Üdv.

Sikerult megoldani! Eloszor is koszonetet mondok pete-nek aki a helyes utra vezetett es azin-nak mert igaza van abban, hogy alapvetoen volt elrontva es lehet, hogy abban is, hogy csak azt hittem hogy megy a ping.

A baj a "csalho-n" volt amint azt sikerult ma reggelre tisztaznom. Tehat ime a megoldas:

ip route add 192.168.100.0/24 dev roedu src 192.168.100.2

Evvel beraktam a route tablaba az utvonalat a tunnel masik vege fele. Utanna letrehoztam egy uj route tablat ROEDU nevvel:

echo 200 ROEDU >> /etc/iproute2/rt_tables

Szabalykent megadtam, hogy ki kell arra menjen:

ip rule add from 193.16.218.75 table ROEDU

Es vegul a tablanak a gateway:

ip route add default via 192.168.100.1 dev roedu table ROEDU

Megegyszer koszonet azoknak akik segitettek.