Dotaz: Vícenásobné připojení serveru k internetu

[Petr Zajíc]

Dal by se využít linuxový stroj tak, aby na něm byly 2 připojení k internetu současně (např. ADSL+WIFI)? Tzn. že by stanice využívající tento server pro připojení k internetu mohly být připojeny rychlostí rovnající se součtu rychlostí obou spojů?

Odpovědi

[Majki]

muzes pouzit bonding (bond interface - modul v jadru) eql - taky v jadru (podobny bondingu) teql - reseni pres packet scheduler http://lartc.org/howto/ (vsechno je v jadru jako modul:) a v kazdem pripade hledej "load balancing" ani jeden z techto pripadu Ti nezarucuje to, ze kdyz jedna linka spadne, tak to bude bezet vsechno jenom po jedne lince..to bys musel resit multipath routingom a podobne a to by uz musel nastatovat taky veci provider na svoji strane, takze na to muzes zapomenout..musis se spolehnout na to, ze obe2 linky budu porad funkcni Resp. jeste mne napada, udelat to multipath statickym routingom a napr. fpingom nebo nejakym zpusobem kontrolovat druhou stranu a kdyz nebude odpovidat, tak zhodit prislusnout default routu (normalni routa smerem na host zustane, takze host muzes kontrolovat) a kdyz znovu odpovi tak default routu pak zasa nahodit...vcase kdyz ta jedna routa bude down, tak vsechno bude bezet jenom po te druhe default route. Chce to jeste par veci osetrit..ale s tim se uz musis pohrat sam..

[Tomáš Hála]

Bonding je podle mne v tomto pripade vyloucen. Jestli dobre chapu, jak funguje, tak slouci dve fyzicka zarizeni do jednoho virtualniho a tomu se pak prideli jedna adresa. Ale kdyz se pripojuji na net pres ADSL a WiFi, tak jedu pres dva providery a dostanu dve ruzne adresy. No a TEQL zase vyzaduje podporu na obou stranach spojeni (tedy i u provideru), takze to take tento pripad neresi. Dve pripojeni od ruznych provideru se daji pouzit podle me jen na rozlozeni zateze mezi nekolik klientu pomoci sikovne nastaveneho routovani. Ale tezko budu stahovat rychlosti souctu obou konektivit. (Leda bych navazal dve samostatna spojeni a stahoval soubor po castech.)

[Majki]

mas pravdu..kdyz jsem to psal moc jsem nepremyslel..

[Beda]

napada me takove polovicate reseni. odolne z pohledu novych konexi a nesetrne ke stavajicim v dobe vypadku. vytvorit nejaky dalsi virtualni sitovy zarizeni, ktery je schopny pustit provoz dal (nejaky napad?). spojit to routovanim do V-ecka kde dole je to virtualni a na koncich jsou fyzicky. na tech fyzickych mit SNAT a DNAT v pomeru 1:1 (jak ip, tak porty - takze se vlastne vykaslat na iptables a udelat to pomoci dumb_nat "ip route help", "ip rule help" budou asi dva nejuzitecnejsi prikazy. este s linkem na www.lartc.org ) default lokalni ip adresu dat rovnu adrese virtualniho zarizeni pro pripad, kdy je v connect/bind neuvedena. (sysctl?) nastavit pro odchozi nejaky druh loadbalancovani(nikdy jsem to nestudoval. nejaky napad?), ktery smeruje tcp a spojovane sluzby skrze tu samou ip (a spolihat se na to, ze se udp sluzby nezblazni, nebo ze pro nejakou kombinaci s-ip:s-port:d-ip:d-port se to bude snazit smerovat na stejny fyzicky rozhranni) takoveto loadbalancovani bude mit v nekterych situacich dost daleko k optimalnimu reseni, kdy obe linky jsou plne, pokud je dost dat, ale lepsi nez nic. v dnsku uvadet pro kazde jmeno ktere chcete tou masinou obsluhovat dva A zaznamy a nechat dns servery(bind - defaultni chovani - nahodna zmena poradi), at provadi nahodny nebo cyklicky reordering zaznamu. (vsadil bych se, ze mozna i takovoudle prasecinku budou ip6 adresy a smerovani resit lip) vyhnete se tak nic neresicim recem s ISP (i kdyz treba mate zrovna stesti na kvalitniho a nadseneho poskytovatele za primerenou cenu (wifi a adsl tipuji domaci reseni)