- This topic has 13 hozzászólás, 6 résztvevő, and was last updated 14 years, 2 months telt el by
.
-
Bejegyzés
-
Helló !
Komoly dilemmával küzdök.
Már meglévő, kiválóan működő rendszer mellé/elé kellene valamit kitalálnom arra a feladatra , hogy a webes forgalmat két router között , a kliensektől jövő hívott oldal címe! és/vagy a portok alapján irányítsam, az egyik, illetve a másik routerre. (Statikus, folyamatos terhelés megosztása érdekében).Az egyik router már „proxys” , a másik még nem.A meglévő két szervert már nem nagyon piszkálnám…
Szóval jelenleg elég erős fejvakarás van.— Tegyek be eléjük még egyet ????……… vagy mi …?
Köszönöm előre is ha valaki tud okosat !
CISCO-éknál minden bizonnyal tudnak javasolni kulcsrakész megoldást, amit a helyszínre kiérkezett szakértő nem kevés óradíjért pár hét alatt elég használhatóra meghegeszt nektek.
akkor legalább egy sematikus ábra kellene, de a megoldást biztos, hogy valamilyen proxy fogja hozni majd…
Az alap felállás.
Kvázi homogén hálózat két ISP-vel, amiből az egyik már proxyn keresztűl, bérelt vonalon üzemel.
Arra lenne szükségem, hogy a hálózaton lévő forgalmat portok és ami bonyolultabbá teszi a dolgot, URL-ek alapján irányítani tudjam a két ISP között.
Konkrétan a kliens bizonyos URL-jei szabályok szeint az egyik ISP-hez kerüljenek a bérelt vonalra, míg a többi internet forgalom , pedig a másik ISP-hez.
Én úgy vélem, hogy az alap dolgokon már túl vagyok, mégsem tudok rá jobb megoldást , mint egy CISCO-t.
Ám, csak egy linuxos megoldást szeretnék keresztül hajtani.Mivel a probléma felvetésének módja erős fejfájást okoz, előre is elnézést kérek a válasz miatt.
Nem kívánok a Cisco nevében beszélni, de közel lehetetlen amit szeretnél (mivel megoldásokat szállítanak ők is és nem vágyakat elégítenek ki). Ugyanis a kívánt layer4 (vagy layer7 – szemlélet és implementáció kérdése) routing nem nagyon valósítható meg, ha a
– „A meglévő két szervert már nem nagyon piszkálnám…”
– „Az egyik router már proxys”
– „a kliensektől jövő hívott oldal címe! és/vagy a portok alapján irányítsam”
feltételek bármelyikét meg kívánod tartani. (A második azért problémás, mert a proxy nem egy szoftver neve, hanem egy szolgáltatás. Ráadásul két proxy szoftver ritkán tudja ugyanazt ugyanúgy.)Az _amit_ szeretnél megoldható, de _ahogy_ szeretnéd hogy megvalósuljon az már agyament dolog. Ha a két „router” egy-egy PC, akkor három proxy segítségével megoldható a következő módon:
– a két router-en levő proxy csak a harmadik proxytól fogad kapcsolatot, ajánlott proxy: squid (a cache hasznos lehet, de csak opció),
– a harmadik proxy egy HA-Proxy, ahol meg van adva a következő három (és a többi) konfig opció:
balance roundrobin
server s1
server s2
– a klienseknél a default gateway (windows: átjáró) a harmadik proxy IP címe
– a harmadik proxy mehet akár az egyik router-en is, ha a squid nem az alapértelmezett portokat portot használja (pl. 8080 és 8443)
– külön-külön kell megadni a 80-as és a 443-as portokra vonatkozó szabályokat.Így a hálózati késleltetés (latency) megnő és csak a HTTP forgalom kerül továbbításra, de a kliensek számára transzparens, és közel optimális a sávszélesség kihasználtság több aktív kliens esetén (az URL és port mágiához hasonlítva).
Hogy miért kell három proxy? Mert a HA-Proxy nem ismer egyetlen egy gateway protokollt sem, csak IP-re továbbít. Ha ilyesmi kell, akkor az már hardveresen megy és nem két forint. Például BGP/CEF/RIP alapú megolgások. Régen a Linux Virtual Server (KTCPVS) is tudott valami hasonlót,.de már nem fejlesztik.
http://www.squid-cache.org/
http://haproxy.1wt.eu/
http://kb.linuxvirtualserver.org/wiki/KTCPVSKöszönöm a választ.
– „A meglévő két szervert már nem nagyon piszkálnám…”- akár piszkálhatjuk is, de nekem egyszerűbbnek tünt egy külön, harmadik gépet beállítani. az a baj, hogy a Squiddet nem bírom rávenni a mutatványra.
– „Az egyik router már proxys”- ez sajnos adott.A bérelt vonalon lévő ISP kapcsolatspecifikus.
– „a kliensektől jövő hívott oldal címe! és/vagy a portok alapján irányítsam”- Vannak olyan címek, amiknek mindenképpen a bérelt vonalra kell kimennie, mert a hívott oldal zárt rendszerben van, ami csakis ezen keresztül érhető el.Sima UPC-s, T-online-s stb vonalról nem.A vél , végül is az, hogy azokat a hívásokat amikhez nem szükséges a bérelt vonal, azt kiterheljük a T-online DSL-jére.
Azért nagyon örülök , hogy valaki végre kezdi megérteni a problémát.
jonnlenin wrote:– „A meglévő két szervert már nem nagyon piszkálnám…”- akár piszkálhatjuk is, de nekem egyszerűbbnek tünt egy külön, harmadik gépet beállítani. az a baj, hogy a Squiddet nem bírom rávenni a mutatványra.Szerintem olvasd át amiket írtam, mert néhány dolgot nagyon összekeversz. A Squid nem azért van, hogy a terhelést kiegyenlítse, nem erre való (mivel „csak” egy általános és robosztus proxy, viszont jól dokumentált). Ráadásul nem véletlenül kizárólag proxykról beszéltem és nem gépekről/szerverekről. Akár egy gépen is futhatnak megfelelő védelem mellett. Sőt, akár egy web proxy is elég lenne kettő helyett a megfelelő beállításokkal, de ez eléggé specifikus . A javaslatom egy terheléselosztó (load balancer) proxy és két web/anonymous/transparent proxyból áll. Ez utóbbi feladata hogy a HTTP HOST mezőben levő címet – újból – feloldja és oda továbbítsa a tartalmat. Nem a HAProxy az egyetlen ami képes megfelelően szétosztani a forgalmat, de messze ez a legáltalánosabban használt célszoftver.
jonnlenin wrote:– „Az egyik router már proxys”- ez sajnos adott.A bérelt vonalon lévő ISP kapcsolatspecifikus.Itt is súlyos tévedés lehet, vagy kevered a proxy és a vhost funkciókat, vagy egy hardveres (specifikus) VPN proxyt nézel általános szoftveres proxynak. Ugyanis most a proxy címére érkező HTTP forgalmat kell újból továbbítani (és kezelni) a fejléc újraértelmezésével. Ezt a funkciót tiltani vagy korlátozni szokták biztonsági okokból, ezért kell itt is korlátozni a bejövő kapcsolatokat a harmadik proxyra (hogy ne legyen átjáróház rossz emberek számára). Nem kizárt, hogy mégis támogatja a rounter/proxy-d a fentieket, ekkor én tévedtem nagyot (az általad megadott infóból nem lehet kihámozni ide vonatkozó dolgokat). Minderre nem lenne szükség, aha a harmadik proxy képes lenne gateway protokoll támogatására. A router típusának ismeretében lehetne fizetős szoftvereket találni, de ha nem vagy a forgalom akkor olcsóbb a plusz PC vásárlása.
jonnlenin wrote:– „a kliensektől jövő hívott oldal címe! és/vagy a portok alapján irányítsam”- Vannak olyan címek, amiknek mindenképpen a bérelt vonalra kell kimennie, mert a hívott oldal zárt rendszerben van, ami csakis ezen keresztül érhető el.Sima UPC-s, T-online-s stb vonalról nem.A vél , végül is az, hogy azokat a hívásokat amikhez nem szükséges a bérelt vonal, azt kiterheljük a T-online DSL-jére.
A HAProxy képes egyedi továbbításra is (lásd ACL rész). De ha csak annyi kell, hogy a megadott címek menjenek a bérelt vonal felé, a többi meg az ADSL felé, akkor nincs szükség proxyra. Kézzel feloldod a domain neveket, az IP-k alapján egy linux gateway (iptables) meg szortírozza. Bár ehhez is át kell alakítani egy kicsit a hálózat elrendezését. Vagy csak a routereknél kell beírni a megfelelő tiltásokat az IP-k alapján. Ha meg szükségtelen a terheléselosztás de nem stabilak az IP címek a DNS-ben, akkor elég önmagában a HAProxy. Ha meg (…), akkor (…).
jonnlenin wrote:Azért nagyon örülök , hogy valaki végre kezdi megérteni a problémát.Inkább a „torpedó” nevű játék fórumos adaptációja zajlik. 🙂 Ez is egy olyan tipikus feladat, ahol nagyon sok megoldás létezik, de hogy melyik a célszerűbb és optimálisabb az a részletektől függ.
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz