Dotaz: Linux GW - 2 nezavisle konektivity

Zdravim makace, dokaze linux pouzivat dve nezavisle konektivity? konektivita A (od jednoho ISP1), eth1 konektivita B (od druheho ISP2), eth2 - kazda je privedena tedy samostatne eth

- chtel bych pouzivat obe konektivity zaraz, vim,ze je zde problem s definici brany, proto se ptam, zda neexistuje nejaky workaround, kdy si linux jadro (idealne) podle vlastniho rozvazeni(napr. dle zatizeni) rozklada odchozi pakety do internetu pres jeden ci druhy interface

- procetl jsem si LARTC, ale nikde jsem na nic takoveho nenarazil, aby nedoslo k nedorozumeni nechci toto!!! http://lartc.org/lartc.html#LARTC.LOADSHARE (rozklad zateze pres 2 ci vice rozhrani, nemam totiz pod kontrolou "network2" )

- ani nechci vzit rozsah site kde je linux jako GW a "rozdelit ji" a na GW posilat jednu cast pres eth1 a druhou pres eth2, i kdyz by ten rozklad byl asi nejjednodussi diky za kazdy napad

Odpovědi

[NN]

Uz to zase vytahuju, ale je to vakh zajimave, nicmene nekdo zminoval,

ze to je L2 vec a ze to musi byt na obou stranach, cimz si ale nejsem

jisty, jinak pres iptables?

http://www.linuxfoundation.org/en/Net:Bonding

NN

[Zdenek]

ip route add default scope global nexthop via gw1 dev eth1 weight 1 nexthop via gw2 dev eth2 weight 1

[Filip Jirsák]

To bude využívat jenom jednu konektivitu, podle toho, na který řádek routovací tabulky kernel narazí dřív.

[Zdenek]

To neni pravda, jadro bude pouzivat round-robinem obe. Predtim je pochopitlne jeste nutne nastavit pomoci source policy routingu, sprave default gw pro jednotlive odchozi adresy.

[Zdenek]

Ale je to connection oriented nebude tedy prehazovat jednotlive pakety, ale jen spojeni. A diky route cache se vybere pro stejnou IP vzdy stejna cesta, dokud ta IP nevypadne z cache.

[Filip Jirsák]

To jsem nevěděl. V tom případě je do routování zataženo něco, co by tam být nemělo – routování má být úplně jedno, že je paket součástí nějakého spojení. Ale asi to usnadní konfiguraci, kterou právě tazatel požaduje. I když je otázka, zda tam nebude překážet ta keš…

[Zdenek]

Spatne jsem to napsal. Routovani nesleduje spojeni, jen si pri prvnim paketu pro konkretni IP da do cache vybranou gateway a tu pak pouziva pro vsechny pakety pro tuto IP, dokud nevyexpiruje.

[Filip Jirsák]

Takže pokud záznam v cache vyprší uprostřed TCP spojení, změní se v něm zdrojová IP adresa a spojení skončí? To je pak podle mne takováhle funkce prakticky k ničemu... Navíc by ještě zpomalovala routování -- pokud by tam žádné vyvažování nebylo, stačí seřadit routovací tabulku podle priorit a následně podle délky prefixu, a hledá se první shoda. Pokud by tam fungovalo vyvažování, musí se po nalezení shody ještě hledat, zda neodpovídá i další záznam se stejně dlouhým prefixem... Se snad nakonec opravdu budu muset do těch zdrojáků podívat.

Jinak ono i běžné vyvažování zátěže, kdy jedno TCP spojení bude mít stálou IP adresu, ale různá TCP spojení od jednoho klienta mohou mít různou zdrojovou IP adresu, bude dělat problémy s hloupými webovými aplikacemi, které změnu IP adresy klienta během jednoho sezení považují za bezpečnostní incident a klienta odhlásí.

[Zdeněk Štěpánek]

Nelze jednotlive pakety odesilat nahodne pres ruzne providery, to by vznikl pekny gulas. Lze rozhazovat pouze cele konexe. Jakmile se zacne prenaset na jednom rozhrani a jednom providerovi, uz to tam musi zustat.

Pokud se to neosetri, muzou asi nastavat pripady ze pulka vebove stranky (treba kod) pojede pres jednoho isp a jine casti (treba obrazky) pres jineho. Preji prijemnou zabavu.

Zdenek

[Filip Jirsák]

Nelze jednotlive pakety odesilat nahodne pres ruzne providery, to by vznikl pekny gulas.

Běžně to nejde, ale samozřejmě existují i případy, kdy to možné je.

Lze rozhazovat pouze cele konexe.

Jenže jádro o spojeních obecně nic neví. Možná může vědět o TCP spojení (i když routování do něj nic není), ale už třeba neví nic o DNS spojení (dotaz a odpověď), nic neví o datovém spojení vytvořeném vedle řídícího spojení FTP atd.

Pokud se to neosetri, muzou asi nastavat pripady ze pulka vebove stranky (treba kod) pojede pres jednoho isp a jine casti (treba obrazky) pres jineho

Právě proto se mi nezdá, že by jádro dělalo automatický loadbalancing. Přineslo by to víc problémů než užitku.

[hysterix]

