Eddig minden szép és jó, de kiderült, hogy van egy szolgáltatás (mondjuk a 8080-as tcp-porton), amit a 10.0.1.1-es lábon kell futtatni, és a 10.0.0.0/24 felől is el kell érni.
Eddig úgy gondoltam, hogy elég annyi, hogy:
iptables -t mangle -A PREROUTING -s 10.0.0.0/24 -d 10.0.1.1 -p tcp -m tcp --dport 8080 -j CONNMARK --set-mark 0x75
ip rule add prio 10 fwmark 0x75 table 100
ip ro add default via 10.0.1.254 table 100
de persze nem... Mi kell még?
- zeller blogja
- A hozzászóláshoz be kell jelentkezni
- 1045 megtekintés
Hozzászólások
Tobbszor elolvastam, de nem teljesen ertem a probemat.
Kozelitsuk meg szigoruan halozatos oldalrol a dolgot. Az elso kerdes, hogy mi a cel? Ha jol ertelmezem, akkor a gepbol egy routert szeretnel csinalni.
Tehat van 2 laba a routernet (gepnek):
- 10.0.1.1 /24 gw:10.0.1.254 (o egy masik router, akinek van atjarasa a tobbi halozatba?)
- 10.0.2.1 /24 (itt ki a gw?)
A cel az, hogy a 10.0.0.0/24-es halozatbol el lehessen erni a 10.0.2.0/24 halozatot a routeren (a gepeden) keresztul. Ehhez egy interface kell a 10.0.0.0/24 halozatban is, hogy egyaltalan megerkezzenek a csomagok. Ezutan lehet beallitani a routingot es persze az sem art, ha a hostok mindket halozaton ugy vannak beallitva, hogy a gateway a router egy-egy megfelelo laba.
"A 10.0.0.0/24 irányába a gw a 10.0.2.254 (örökség, más okból nem módosítható)" Ez butasag, a gatewaynak nyilvanvaloan az adott halozaton kell lennie. Ez azert mukodott eddig, mivel a host nem ismerte a kijaratot (gatewayt), ezert broadcastban kuldte a csomagokat, hatha valaki ismeri a kijaratot (a geped ismerte es tovabbitotta).
"amit a 10.0.1.1-es lábon kell futtatni, és a 10.0.0.0/24 felől is el kell érni" Ehhez a routeren mindket halozatban kell egy interface, amit beallitasz mindket halozaton levo hostoknak default gatewaynek es persze beallitod, hogy routoljon a gep (es egyaltalan mit jelent az, hogy egy labon kell futtatni?).
Kerlek egy egyszeru abran razold le a halozatokat, hogy tiszta legyen a kep, es hogy honnan mit kell elerni.
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
Megpróbálom egyszerűbben: A 10.0.0.0/24 felől el kell érni a 10.0.1.1 és a 10.0.2.1 lábon lévő szolgáltatásokat, a megfelelő interfész felől érkezve. Jelenleg a szerverről a 10.0.0.0/24 a 10.0.2.0/24 hálózat gw-e felé (10.0.2.254) felé van routolva, tehát a 10.0.2.2 lábon lévő szolgáltatást elérik.
Az a kérdés, hogy a 10.0.1.1-es lábra bejövő csomagra hogyan lehet ugyanazon a lábon választ küldeni?
- A hozzászóláshoz be kell jelentkezni
Ne haragudj, de meg igy sem ertem sem az alapfelallast, sem az elerendo celt.
Tehat van egy router a halozaton, ami megfeleloen mukodik, routol a 10.0.0.0/24 es a 10.0.2.0/24 kozott?
Ezen kivul van egy host (a szervered), aminek van egy 10.0.2.2/24-es laba, ezt elerik a routeren keresztul? Mi a feladat? Van egy 10.0.1.1/24 laba is?
Vagy a szerverbol szeretnel routert csinalni?
Kerlek rajzolj egy fizikai es egy logikai topologiat, mert nagyon kodos a kep, nem tiszta az sem, hogy most hogy nez ki a halozat es az sem, hogy mit szeretnel megoldani.
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
Volt kettő gép, 10.0.1.1 és 10.0.2.1. Ebből lett egy gép, két interfésszel. A 10.0.0.0/24 -nek el kell érni mindkét címen az ott futó szolgáltatásokat (a szolgáltatások, pl. a httpd csak megadott ip-címen hallgat, a másik cím felől nem szabad elérhetővé tenni). A szolgáltatásoknak maradni kell az adott interfészen, nem válthatnak címet, illetve a szerver nem route-olhat a két lába között.
Ha egyszerűsítem, akkor van egy router, ami a 10.0.0.0/24, 10.0.1.0/24 és 10.0.2.0/24 között végzi a routingot (valamennyi interfészének a címe a megfelelő hálózatból a .254). Az utóbbi két hálózatban van egy-egy lába a szervernek, (10.0.1.1 és 10.0.2.1).
+-------------------+ +-----------------+
| szerver | | router | +-------------------+
| eth2: 10.0.1.1 +--------+ 10.0.1.254 | | kliensek |
| | | 10.0.0.254 +--+ 10.0.0.0/24 |
| eth3: 10.0.2.1 +--------+ 10.0.2.254 | | defgw: 10.0.0.254 |
| | +-----------------+ +-------------------+
| defgw: 10.0.1.254 |
| 10.0.0.0/24 a |
| 10.0.2.254 felé! |
+-------------------+
A "router" egy komplex hálózat, forgalomszűréssel és több más kijárattal és hálózati zónával.
- A hozzászóláshoz be kell jelentkezni
Koszonom, egy fokkal tisztabb a kep.
A kerdes mar csak az, hogy pontosan mi lenne a feladat?
Kinek kell, mire, hol valaszolni?
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
10.0.0.0/24 felől érkeznek a kérések:
-a 10.0.2.1:1234-re, erre a válasz szépen megy arra (10.0.2.254), amerről a kérés jött.
-a 10.0.1.1:8080-ra, innen a válaszcsomagoknak a 10.0.1.254 felé kéne elindulni - na ez az, ami nem megy.
- A hozzászóláshoz be kell jelentkezni
Kerlek probalj meg egy kicsit bovebben es reszletesebben fogalmazni, mert igy nem konnyu kitalalni, mit szeretnel.
Tehat a 10.0.1.1re honnan erkezik keres? A 10.0.0.0/24 felol? Merre megy ki jelenleg a valasz? Gondolom a 10.0.2.1 interfacen.
Ha a szervered routing tablajaban az van benne, hogy a 10.0.0.0/24 a 10.0.2.254 fele van, akkor nyilvan arra fogja kuldeni a csomagokat, nem a masik iranyba, annak ellenere, hogy onnan erkezett. A routeren kell bekonfiguralni, hogy fogadja el ezeket a csomagokat es tovabbitsa.
A masik, amit nem ertek, hogy a szerveren levo 2db interface kozul, csak az egyikhez van default gateway. A masikhoz miert nincs? Latom, hogy be van irva a 10.0.2.254, de azt csak a 10.0.2.1 cimnel fogja figyelembe venni, a 10.0.1.1 egy masik VLANban, masik tartomanyban van. Ez nem tarotzik szorosan a problemahoz, csak megjegyzem.
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
eth2 Link encap:Ethernet HWaddr 00:00:00:AA:BB:CC
inet addr:10.0.1.1 Bcast:10.0.1.255 Mask:255.255.255.0
eth3 Link encap:Ethernet HWaddr 00:00:00:AA:BB:DD
inet addr:10.0.2.1 Bcast:10.0.2.255 Mask:255.255.255.0
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.1.254 0.0.0.0 UG 0 0 0 eth2
10.0.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth2
10.0.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth3
10.0.0.0 10.0.2.254 255.255.255.0 UG 0 0 0 eth3
A 10.0.0.0/24 felől jön kérés a 10.0.2.1-re, amire a válasz a routing alapján azon a lábon megy vissza, ahonnan jött - pipa.
Jön kérés a 10.0.1.1-re is, na az erre menő választ kéne ugyanott (eth2) visszaküldeni, ahol bejött. (Az eth0 és eth1 lábak nincsenek felkonfigurálva)
- A hozzászóláshoz be kell jelentkezni
Ha a routing tabla szerint a 10.0.0.0/24 a 10.0.2.254 fele van (marpedig amit irtal, abbol ez derul ki), akkor nem fogja a 10.0.1.254 fele kuldeni, attol fuggetlenul, honnan erkezett a csomag.
A kerdes, hogy miert ilyen fontos, hogy o ott valaszoljon?
Nem jo az, hogy a 10.0.1.1 a felado, a szerver megroutolja es a 10.0.2.1-en kimegy? A csomagnak igy a forrasa a 10.0.1.1 lesz, ha ez fontos.
Szerintem nem lehet megeroszakolni a szervert, hogy mindenkeppen ott valaszoljon, ahol kapta a csomagot, de ebben nem vagyok teljesen biztos, egy Linux szaki majd ezt jol megmondja. Csodalkoznek, mert ezzel azt mondjuk, hogy van routing tabla, csak nem vesszuk figyelembe.
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
Az ábra, meg az itt közölt scenario egy végletekig leegyszerűsített változat, a "router"-nek nevezett eszköz egy összetett hálózat, tűzfalakkal, több egyéb eszközzel.
A "miért arra" kérdésre egyszerű a válasz: csak a szerveren lehet módosítani, a kliensen, illetve a kettő közötti hálózaton nem, vagy nem egyszerűen. Egyébként meg kettő darab routing tábla van, az egyik a "normál" forgalomra, amiben a defgw 10.0.1.254, és amiben ott van, hogy a 10.0.0.0/24 a 10.0.2.254 felé van, meg egy másik, amiben meg a 10.0.2.254 a defgw, és ami alapján routolni kéne azokat a forgalmakat, amik a 10.0.0.0/24 felől beszélgetnek a 10.0.2.1:8080-as portjával. Erre lenne a connmark, meg az ip rule, amit helyre kéne rakni.
- A hozzászóláshoz be kell jelentkezni
2 routing tabla???
Ezt hogyan lehet megvalositani? Mi alapjan dol el, hogy eppen melyik routing tablat hasznalja a gep? Errol tudnal valami leirast kuldeni?
A megoldas, amit irtam, az nem jo (10.0.1.1 felad, megroutol, 10.0.2.1-en kimegy)
---
Tetragir
- A hozzászóláshoz be kell jelentkezni
Igen, két routing tábla. Vagy három. Vagy x darab. Policy Based Routing. Na ez nem akar összeállni, bár a héten nem nagyon tudtam vele foglalkozni.
- A hozzászóláshoz be kell jelentkezni
Amikor utoljara foglalkoztam vele, akkor a CONNMARK es a MARK nem volt harmonizalva (kellett egy kulon iptables szabaly, hogy a CONNMARK-ot MARK-ra masoljam.) Az ip rule a sima MARK-ot hasznalta.
- A hozzászóláshoz be kell jelentkezni
up
- A hozzászóláshoz be kell jelentkezni