routeolas de hogyan

Linux-kezdő

Sziasztok!

Adott két vonal, két fix ip. Beraktam a modemek mögé egy debiant 3 hálókártyával. Azt szeretném tudni, hogyan lehet azt megoldani azt, hogy ha valami bejön az egyik kártyán akkor ugyanazon akarjon kimenni is, hogy teszem azt mindkét publikus ip-n elérhető legyen a nat mögött lévő ftp szerver.
Tippeket adjatok legyszi. A route táblát már nézegettem de eddig sosem kellett igazán hozzányúlnom.
köszi.

R.

  • 2120 megtekintés

( azin | 2007. 05. 30., sze – 09:11 )

Hello!

Advanced routing-al próbálkozz. Kernelben be kell legyen kapcsolva. A megfelelő userspace progival tudod beállítani a routing táblákat. (iproute2).
Az egyes interfacek forrás címe alapján kell egy szabályt írnod. Azaz, ha valaki az A interfacen csatlakozik a szerverhez, a szerver az ahhoz tartozó interface IP címével látja el a válasz csomagot (forrás cím). Erre a forrás címre írja egy szabályt tudod szabályozni, hogy az A interface-n bejőtt csomagra a válasz is ott menyjen ki.

Üdv

Köszi, ilyesmire gondoltam én is. A kernelben advanced routing benne van, iproute2 fent van es egyszerűbb szabályokat tudok is definiálni, de az ip route és én még nem igazán értjük egymást.
Szóval a routing-ból csak az advanced hiányzik az pedig az én hiányosságom. Nézegettem a man-t de egy példa sokat segítene...

R.

Linux Advanced Routing HOWTO

4.1. Simple source policy routing

Let's take a real example once again, I have 2 (actually 3, about time I returned them) cable modems, connected to a Linux NAT ('masquerading') router. People living here pay me to use the Internet. Suppose one of my house mates only visits hotmail and wants to pay less. This is fine with me, but they'll end up using the low-end cable modem.

The 'fast' cable modem is known as 212.64.94.251 and is a PPP link to 212.64.94.1. The 'slow' cable modem is known by various ip addresses, 212.64.78.148 in this example and is a link to 195.96.98.253.

The local table:

[ahu@home ahu]$ ip route list table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
local 10.0.0.1 dev eth0 proto kernel scope host src 10.0.0.1
broadcast 10.0.0.0 dev eth0 proto kernel scope link src 10.0.0.1
local 212.64.94.251 dev ppp0 proto kernel scope host src 212.64.94.251
broadcast 10.255.255.255 dev eth0 proto kernel scope link src 10.0.0.1
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 212.64.78.148 dev ppp2 proto kernel scope host src 212.64.78.148
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1

Lots of obvious things, but things that need to be specified somewhere. Well, here they are. The default table is empty.

Let's view the 'main' table:

[ahu@home ahu]$ ip route list table main
195.96.98.253 dev ppp2 proto kernel scope link src 212.64.78.148
212.64.94.1 dev ppp0 proto kernel scope link src 212.64.94.251
10.0.0.0/8 dev eth0 proto kernel scope link src 10.0.0.1
127.0.0.0/8 dev lo scope link
default via 212.64.94.1 dev ppp0

We now generate a new rule which we call 'John', for our hypothetical house mate. Although we can work with pure numbers, it's far easier if we add our tables to /etc/iproute2/rt_tables.

# echo 200 John >> /etc/iproute2/rt_tables
# ip rule add from 10.0.0.10 table John
# ip rule ls
0: from all lookup local
32765: from 10.0.0.10 lookup John
32766: from all lookup main
32767: from all lookup default

Now all that is left is to generate John's table, and flush the route cache:

# ip route add default via 195.96.98.253 dev ppp2 table John
# ip route flush cache

And we are done. It is left as an exercise for the reader to implement this in ip-up.

( muszi v | 2007. 05. 30., sze – 09:17 )

connmark-kal megjelolod a bejovo kapcsolatot, es utana minden egyes kimeno csomagba beleirod a kapcsolatahoz tartozo mark-ot, majd a mark szerint route-olod az elso vagy a masodik kimeno kapcsolat fele.

Nem a csomagot irod at, hanem a csomaghoz tartozo mark-ot (amit a netfilter tart nyilvan). Amugy pedig nem tudom, hogy tudnad maskepp eldonteni, hogy az 1.2.3.4-rol a szerveredre erkezo csomagra melyik interfeszen keresztul kuldd ki a valaszt (a lartc howto-bol idezett resz akkor jo, ha belulrol indul a keres, mert akkor a NAT miatt a jo interfeszen jon majd vissza a valasz is).

Ez igaz is lenne, ha a szervernek lenne ket publikus IP cime, csakhogy a topikindito szerint van egy router ket internetkapcsolattal, es az DNAT-ol a mogotte levo szerverre. Igy a szerver felol erkezo csomagok forrascime lesz mondjuk 192.168.1.1 (a szerver DMZ-beli cime), a celcim pedig 1.2.3.4 (ahonnan a keres erkezett). Nem vagyok biztos benne, de szerintem a DNAT-olt cim visszairasa eredetive a postrouting-ban tortenik, amikorra a route-olas mar reg megtortent, tehat nem vagyok biztos benne, hogy talalkoznal a bejovo interfesz cimevel.

Engem az a resz zavart meg, hogy "mindkét publikus ip-n elérhető legyen a nat mögött lévő ftp szerver" meg "Beraktam a modemek mögé egy debiant 3 hálókártyával"- ha a Debian a router is, meg az ftp szerver is egyben, akkor nincs NAT mogott (ket publikus IP-je van). Ha megis ugy van, ahogy en ertettem (a routerben 3 halokartya van, 2 a ket ADSL, 1 az ftp szerver fele), akkor szerintem csak a conntrack-kel tudod megoldani.