Rekl bych, ze co se narocnosti tyce, je to plne srovnatelne s udrzovanim conntrack pri NATu. Cimz nerikam, ze to tak funguje, ale rozhodne je to realizovatelne a slo by o stejne "osklivy" zasah do jadra, jako u iptables NATu. Neslo by sice o load ballancing, protoze v pripade, ze vsichni budou chtit videt neco na jednom sigle ip serveru, tak provoz poleze ven jen jednim interfacem, ale urcity rozklad zateze by za bezneho provozu nastaval. Ale jak uz se reklo, muze (a bude) to pachat problemy u serverovych farem s vice ip adresami, coz je hlavni duvod, proc si myslim, ze to nikdo neresi.

[Filip Jirsák]

O náročnost vůbec nejde. Ale Linuxový firewall pracuje se spojením, takže udržovat v něm přehled o spojeních je přirozené - a taky k tomu má spoustu podpůrných prostředků. Routování pracuje jen na úrovni paketů, spojení by se tam musela zanést (a zbytečně tak duplikovat kód firewallu).

[Zdenek]

Ale ono opravdu dela viz CONFIG_IP_ROUTE_MULTIPATH v ipv4.route.c a ipv4/fib_*.c

[Filip Jirsák]

Nedělá, to volba je ve výchozím nastavení vypnutá. Pokud někdo má ten speciální případ, že se mu může vyvažování jednotlivých paketů hodit, může si ji zapnout. Ale není to pro běžné použití (pokud tedy nechcete klientům náhodně přerušovat spojení).

[Zdenek]

Tak pochopitelne zalezi na tom jestli je to zapnute a treba RHEL5 ji ve svych kernelech ma povolenou. O pouziti a chovani tehle funkce enni myslim mezi nami sporu

[Zdeněk Štěpánek]

Tohle je spravna odpoved, je to i v tom LARTC, jen na jiny strance. Weight urcuje pomer v jakym se budou rozhrani pouzivat 1:1 strida obe konektivity.

U kamose jsem to zkousel a vcelku to fungovalo, i kdyz cilem bylo mit zalozni ADSL.

Zdenek

[hysterix]

Mel byste asi upresnit, co myslite tim "dokaze linux pouzivat dve nezavisle konektivity?"

Jiank existuje vec zvana source based routing, kterou jsem uz 2x bez problemu pouzil pro prechod od jednoho providera k druhemu za provozu. Principem je existence dvou (a klidne i vice) ruznych routovacich tabulek podle zdrojove adresy odchazejiciho paketu.

[Filip Jirsák]

Automatické rozvážení jeden paket sem, druhý tam, udělat nemůžete -- to by pak třeba v rámci jednoho TCP/IP spojení některé pakety měly jednu odchozí IP adresy a jiné druhou, takže druhá strana by to nepovažovala za jedno spojení. Leda, že byste neměnil zdrojovou IP adresu -- to byste ale jednak používal obě spojení jen pro upload (což asi nechcete), jednak by rozumný ISP ty pakety zahazoval. Pokud tedy nemáte blok IP adres routovatelný přes oba ISP, ale to asi těžko -- pokud ano, pak v rozpočtu určitě najdete dost peněz na to zaplatit zkušené správce, kteří vám takovou síť budou administrovat

Takže zbývá rozdělování paketů podle nějakých pravidel, a to už se tu řešilo několikrát -- třeba zde.

[linuxnew]

A proc by to nemohlo fungovat jako napr. "stavovy" firewall, pri navazovani noveho spojeni /respektive by si to pamatovalo, tahle IP z LAN chce otevrit SYN s najakou masin v Inetu, rozhodnu podle kriterie vytizeni (pripadne dalsich veci) pres jakou GW to pujde, po uzavreni spojeni by vypadnul radek o stavu, takze by to cela mohlo probehnout znovu. S UDP je to trochu slozitejsi, neni zde zadny handshake apod., presto TCP spojeni vedou.

A nebo to vubec nejde a bude se to muset resit ruleset na zaklade source routovani.

[Filip Jirsák]

Se zapamatováním spojení by to fungovat mohlo, ale neexistuje pro to žádné hotové řešení – pravidla se mohou uplatňovat podle značek z iptables, iptables mají větší možnosti rozlišování paketů a můžete pakety k rozlišení předávat i externímu programu. Takže možnosti, jak to udělat, existují…

[pavel]

Rozhazovani paketu jeden sem, druhy tam, to delat nelze. Cilovy stroj vidi dve ruzne IP a tim to povazuje za dve odlisne spojeni. Existuji ruzne metody low balancingu, ktere lze vyuzit napriklad i k rozlozeni zateze mezi ruzne vetve fyz. serveru (rizene napr. DNSem), ale vzdy je to spojeni jedna IP proti druhe IP a ne ze je jedna z tech IP promennych. Rozlozeni zateze tak jak chcete je nutno nadefinovat. napr. viz odkaz na diskuzi vyse. Vase otazka, zda linux dokaze pouzivat ruzne konektivity, tak ano, dokaze. Vytvareni failoveru (ipmp) atd...

[Sejki]

Mas na mysli neco jako dual wan router? http://www.alwar.cz/e-shop/vmchk/smc-dual-wan-load-balancing-vpn-router.html

[Sejki]

nebo ti treba pomuze toto http://www.linuxquestions.org/questions/linux-networking-3/useful-dual-wan-script-574424/

[sheery]

Není to vpodstatě totéž co se řešilo na

http://www.root.cz/diskuse/3855/

a případně i dalších diskuzích na rootu (s některými možnými odpověďmi tam?