Szevasztok!
A megoldandó feladatom lényege tömören: load balancing az adott két interfészen kifelé. Az elvárás az, hogy a hoston létrejövő új kapcsolatokat az egyenletesebb terhelés stb. miatt egyszer az egyik, másszor pedig a másik hálózati útvonalra route-olja. A létrejött kapcsolat ezután marad az adott útvonalon.
Meg tudtam oldani (ip, iptables), hogy ha van egy wifi és egy ethernet kapcsolat ugyanazon a gépen, akkor ott működjön a balancing. Fontos részlet, hogy mindkét kapcsolathoz adott volt egy gateway.
Most azt kellene megoldanom, hogy egy peer-to-peer (modemes 3G) kapcsolat és az ethernet között működjön a load balancing. (A végső cél az, hogy bármilyen két interfész között működjön). Sajnos azonban a p2p kapcsolatnál (általában) nincs GW, így itt sem. Van egy IP, amit a ppp0 kap, és van egy remote IP (most 10.64.64.64).
Sajnos a hálózatokhoz nem értek igazán jól, így ha van itt valaki, aki netalántán igen, az nyugodtan világosítson fel az esetleges tárgyi tévedéseimről :)
Kérdés 1: p2p esetében, ha csatlakozni akarok pl. az 5.6.7.8 hosthoz, akkor technikailag kimegy egy csomag a remote address-re (10.64.64.64)? A pppd azt írja, "couldn't determine remote IP address, defaulting to 10.64.64.64, ezek szerint ez nem egy túl releváns cím. Akkor ha jól sejtem, simán 5.6.7.8-nak címzi a rendszer a csomagokat, és a p2p vonal másik végén lévő szerver ezt kiolvassa, továbbküldi a packetemet?
Olvasgattam mindenféle ip meg linux routing leírást, példákat, de még sajnos mindig nem teljesen egyértelmű a routolás. Az /etc/iproute2/rt_tables alatt vannak definiálva a táblák, legnagyobb számmal (prioritás?) a local, utána main, default és a sajátjaim.
Kérdés 2: ha egy routolási szabály illik pl. a main táblában a bejövő csomagra, akkor elirányítja a csomagot és befejezi a további táblák olvasását, igaz?
Úgy általában egy kissé konfúz számomra a kernel route táblák és az iptables együttműködése, hogy melyik mikor és hogyan lép be. Mert odáig rendben van, hogy a kernel a táblák alapján irányít el csomagokat, de az nincs rendben, hogy az iptables is tud irányítgatni csomagokat. Rendben, ismerem ezt http://jengelh.medozas.de/images/nf-packet-flow.png de nincs valami általános "ökölszabály"?
--------------------------
Akkor a konkrét gond:
Az rt_tables-ben két táblám van:
202 eth
200 ppp
Felhozom az eth0-t, ppp0-t. Route tábla:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.64.64.64 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 202 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 202 0 0 eth0
Tehát a ppp0 már itt sem látszik, csak a 10.64.64.64-es kamu címen.
eth route tábla az eth0 GW felé routoljon:
ip route add default via 192.168.2.1 table eth
ppp route tábla, de hova routoljon?
ip route add to 0.0.0.0/0.0.0.0 dev ppp0 table ppp
iptables szabályok, melyek megjelölik az eth0/ppp0-ról induló csomagokat:
iptables -t mangle -A OUTPUT -o eth0 -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -o eth0 -m state --state new -m statistic --mode random -probability 0.5 -j MARK --set-mark 2
iptables -t mangle -A OUTPUT -o ppp0 -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -o ppp0 -m state --state new -m statistic --mode random -probability 0.5 -j MARK --set-mark 2
Policy routing, azt akarom, hogy a jelölésnek megfelelő routing táblára fusson rá (de mintha a main-t előtte mindig lefuttatná?!):
ip rule add fwmark 1 table eth
ip rule add fwmark 2 table ppp
Majd a NAT:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Legvégül:
ip route flush cache
Name serverek a google DNS serverekre vannak állítva.
Eredmény:
Egymás után több kapcsolatot indítok (letöltés), de mindig az eth0-n megy ki.
iptables -t mangle -nvL
Chain PREROUTING (policy ACCEPT 4617 packets, 6571K bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 4617 packets, 6571K bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 2756 packets, 143K bytes)
pkts bytes target prot opt in out source destination
11 660 MARK all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW MARK set 0x1
4 240 MARK all -- * eth0 0.0.0.0/0 0.0.0.0/0 state NEW statistic mode random probability 0.500000 MARK set 0x2
0 0 MARK all -- * ppp0 0.0.0.0/0 0.0.0.0/0 state NEW MARK set 0x1
0 0 MARK all -- * ppp0 0.0.0.0/0 0.0.0.0/0 state NEW statistic mode random probability 0.500000 MARK set 0x2
Chain POSTROUTING (policy ACCEPT 2756 packets, 143K bytes)
pkts bytes target prot opt in out source destination
Itt látszik, hogy a mangle táblában tényleg megjelölt kapcsolatokat/csomagokat 1-gyel és 2-vel, de kifelé már csak az eth-n megy. Ezek szerint:
-1) vagy rossz a ppp táblába elhelyezett szabályom --> mit tegyek be helyette?
-2) előbb fut le a main tábla, és mivel ott az első default gw az ethernet gw, ezért oda küldi ki;
Tud valaki segíteni? (tudom, nem egyszerű :))
- 3673 megtekintés
Hozzászólások
Hali!
Lehet, hogy hulyeseget mondok, de szerintem a route-olas elott kene megjelolni a csomagokat, es nem utana (persze ekkor a -o nem ertelmes, esetleg a -i):
iptables -t mangle -A PREROUTING -m state --state new -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -m state --state new -m statistic --mode random -probability 0.5 -j MARK --set-mark 2
- A hozzászóláshoz be kell jelentkezni
Ezt már próbáltam korábban is, és ugyanúgy működött. A wifi-ethernet párossal direkt kipróbáltam, és mindkét variáció jó volt...
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Az rt_tables-ben két táblám van:
202 eth
200 ppp
Felhozom az eth0-t, ppp0-t. Route tábla:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.64.64.64 * 255.255.255.255 UH 0 0 0 ppp0
192.168.2.0 * 255.255.255.0 U 202 0 0 eth0
default 192.168.2.1 0.0.0.0 UG 202 0 0 eth0
Tehát a ppp0 már itt sem látszik, csak a 10.64.64.64-es kamu címen.
eth route tábla az eth0 GW felé routoljon:
ip route add default via 192.168.2.1 table eth
ppp route tábla, de hova routoljon?
ip route add to 0.0.0.0/0.0.0.0 dev ppp0 table ppp
nem jó parancsokat használsz, emiatt fogalmi zavaraid keletkeztek.
a közelebbi tanulmányozásra javasolt parancsok:
ip rule list
ip route list table xyz
a "route", meg a "netstat -r" parancsokat kb. felejtsd el örökre.
a működés rendszere:
elindulunk az ip rule list által prezentált rule listán, sorszám szerint növekvő sorrendben, minden match esetén végrehajtjuk az ott levő tevékenységet. ez jelentheti a folyamat végét (pl. unreachable esetén "nem nyert"), vagy ha egy konkrét routing táblát nevez meg az a szabály, akkor azt a routing táblát végignézzük. ha a routing táblában van találat, akkor véget ért a folyamat, ha egyáltalán nincs a routing táblában megfelelő sor, akkor a rule táblában megyünk tovább. ez nyilván csak akkor lehetséges, ha abban a routing táblában nincs default route, hiszen az mindenre illeszkedne.
- A hozzászóláshoz be kell jelentkezni
nem jó parancsokat használsz, emiatt fogalmi zavaraid keletkeztek.
Fogalmi zavaraim egészen biztosan vannak, azért is dobtam be ezt a témát...
ip rule list
ip route list table xyz
Na most ezek miben különböznek az "ip rule" és "ip route show table" parancsoktól? Mintha úgy rémlene, hogy a list == show. És ezeket bizony ismerem.
A vázolt helyzetben az ip rule kimenete két sort tartalmaz, kb. ilyen tartalommal:
fwmatch 1 --> table eth
fwmatch 2 --> table ppp
Más egészen biztosan nincs benne.
A "route" kimenete nem más, mint "ip route show" vagy "ip route show table main", ez is világos volt eddig.
elindulunk az ip rule list által prezentált rule listán, sorszám szerint növekvő sorrendben, minden match esetén végrehajtjuk az ott levő tevékenységet. ez jelentheti a folyamat végét (pl. unreachable esetén "nem nyert"), vagy ha egy konkrét routing táblát nevez meg az a szabály, akkor azt a routing táblát végignézzük. ha a routing táblában van találat, akkor véget ért a folyamat, ha egyáltalán nincs a routing táblában megfelelő sor, akkor a rule táblában megyünk tovább. ez nyilván csak akkor lehetséges, ha abban a routing táblában nincs default route, hiszen az mindenre illeszkedne.
Ezek szerint a legkisebb prioritásútól megyünk a legnagyobb felé (a main asszem 254 vagy vmi ilyesmi számmal rendelkezik).
Ha van találat, de nem default route, akkor végrehajtjuk, megyünk tovább?
Ha van találat és az default route, akkor végrehajtjuk és nem megyünk tovább?
Ha így van, akkor az esetemben annyi a baj, hogy a ppp0 interfészre nem tudtam jó route szabály alkotni (ezt mondjuk eddig is sejtettem), mert amúgy ezzel a logikával wlan-eth párossal szépen megy a dolog...
[NEM ÉRTEM
Wifi-eth páros esetén: jól működött, de úgy, hogy az eth táblában is volt egy default route (eth0 gw felé), a wifi táblában is (wlan0 gw felé), és a main táblában mind az eth0, mind pedig a wlan0 default route-ja benne volt. Ha a main táblából ezeket kivettem (wlan0, eth0 default gw), de bennehagytam az altáblákban, akkor nem akart működni, és nem értem miért, hiszen az altáblákban egyértelműen benne volt a default útvonal, elvileg ott lett volna match és arra kellett volna mennie a csomagnak. Vagy esetleg az altáblákban definiált default útvonalak mindegyikét definiálni kell a main-ben is?
]
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Ha van találat, de nem default route, akkor végrehajtjuk, megyünk tovább?
Ha van találat és az default route, akkor végrehajtjuk és nem megyünk tovább?
Ha van találat a routing táblában, akkor végrehajtjuk, és nem megyünk tovább a rule listán.
Ha van default route abban a routing táblában, akkor sosem fordulhat elő, hogy nincs találat, ergó a rule listán sosem megyünk tovább. Ezt sokan be szokták nézni.
--------------------
Szerintem koncepcionálisan nem jó az, ahogyan ezt szeretnéd csinálni.
Amíg nincs routolva a csomag, addig a -o opcióval nem tudsz matchelni a kimenő interfész szerint (mert még nem tudja a rendszer, hogy hol fog kimenni), ha pedig már matchel, akkor már megtörtént a routolás (ugye a main tábla szerint, mivel nem volt még fwmark), ergó már hiába akarsz fwmarkot beállítani, és az alapján másfele routolni. Ez így 22-es csapdája.
- A hozzászóláshoz be kell jelentkezni
Megoldási javaslat: OUTPUT helyett PREROUTING, és nem -o, hanem -d alapján matchelni.
------------
Visszavontam: nem kell OUTPUT helyett PREROUTING, ha helyben generált forgalomról beszélünk (a PREROUTING csak az áthaladó forgalomra vonatkozik), de a -o akkor sem tud matchelni.
- A hozzászóláshoz be kell jelentkezni
Természetesen helyben generált forgalomról van szó, asszem írtam is a legelső postban. A cél, hogy a kifelé induló kapcsolatok egy része az egyik, másik része a másik interfészen menjen ki.
PREROUTING-nál -i kell, ez eddig is világos volt, mint már mondtam, az eth-wifi-re jól működik a dolog, és ott kipróbáltam PREROUTING-gal és OUTPUT-tal is, megfelelő -i -o kapcsolókkal, mindkettő jó volt.
Megnézem a -d kapcsolót, kösz.
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
(sub)
szerk.: én is ezen a témán rugózok most, egy elég jó leírást találtam, nem biztos hogy segít, de jól magyaráz:
http://www.diegolima.org/wordpress/?p=36
- A hozzászóláshoz be kell jelentkezni
Kösz a linket, már én is megtaláltam, és kiindulásnak tényleg nagyon jó. Ő viszont olyan esetet mutat be, amikor a két interfészhez tartozik egy-egy gateway is, és ez az eset nálam is jól működik. Az én problémám az, hogy wifi-ppp között szeretnék ilyen elosztást, csakhogy bekavar az, hogy a ppp-nél nincs gateway (tudom, van olyan ppp kapcsolat, ahol van, de erre is működnie kell), és mindjárt nem működik a balancing. Valószínűleg az a baj, hogy nem tudtam megfelelő routing szabályt kitalálni a ppp interfészre...
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
látatlanban beszélek, de hirtelen úgy próbálnám, hogy ha boot-kor beállítódik a main route táblába a PPP, akkor már csak a wifi-nek hoznék kézzel létr egyet, és a PPP felé a main táblán keresztül route-olnám, így nem kell semmilyen gw-t beállítani mivel nincs is. A postrouting résznél csak az interface neve és külső IP címét kell megadni, tehát nem látok gondot a dologban, igaz nem próbáltam :)
- A hozzászóláshoz be kell jelentkezni
Én erre azt a megoldást csinálnám inkább, hogy a ppp a default route-ot ne a main táblába tegye bele (dhclient-tel pl. meg lehet csinálni, hogy a script, amit lefuttat, más parancsot futtasson, és így másik táblába tud kerülni a default route; a ppp-nél talán a /etc/ppp/ip-up, meg hasonlókkal lehet játszani egy nodefaultroute mellett).
Az a gond, hogy a 'CONNECTED' típusú route-ok (amik nem gateway-re, hanem interfészre mutatnak) a main táblába kerülnek, és azokat preferálni kéne a távolabbi route-okkal szemben (a gateway-re mutató, pl. a default route), különben meglepő élmények tudnak következni.
- A hozzászóláshoz be kell jelentkezni
ezt a preferálás végezné az SNAT szabály (fenti link).
amúgy persze felvehető másik route táblába is, ennek én sem látom akadályát --> main-ből kivesz, új rule létrehoz, majd ide ugyanaz beír.
- A hozzászóláshoz be kell jelentkezni
Az esetemben nem azzal van a baj, hogy hol van a PPP routeolási szabálya, és nem is azzal, hogy hol az etherneté.
Furcsán működik a routolás. Jelenlegi tudásom szerint a mangle tábla PREROUTING lánca a routolás előtt kell, hogy lefusson, és az eth-wifi esetben ez meg is történik tökéletesen. Viszont a ppp-eth esetben nem, azaz a PREROUTING csak azután fut le, hogy a main táblából már kivette a default route-ot, ez pedig így számomra nagyon nem világos és nem is jó. Mindenesetre még mindig úgy gondolom, hogy én rontottam el valamit, csak nem tudom, mit, hogy miért viselkedik máshogy a mangle tábla/routolás, mint eth-wifi esetben.
De miből tűnik úgy, hogy rosszul működik?
Adott ez (ppp + eth eset):
ip route show:
10.64.64.64 dev ppp0 proto kernel scope link src 94.44.62.203
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.2 metric 202
default dev ppp0 scope link
(Kitöröltem a szabályt, ami default gw ethernet felé irányít, az utolsó szabály szerint a default csomagok a ppp0-n mennek ki)
A többi lépés:
ip route add default via 192.168.2.1 table eth
(ip route show table eth:
default via 192.168.2.1 dev eth0)
iptables -t mangle -A PREROUTING -i eth0 -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -i ppp0 -j MARK --set-mark 1
ip rule add fwmark 1 table eth
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
ip route flush cache
A beállítások szerinti routing policy értelmében _minden_ csomagot az eth0-n kellene kiküldenie. Indítok néhány letöltést, és mégis _mindig_ a ppp0-n megy ki, pedig az eth-n kellene kimennie, mert az 1-es mark az eth táblára mutat.
Módosítás:
ip rule add fwmark 1 table eth --> ip rule add from 94.44.62.203 table eth
Azaz olyan szabályt alkotok, ami a ppp0 interfészről (94.44.62.203 a címe) jövő csomagokat az eth tábla szerint routolja minden korábbi előzmény és feltétel nélkül, és láss csodát, ekkor az eth0-n mennek ki a csomagok! (tehát szépen kiveszi az eth altáblából és alkalmazza is)
Ezek szerint itt mindenképpen valami gond van. Úgy tűnik, mintha az iptables PREROUTING a mangle táblára a routolás _után_ futna le ebben az esetben, mert az iptables -t mangle -nvL kimenetben látszik, hogy nőttek a számlálók, tehát be lett állítva az fwmark értéke, de már későn, mert a routolás megtörtént.
Ezt magyarázza meg nekem valaki, mert ugyanezzel a felépítéssel/logikával eth + wifi esetben tökéletesen működik minden!
Az a gond, hogy a 'CONNECTED' típusú route-ok (amik nem gateway-re, hanem interfészre mutatnak) a main táblába kerülnek, és azokat preferálni kéne a távolabbi route-okkal szemben (a gateway-re mutató, pl. a default route), különben meglepő élmények tudnak következni.
Ez lehet, hogy egy olyan ún. "meglepő élmény"?
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Furcsán működik a routolás. Jelenlegi tudásom szerint a mangle tábla PREROUTING lánca a routolás előtt kell, hogy lefusson, és az eth-wifi esetben ez meg is történik tökéletesen. Viszont a ppp-eth esetben nem, azaz a PREROUTING csak azután fut le, hogy a main táblából már kivette a default route-ot, ez pedig így számomra nagyon nem világos és nem is jó.
Én is ezt hittem, aztán elolvastam a doksit. Persze a tapasztalataiddal sem vág egybe, de enyéimmel igen: a mangle/PREROUTING a forwardolt (in -> out) packetokra fut le a routing előtt, a mangle/OUTPUT a helyben generált (-> out) packetokra fut le a routing előtt. A nevükkel ellentétben... Van még egy tudnivaló: a routing döntés a route cache miatt az első packetnél eldől, onnantól kezdve már hiába variálsz.
mangle:
This table is used for specialized packet alteration. Until
kernel 2.4.17 it had two built-in chains: PREROUTING (for
altering incoming packets before routing) and OUTPUT (for
altering locally-generated packets before routing). Since
kernel 2.4.18, three other built-in chains are also sup-
ported: INPUT (for packets coming into the box itself), FOR-
WARD (for altering packets being routed through the box),
and POSTROUTING (for altering packets as they are about to
go out).
Ez lehet, hogy egy olyan ún. "meglepő élmény"?
Nem, az általam ismertetett élmény az lehet pl., hogy az ethernet hálózatodon van egy 192.168.1.1/24-es cím, a gépedről induló 192.168.1.2-re címzett forgalom meg az ethernet láb helyett kimegy a default route-on keresztül a ppp másik végpontjára, mert a default route "előbbre való" lesz a rule-ok miatt.
Persze ezt ki lehet védeni, ha tudod, hogy milyen címek vannak direktben az ethernet lábon, de ha pl. dhcp-vel kapod a címet egy kábelnetes szolgáltatótól, aki néha más címtartományból oszt, akkor arra nem tudsz szabályt írni, ott mindenképpen a main routing táblát kell előre sorolnod - de akkor viszont abban nem lehet default route.
- A hozzászóláshoz be kell jelentkezni
Mivel a tesztelésre wget-es letöltést használok, ezért a kapcsolat az én gépemről indul ki, tehát legalább a mangle/OUTPUT-nak illeszkednie kellene rá. És mint mondtam, eth-wifi esetben illeszkedik is, csak eth-ppp esetben nem, pedig a séma ugyanaz. És a letöltési teszt is mindkét esetben ugyanaz. Az meg, hogy az adott kapcsolathoz bekerül a route cache-be, jó is, mert nem akarom, hogy két itf-en jöjjön le egy "sessionhöz" tartozó adat. Azt akarom, hogy felváltva használja a rendszer mindkét interfészt, az nem izgat, hogy az egyes kapcsolatok mennyi ideig tartanak.
Ezért nem értem, hogy miért nem megy. A ppp-eth esetben is helyben generált csomagról van szó (HTTP request a szerver felé), de mégis, előbb route-ol és utána jön a mangle szabály. És hiába olvastam el korábban is a man iptables-ben az idézett részt, nekem mindig az jött le, hogy a mangle route-olás előtt dolgozik. Sőt, ez alapján is kb. erről van szó:
http://jengelh.medozas.de/images/nf-packet-flow.png
Mit csináljak tehát, hogy meg tudjam jelölni (1/2-vel) az újonnan létrejövő kimenő kapcsolataimat ppp-eth esetben?
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Mit raksz most az OUTPUT listába? Az eredeti felvetés szerint volt ott -o, ezt ugye kivetted?
Nekem pl. ilyenek vannak:
iptables -t mangle -A OUTPUT -j MARK -s 192.168.1.101 --set-mark 20
iptables -t mangle -A OUTPUT -j MARK -s 192.168.1.102 --set-mark 10
iptables -t mangle -A OUTPUT -j MARK -d 195.199.255.195 --set-mark 10
Azt a rule-ok szintjén oldom meg, hogy csak a még eldöntetlen forráscímű csomagok/streamek esetén van választás a mark szerint; ha már van uplink forráscíme a csomagnak, akkor már csak az ahhoz tartozó linken küldhetem ki. Akinek még nincs, az a mark szerint vagy az egyik vagy a másik uplinket kapja. Akinek meg markja sincs, az meg valami default policy szerint megy.
A rule lista:
0: from all lookup local
100: from all to 127.0.0.0/8 lookup main
100: from all to 10.0.0.0/8 lookup main
100: from all to 172.16.0.0/12 lookup main
100: from all to 192.168.0.0/16 lookup main
100: from all to 169.254.0.0/16 lookup main
100: from 127.0.0.0/8 lookup main
100: from 10.0.0.0/8 lookup main
100: from 172.16.0.0/12 lookup main
100: from 192.168.0.0/16 lookup main
100: from 169.254.0.0/16 lookup main150: from all to 127.0.0.0/8 unreachable
150: from all to 10.0.0.0/8 unreachable
150: from all to 172.16.0.0/12 unreachable
150: from all to 192.168.0.0/16 unreachable
150: from all to 169.254.0.0/16 unreachable200: from < uplink 1 lan cimek > lookup 100
200: from < uplink 2 lan cimek > lookup 200250: from < uplink 1 lan cimek > unreachable
250: from < uplink 2 lan cimek > unreachable300: from all fwmark 10 lookup 100
300: from all fwmark 20 lookup 200
32766: from all lookup main
32767: from all lookup defaultip route list table 100:
default via < uplink gw 1 > dev eth1 metric 10ip route list table 200:
default via < uplink gw 2 > dev eth2 metric 5ip route list table default:
default via < uplink gw 2 > dev eth2 metric 5
default via < uplink gw 1 > dev eth1 metric 10
a sima 'main' routing tablaban pedig nincsenek default route-ok.
- A hozzászóláshoz be kell jelentkezni
Megcsináltam iptables -t mangle -A OUTPUT -s -sel, nem segített. Variáltam is, úgy sem ment.
Odáig jutottam, hogy megjelöli a csomagokat, de vagy az eth0-ra nem akarja kiküldeni, vagy pedig a ppp0-ra. Meg tudom csinálni, hogy az egyikre kimenjen, de akkor a másikra nem fog.
Gyanús nekem ez a ppp...
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Akkor rakd be a két verziót (az iptables, az ip rule, meg az ip route parancsokat), hátha több szem többet lát.
- A hozzászóláshoz be kell jelentkezni
Ami nem megy:
ip route add default via $ETH_GW table eth
ip route add default dev ppp0 table ppp
iptables -t mangle -A OUTPUT -s $PPP_IP -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -s $PPP_IP -m state --state new -m statistic --mode random --probability 0.5 -j MARK --set-mark 2
iptables -t mangle -A OUTPUT -s $ETH_IP -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -s $ETH_IP -m state --state new -m statistic --mode random --probability 0.5 -j MARK --set-mark 2
ip rule add fwmark 1 table eth
ip rule add fwmark 2 table ppp
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
ip route flush cache
Ami megy (az ip rule-okkal játszva lehet az összes forgalmat a ppp vagy eth felé terelni, és úgy rendben is van, tehát maguk a routolási szabályok elvben jók)
ip route add default via $ETH_GW table eth
ip route add default dev ppp0 table ppp
iptables -t mangle -A OUTPUT -s $PPP_IP -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -s $PPP_IP -m state --state new -m statistic --mode random --probability 0.5 -j MARK --set-mark 2
iptables -t mangle -A OUTPUT -s $ETH_IP -m state --state new -j MARK --set-mark 1
iptables -t mangle -A OUTPUT -s $ETH_IP -m state --state new -m statistic --mode random --probability 0.5 -j MARK --set-mark 2
ip rule add from $ETH_IP table eth
ip rule add from $PPP_IP table ppp
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
ip route flush cache
- A hozzászóláshoz be kell jelentkezni
Kimenő kapcsolatnál source IP-d sincs (hacsak nem bindol az alkalmazás fixen source IP-t), amíg nincs megroutolva az első packet, hiszen a kimenő interfészből fogja megtudni, hogy melyik source IP-t kell választani...
- A hozzászóláshoz be kell jelentkezni
Tehát a helyes megoldás kb. így nézne ki:
iptable -t mangle -A OUTPUT -m state --state new -j MARK --set-mark 1
iptable -t mangle -A OUTPUT -m state --state new -j MARK --set-mark 2 -m statistic --mode random --probability 0.5
ip route add default via $ETH_GW table eth
ip route add default dev ppp0 table ppp
ip rule add from $ETH_IP table eth
ip rule add from $PPP_IP table ppp
ip rule add fwmark 1 table eth
ip rule add fwmark 2 table ppp
- A hozzászóláshoz be kell jelentkezni
Ez sem működik :(
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
És mi nem megy vele?
Mondjuk nekem gyanús az a 'default dev ppp', szerintem így nem lehet default routert ppp-n keresztül megadni, a next hop-ot kell gateway-ként kell beírni.
- A hozzászóláshoz be kell jelentkezni
Az fwmark-os móka, kb. mint előtte eddig mindig.
A "default dev ppp0" szerintem nem lehet bűnös, mert ha csak ppp kapcsolat van, akkor meg ezzel a szabállyal megy a kapcsolat.
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
még egy utolsó dolog: kutatok, és közben fent vl szerint ajánlott módon kellene talán megközelíteni:
vl: "a next hop-ot kell gateway-ként kell beírni..."
meg ez szerint is lehet a ppp ADSL kapcsolatodnál "default dev ppp0" helyett így kellene felvenni?
ip route add default via GW dev ppp0 table ppp
tehát úgy, ahogy lejjebb írtad a mobil-os ppp esetében. így is próbáltad már?
szerk.: kipróbáltam, a ppp gateway a fenti módon megadva is jól megy. a load balance még mindig nem.
- A hozzászóláshoz be kell jelentkezni
Ez érdekes. Erről csak az jut eszembe, hogy amikor TCP/IP kommunikációs itf-et írtam a processeink számára, akkor a bind lépésben mindig egy itf-hez kötöttem a socketet, ami így egyből meg is kapta az itf IP-jét. Nem zárom ki, hogy lehet máshogy is csinálni...
Tapasztalataim alapján úgy tűnik egyébként, hogy az alkalmazások az időben első itf-hez kötik magukat...
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
ugyanezt megcsináltam amit te, és tényleg mindig a ppp felé akar route-olni nálam is, mindegy hogy variálom a rule-okat.
csak akkor nem route-ol a ppp felé, ha eltávolítom a ppp default-ját, ekkor már a másik eth felé megy a forgalom.
up. up2.
- A hozzászóláshoz be kell jelentkezni
T-Mobile PPP kapcsolathoz van GW, azzal is meg tudtam csinálni a load balancingot (ethernet, ppp).
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
ennél mindegy volt hogy ha az egyik nic default gw route bejegyzése a main táblában volt vagy sem? mindkét esetben jól működött?
- A hozzászóláshoz be kell jelentkezni
Azt hiszem a main táblából az összes default route-ot kivettem. De ha nem is, akkor sem nehéz erre már rájönni kísérletezgetéssel :)
Amúgy kb így nézett ki a route része:
ip route add default via 192.168.2.1 table eth
ip route add src 0.0.0.0 to 79.122.89.185 dev ppp0
ip route add default via 79.122.89.185 table ppp
79.122.89.185 a ppp GW-e, 192.168.2.1 pedig az etherneté.
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
köszi. ugyanez nálam :)
- A hozzászóláshoz be kell jelentkezni
PPP probléma megkerülésére van egy születőben lévő ötletem, nem tudom, mennyire lehet megvalósítani.
A dolog lényege, hogy magunk készítenénk egy GW-t. Ez lehetne pl. egy virtuális hálózati itf saját IP-vel.
+----------+
ppp0 <--- itf0 <--- | ROUTING | <--- input packages (locally generated)
net <--- eth gw <--- | DECISION |
+----------+
Az itf0 tehát szimplán csak forwardolná a ppp0 felé a csomagokat, viszont a mangle - mark stb., routing rendszerben ő lenne benne a ppp0 helyett, így lehet, hogy megjavulna a problémám (mégpedig, hogy eth-ppp esetben routolási döntés után kapja meg a MARK számot).
- A hozzászóláshoz be kell jelentkezni
Ezzel is vannak gondjaim.
Előszőr elviekben teszem fel a kérdést, hogy lehetséges-e ilyet csinálni:
-1) tunctl-lel készítek egy tap0 eszközt;
-2) tap0 eszköz kap egy saját IP címet és egy alhálózatot;
-3) tap0 IP-re érkező minden csomagot áttolunk az eth0 gw címre (az meg kiküldi a nagyvilágba);
-4) az eth0 gw-re beérkező minden csomagot átküldünk a tap0 IP-re;
-5) nem feltétel, hogy az eth0 magában működőképes maradjon;
-6) az kell, hogy tap0-n keresztül menjen pl. a ping;
Ezzel tesztelem:
ping -I tap0 index.hu
A válasz "destination host unreachable", viszont tcpdump -i tap0 ezt írja:
ARP, request who-has 217.20.130.97 tell 192.168.10.1
Névfeloldás megy. Arra gyanakszom, hogy a válasz már nem tud visszajönni.
Script:
#!/bin/bash
ETH_GW=192.168.2.1
ETH_IP=192.168.2.2
TAP0_IP=192.168.10.1
echo "1" > /proc/sys/net/ipv4/ip_forward
echo "1" > /proc/sys/net/ipv4/conf/all/forwarding
# Default state
ip rule del from $ETH_IP 2>/dev/null
ip rule del from $PPP_IP 2>/dev/null
ip rule del from $TAP0_IP 2>/dev/null
ip rule del from $ETH_GW 2>/dev/null
ip rule del from $TAP0_IP 2>/dev/null
ip route flush table eth
ip route flush table ppp
ip route flush table tap
iptables -F -t filter
iptables -F -t mangle
iptables -F -t nat
iptables -F -t raw
tunctl -d tap0
# We definitely need a nameserver
echo "nameserver 192.168.2.1" >> /etc/resolv.conf
tunctl -t tap0
ifconfig tap0 $TAP0_IP up
ip rule add from $TAP0_IP to $ETH_GW
ip rule add from $ETH_GW to $TAP0_IP
ip rule add nat $ETH_GW from $TAP0_IP
ip route flush cache
Innen talán hiányzik egy "iptables -t nat -A POSTROUTING -o eth0/tap0 -j MASQUERADE" sor, de egyrészt ha betettem sem lett jobb, másrészt már az ip rule (ha jól csináltam) elvégzi a NAT-nál a címcserét (eth GW címét lecseréli a tap0 címre, hogy oda jöjjön vissza a válasz) - már ha nem rontottam el...
Szerintetek mit rontottam el?
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Ez így hülyeség lesz, mágegyszer átolvasva a TUN/TAP leírást ez nem erre való.
Akkor hogyan csináljak virtuális interfészt, valaki tudja? Bridge utils?
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
Ezen a wifi-n gondolkodom: beilleszteni a körbe úgy, hogy
kap egy fix ip-t és kifelé ezen keresztül megy a ppp.
Ezt lehetne?
- A hozzászóláshoz be kell jelentkezni
Valaki próbálta már a ppp multilinket? Megy ez pl. Vodafone és T-Mobile kapcsolatokkal, vagy a multilink minden egyes csatornája ugyanahhoz a szolgáltatóhoz kell, hogy tartozzon?
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
subscribe
---------------------------------------------------
Talisker Single Malt Scotch Whisky aged 10 years :)
- A hozzászóláshoz be kell jelentkezni
nem jutottál semmire?
- A hozzászóláshoz be kell jelentkezni
Nem... azóta máson kell dolgoznom. Van itt kollega, aki látott már közelről ppp kernel modult, és az ő véleménye szerint a ppp kissé össze van "tákolva", emiatt úgy gondoljuk, hogy lehet, hogy ezért működik furcsán. Én most nem állok neki ppp modult javítani a kernelben... ;)
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
En is szeretnek egy load balance-ot, szinten egy alhalozatos net es egy ppp kozott.
Urak, segitsetek, hadd tanuljak valamit ismet!
Irtad: "Sajnos azonban a p2p kapcsolatnál (általában) nincs GW, így itt sem. Van egy IP, amit a ppp0 kap, és van egy remote IP (most 10.64.64.64)."
Viszont en a kovetkezot olvastam:
angband:/etc/ppp/peers# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
MY.GA.TE.WAY 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0
MY.GA.TE.WAY 0.0.0.0 255.255.255.255 UH 0 0 0 ppp1
10.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 eth2
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 ppp0
Itt olvastam:
http://www.debian-administration.org/articles/379
Nem tudom, hogy neked a MY.GA.TE.WAY helyen van-e adat, de a leiras azt feltetelezi, hogy ez a ppp gw-je.
En ez alapjan probalkoztam (nalam mindig ua. az ip epult be a route tablaba a jelolt helyre), tehat azonosultam az elgondolassal.
Sajnos megsem sikerult megcsinalnom, mert a linken lathato leiras elsore tul sokat tud (jobb szeretek elso lepesben egy egyszerubb feladatot ellato "deszkamodellt" osszerakni, aztan szepitgetni a mukodest a kulonbozo esetekre), igy nem estem meg neki ido hijan az ertelmezgetesnek es sajat igenyekre faragasnak, ennelfogva az itt leirtak sajat konfiguracioval valo kiprobalasanak sem.
Mas leirasok alapjan viszont nem jott ossze. Vagy nem volt a Natolt alhalozatban net, vagy egy poff - pon paros utan csak a ppp-t hasznalta.
Valaki nem tud egy gyorstalpalot tartani, hogy mit kell lefuttatni, es az mit is tesz?
Akar egy egyszerubb leirasbol kiindulva.
Pl. ebbol:
http://lartc.org/howto/lartc.rpdb.multiple-links.html
Ha ertenem, akkor tudnek otletelni, vajon mi miatt nem megy.
Vagy legalabb arra kellene utmutatas, hogy ha nem megy, hogyan lehet nyomon kovetni az iptables altal vizsgalt mindenfele csomagokat (iptraf ehhez kevesnek tunt).
- A hozzászóláshoz be kell jelentkezni
Az ip route kimenete olyan esetben, amikor nincs szolgáltatói GW a ppp kapcsolathoz úgy néz ki nálam, hogy a MY.GA.TE.WAY = 10.64.64.64, ami a pppd log szerint is egy általa kitalált IP cím, tehát messze nem nevezhető igazi GW-nek. Azért működik véleményem szerint mégis a p2p, mert az egy olyan kapcsolat, hogy az egyik oldalon beletolsz valamit és az a másik oldalon ki fog jönni, legyen is bármi a címe. Tehát kap a csomagod egy akármilyen cél IP-t, a másik oldal ezt feldolgozza és teszi, amit kell. Címzéskor pedig a 10.64.64.64-et nem használja a rendszer p2p esetben, de ez csak az én elméletem :)
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
sok időt rászántam, és bármilyen beállítással, bármilyen iptables + fwmark és bármilyen routing alapján _mindig_ a ppp0 ADSL kapcsolaton megy ki a packet, ahogy tselmeci is leírta.
mi lehet a gond? simán gateway-nek meg lehet adni az átjáróját, és eddig ok.
de miért nem működik rendesen az fwmark ADSL esetében?
nagyon hálás lennék én is ha valaki adna választ.
köszi.
- A hozzászóláshoz be kell jelentkezni
Hogy miért, nem tudom, gondolom van valami gond az illető modulban. Amúgy működik az fwmark, csak éppen routolás után jelöli meg a csomagokat, ami annyit ér, mint halottnak a csók.
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
úgy néz ki ez a megoldás, még tesztelem...
echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter
echo 2 > /proc/sys/net/ipv4/conf/default/rp_filter
- A hozzászóláshoz be kell jelentkezni
kivancsi vagyok.
eddig egy leirasbol sem emlekszem ilyenre.
a legnagyobb leirasban van hasonlo, de ott nem 2-t, hanem 0-t iranyit bele.
Mit lehet (mit erdemes) errol a rp_filterrol tudni?
- A hozzászóláshoz be kell jelentkezni
Azt, hogy ha nem determinisztikus a routingod, vagy aszimmetrikusan mennek a packetok (más interfészen küldöd ki, mint amelyiken a válasz majd visszajön), akkor ki kell kapcsolni, ha nem akarsz szopni.
Ez egy security feature, arra való, hogy csak olyan forráscímmel engedjen be packetokat, amihez tartozó route kifele arra az interfészre mutat, amin a packet bejött. Ez egyszerű hálózatokban működik csak, ahol az 'A' interfészen kiküldött packetra a válasz nem érkezhet más interfészen vissza, mert a külvilágban nincs kapcsolat semelyik két interfészed között.
- A hozzászóláshoz be kell jelentkezni
izgalmas... Koszi a valaszt!
Es a belerakott ertekek mit jelentenek? Mert ez a 2-es ertek nem annyira egyertelmu, mint pl. a /proc/sys/net/ipv4/forward(ing?)-ba rakhato 0 es 1...
- A hozzászóláshoz be kell jelentkezni
http://www.mjmwired.net/kernel/Documentation/networking/ip-sysctl.txt
2 - Loose mode as defined in RFC3704 Loose Reverse Path
Each incoming packet's source address is also tested against the FIB and if the source address is not reachable via any interface the packet check will fail.
- A hozzászóláshoz be kell jelentkezni
+1 na ez engem is érdekel :)
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
egylőre még nem jutottam előbbre, annyi van, hogy mindkét interface-en elérhető a szerver és a jó IF-en küldi vissza a packet-et.
balance még nem jött össze sajna. viszont már nem mindig ppp felé route-ol, hanem amit a másik gw felé irányítottam azt arra, a többit a ppp felé, és a jó IF-en közlekednek a csomagok. eddig ez nem így volt.
- A hozzászóláshoz be kell jelentkezni
Ez is valami, szerdán vagy csütörtökön ránézek én is az én összeállításomra, aztán beszámolok.
--
http://www.open-st.eu
- A hozzászóláshoz be kell jelentkezni
egy kis plusz infó: még egy fontos dolog kellett nálam a PPPoE kapcsolat masquerade-hez:
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o ppp0 -j TCPMSS --clamp-mss-to-pmtu
ez azért kellett, mert az MTU érték rosszul módosult a MASQ fordítás után az ADSL kapcsolat felé.
szerk.: egyébként adott /16-os tartományokat a másik NIC felé route-olok, és így szépen meg tudom osztani a forgalmat. főleg mivel különböző a feltöltési sebesség, ezért egyelőre ez is tökéletesen megfelel.
- A hozzászóláshoz be kell jelentkezni