Hát izé, nekem nem ez jött le a topicindítóból (kéretik ezután minden esetben rajzot is mellékelni!:)))
Ebben az esetben javasolt alias IP beállítása az FTP szerveren. Azaz az egyik vonalról a .1-re a másik vonalról a .2-es IPre NATolunk.
Így a postrouting nem zavar be, mert már a debian routerre bejövő válasz csomagban is más az IP cím.
Üdv

Azin megoldasa egyszerubb, viszont a szervert is modositani kell hozza (IP alias - lehet, hogy a szerver OS-e nem tudja). Vegulis a conntrack-es megoldas sem olyan bonyolult, a kovetkezo kell az iptables-nek: 

#
# SNAT
#

iptables -t nat -A POSTROUTING -o "$EXT_IF" -j MASQUERADE
iptables -t nat -A POSTROUTING -o "$EXT2_IF" -j MASQUERADE

#
# PACKET MARKING
#

# Mark and save
iptables -t mangle -N MARK_1_AND_SAVE
iptables -t mangle -A MARK_1_AND_SAVE -j MARK --set-mark 1
iptables -t mangle -A MARK_1_AND_SAVE -j CONNMARK --save-mark
iptables -t mangle -A MARK_1_AND_SAVE -j ACCEPT

iptables -t mangle -N MARK_2_AND_SAVE
iptables -t mangle -A MARK_2_AND_SAVE -j MARK --set-mark 2
iptables -t mangle -A MARK_2_AND_SAVE -j CONNMARK --save-mark
iptables -t mangle -A MARK_2_AND_SAVE -j ACCEPT

# Mark incoming connections
iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark
iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j ACCEPT
iptables -t mangle -A PREROUTING -i "$EXT_IF" -j MARK_1_AND_SAVE
iptables -t mangle -A PREROUTING -i "$EXT2_IF" -j MARK_2_AND_SAVE

(ja, es szerintem ez sem nagyobb terheles, mint minden egyes csomagnak megnezni a forrascimet :-)

Meg kell szerkeszteni a routing tablat, hogy az 1-es fwmark-os csomagok az egyik ISP fele menjenek, a 2-es fwmark-osok a masik fele. Esetleg azt is meg lehet csinalni, hogy a belulrol indulo csomagok pedig random modon egyik vagy a masik fele (terhelesmegosztas - ezeket mar az idezett lartc howto szerint).

A ket routing tablat mindket modszernel ugyanugy letre kell hozni, azt ugysem uszod meg :-)

A dolog lenyege az, hogy minden internetkapcsolat szamara letrehozol egy sajat routing tablat ugy, hogy minden helyi halozat szerepeljen benne, es a default gateway pedig az adott internetkapcsolat def.gw.-je legyen. Utana letrehozod azokat a szabalyokat, amik eldontik, hogy mikor melyik routing tablat kell hasznalni (pl. forras cim szerint, cel port szerint, fwmark szerint, stb.). Nem olyan bonyolult dolog az, csak elso olvasasra :-)

Igen, ezt sejtettem es a ket routing tablat mar meg is csinaltam. Elso olvasasra tenyleg bonyolultnak tunt, de nagyjabol kezd kialakulni a kep. Mivel elsore ugysem fog sikerulni ezert azt kerdeznem meg, hogy nincs valami debug modszer amivel ellenorizni lehet hogy mi tortenik ha nem ugy mukodik ahogy szeretnem?

Hello,

Nalam is hasonlo dolgot kell megoldani, 2 adsl mindketto menjen annyi plussz funkcioval, hogy ha a belso halozatrol egy megadott portra csatlakoznak akkor ne az elsodleges hanem a masodik adsl-en menjen a kommmunikacio. A fenti linket vettem alapul s azon indultam el, vegulis ugy tunik, hogy a route-olas az szepen megy (kivulrol tudom pingelni mindket adsl-es ip-t), de mikor beallitottam tcpdump-al torteno ellenorzeskor kiderult, hogy a visszafele torteno kommunikacional a szerverig eljut de utana a belso halozati gepre mar nem.

A route tabla igy nez ki:

62.112.xxx.yyy dev ppp0 scope link src 62.112.xxx.yyy
62.112.192.150 dev ppp0 proto kernel scope link src 62.112.xxx.yyy
62.112.192.150 dev ppp1 proto kernel scope link src 62.112.zzz.zzz
192.168.6.0/24 dev eth1 proto kernel scope link src 192.168.6.253
default via 62.112.192.150 dev ppp1
default via 62.112.192.150 dev ppp0

ip route show table 4:

default via 62.112.192.150 dev ppp1

ip rule show:

0: from all lookup local
32763: from all fwmark 0x4 lookup 4
32764: from 62.112.zzz.zzz lookup adsl2
32765: from 62.112.xxx.yyy lookup adsl1
32766: from all lookup main
32767: from all lookup default

s vegul az iptables beallitasok:

iptables -t mangle -A PREROUTING -p tcp --dport 110 -s 192.168.6.0/24 -j MARK --set-mark 4
iptables -t nat -A POSTROUTING -o ppp0 -j SNAT --to 62.112.xxx.yyy
iptables -t nat -A POSTROUTING -o ppp1 -j SNAT --to 62.112.zzz.zzz

Van esetleg valakinek otlete mit szurhatok el? Tuzfal nem szurheti a dolgot, mar mindent engedelyeztem.

Thx,

Baktor