Sziasztok,
egy centos 5.4-en pppd-vel kapcsolódtam egy pptp vpn szerverre (ppp0 interface), és php-vel (curl) le szeretnék tölteni fileokat 2 párhuzamos szálon; az egyik processzen az eth0-n keresztül, a másikon a ppp0-n keresztül (az oldal ip-nként csak 1 letöltést enged). A kérdésem az lenne, hogyan lehet a default gatewayt / default devicet processzenként beállítani?
Kösz és BÚÉK,
KóBi
- 1296 megtekintés
Hozzászólások
iptables -t mangle -A OUTPUT -m owner --uid-owner user1 -j MARK --set-mark 100
iptables -t mangle -A OUTPUT -m owner --uid-owner user2 -j MARK --set-mark 200
ip rule add fwmark 100 table 100
ip rule add fwmark 200 table 200
ip route add default via gw1 dev eth0 table 100
ip route add default via gw2 dev ppp0 table 200
- A hozzászóláshoz be kell jelentkezni
Szia Josephus,
kösz a segítséged! Ha jól értem, akkor az iptables-ben per user routingot állítasz be, de ez azt jelentené, hogy minden threadnek külön usert kell felvennem, illetve a rendszerbe be kell "égetnem" a userenkénti routingot. Valódi per process routingot nem lehet megvalósítani linuxban? Ha nem, akkor nem adódnak problémáim majd a dns-el a ppp0-ra routolt userrel?
Kösz mégegyszer,
KóBi
"Turpis et diabolica >>hui, hui<< frequenter auditur."
- A hozzászóláshoz be kell jelentkezni
eth0-n keresztül, a másikon a ppp0-n keresztül
rendszerszinten ez ugy megy, hogy - felteve hogy tcp-felett toltesz le, pl http-n keresztul - hogy a connect() elott egy egyebkent opcionalis bind() hozzakoti a scoket-et egy adott iface-hoz (amit az /sbin/ifconfig altal kiirt ip-szam reprezental, mint egyertelmu megfeleltetes) igy a csomagok kuldozgetesekor mivel a kernel tudja hogy melyik ip-hez melyik iface tartozik, ezeert ott fog kimenni. Neked itt erre van szukseged, ha jol latom. A kedvenc "szeretnék tölteni" programodnak kell megmondani, hogy milyen un. source address-t hasznaljon. Ezt vagy tudja, vagy nem, mindensetre lowlevel programok (
netcat,
socket,
wget) tudnak ilyeneket (rendre a -s, -B es --bind-address opcio), de ha mondjuk torrenteznel, es a konzolos
btdownloadcurses-t hasznalod, az is tudja (--bind opcio).
Egyebkent udp felett is lehet ilyen bind-inget csinalni, megy, mukodik, hasznaltam, igaz azt csak programozoi szinten (lasd feljebb).
- A hozzászóláshoz be kell jelentkezni
Sziasztok!
Köszönöm szépen mindannyitok segítségét, de szerintem a userek szétroutolása lesz a megoldás.
Az alapvető probléma, hogy egy oneclick hostertől szeretnék fájlokat letölteni (nem a pénzt sajnálom rá, a technikai megoldás érdekelt).
A rendszer amit összeraktam, úgy néz ki, hogy hozzáféréssel rendelkezem egy internetre nyitott pptp hálózathoz (egy C osztályt oszt ki a gateway, minden kiosztott cím publikus), és azt volt az ötletem, hogy építek egy gépet, ami mondjuk 4x csatlakozik a gatewayre, és 4 usert külön "vonalon" (interfacen) routol. Minden user futtat egy daemont, ami egy webservicetől ovassa be, hogy milyen fájlt töltsön le (a webservice meg kezeli, hogy milyen user/ip párosnak osztott ki melyik fájlt, hol tart a letöltés, hány szabad letöltő daemon van, stb.). A daemon megteszi a szükséges lépéseket (azért nem tudok hozzá wget-et használni, mert post-olni kell és sessionönként gondoskodni kell a cookie-król, ezért sokkal kényelmesebb a php/cURL megoldás). Miután lejött a fájl egy közös helyre scp-zik (közös userrel).
Igazából a rendszer nagyjából jól működik, egy gonddal küzködök még: az a gép, amelyik osztja a daemonok közt a webcímeket, kb. 1-2 naponta lángok és kernel errorok közt adja meg magát. A gép nem válaszol semmire (http/ssh), a system log tele van oom-killer üzenettel. Arra gyanakszom, hogy a percenkénti párhuzamos lekérdezések miatt (minden lekérdezés egy olvasás a teljes táblán utána, ha kioszt a webszolgáltatás egy fájlt, akkor végrehajt egy update parancsot) lockolási probléma lépett fel, de szerintem bármilyen sql-t felhasználó weboldalt is írok, hacsak nem direkt olyan kódot írok, ami a rendszernek árt, nem kellene, hogy megboruljon az OS.
Szerintetek mitől lehet ez a jelenség?
Kösz mégegyszer,
K
"Turpis et diabolica >>hui, hui<< frequenter auditur."
- A hozzászóláshoz be kell jelentkezni