Dotaz: redundance pripojeni k Internetu

[Stanislav Kostka]

Ahoj, resim nasledujici problem - mam linux router se dvema NIC, dve pripojeni k dvema ruznym ISP a potrebuju zridit failover tak, aby pri vypadku jednoho pripojeni se automaticky pouzilo to druhe. A naopak - pokud primarni ISP opet "naskoci", tak aby se provedl "failback" - prepnuti na primarni ISP. Muzete me navest? Diky za jakoukoli radu, S.K.

---

---

Odpovědi

[skunerq]

script, ktery pinga na default gateway primarniho ISP, v pripade nedostupnosti prepise routovaci tabulku, resp. DGW pro vasi sit a zaroven ceka na najeti primarniho providera, aby to vratil zpet. Je ale potreba osetrit flapovani primarniho ISP, aby to neprepinal co minutu ... Hledejte dual WAN script pro linucha, nebo si rovnou kupte primo dual WAN router.

[dopisovatel]

treba do cronu neco takoveho, pro nahozeni tmobile jako backupu :

#!/usr/bin/perl

use Net::Ping;

system "killall pppd";

system "ip route del dev eth0 default";

system "ip route add dev eth0 default via xx.xx.xx.xx";

system "cp ./resolv.conf.orig /etc/resolv.conf";

my $p = Net::Ping->new("icmp");

my $host="8.8.8.8";

unless ($p->ping($host)) {

system "killall pppd";

system "ip route del dev eth0 default";

system "pppd call tmobile4g";

}

[Stanislav Kostka]

Diky za tip! Trochu jsem googlil a nasel par clanku o bondingu. Neresilo by to presne muj problem? Mate s tim nejake zkusenosti?

[MMichal]

To urcite ne. Bonding je failover na linkove vrstve. Tzn. dva (ci vice) kabely vedou do jednoho switche (fyzickeho ci virtualniho pres vice fyzickych).

[Filip Jirsák]

Já bych tedy default routy nemazal, nechal bych je tam obě a jenom bych jim měnil váhu. Připadá mi to čistší řešení – a třeba když omylem z jedné síťovky vytrhnete kabel, bude se automaticky routovat přes druhou a nemusíte čekat na to, až neprojde ping.

[já]

Kernel volí cestu podle nastavené váhy. Ale když zvolí tu nefunkční, musí se spojení "vytimeoutovat", aby kernel poznal, že tudy cesta nevede.

[Filip Jirsák]

Opravdu bude kernel volit cestu i přes neaktivní zařízení?

[já]

Co když máte oba providery přes jeden interface? Nebo gateway funguje a něco nefunguje až za ní?

[Filip Jirsák]

Tazatel psal, že má dvě rozhraní. A já jsem psal, že to vyřeší případ, kdy se dané zařízení deaktivuje (např. vytáhnete ethernetový kabel). To jádro může poznat a zareagovat na to hned. Jinak si samozřejmě musí tazatel nadefinovat, co pro něj znamená „výpadek připojení“, a to pak testovat. Jádro samozřejmě nemůže vědět, co si kdo pod tím představuje.

[já]

Situací na úrovni "např. vytáhnete ethernetový kabel" v běžném provozu asi nebude moc.

[Jirka]

Tak trochu off-topic, ale neodolal jsem.

[pavlix]

Situací na úrovni "např. vytáhnete ethernetový kabel" v běžném provozu asi nebude moc.

To byses divil.

Jinak výjimečně se mi Jirsákovo řešení líbí, řešit failover jen váhou mi přijde jako dobrý nápad.

[dustin]

Obdobný požadavek už řešíme s mírným úspěchem delší dobu. Máme to ještě mírně komplikovanější, že chceme, aby obě rozhraní chodily současně pro příchozí provoz (jsou to např. MX záznamy v doméně, vedle dalšího backupu), takže přes ně zvenku funguje i smtp, ssh, vpnka apod. Rovněž lze vyčlenit určitý provoz, aby šel přes záložní, když už se platí a existuje (např. odchozí SMTP, když se hlavní linka dostala do blacklistovaného bloku UPC a to to samozřejmě nijak neřešilo). Tyto požadavky nakonec vyvstanou vždycky, málokdo nechá záložní linku ladem.

Řešíme to tak, že se v cronu každou minutu testuje pingem dostupnost nějaké IP adresy v síti primárního providera, přičemž má ping omezené TTL paketů, aby to ze sekundární linky nezafungovalo. Když to vyhnije (u UPC docela časté), přepne se defaultní routovací tabulka na backup linku. A když se spojení obnoví, zase se to přepne zpátky. Ale pomocné routovací tabulky s nižší prioritou napojené na obě rozhraní žijí pořád, to umožňuje příchozí provoz i na sekundárním rozhraní.

Při přepnutí se maže conntrack tabulka, restartuje vpnka atd.

Samozřejmě s tím musí počítat i firewall, vpnky, SPF záznaky v doménách atd.

Problém je, když ta linka pinguje, ale hodně slabě, pak se to nepřehodí. Nebo když to vyhnije až za tou testovací IP adresou, ale k tomu u UPC moc nedochází, tak to obvykle umře hned za modemem.

[linuxik]

Jak uz tady uz nekdo navrhnul, necha se pouzit bonding, Staci nastavit arp_ip_target a jako parametry IP adresy provideru.

[Filip Jirsák]

Bonding je něco jiného. Funguje na nižší vrstvě, musí ho podporovat druhá strana a funguje jako posílení kapacity jednoho spoje – typicky máte switch a z něj dvě linky do jednoho počítače. Z pohledu sítě se pak obě síťové karty tváří jako jedna, a počítač může odesílat skrze obě karty, stejně tak switch využívá obě dvě.

To, co chce tazatel, funguje až na IP vrstvě – odesílatel někde v internetu si nezvolí, přes kterého providera paket pošle, ale je to jasně dané už cílovou IP adresou. U paketů z vnitřní sítě zase musí souhlasit odchozí IP adresa s tím, přes kterého providera paket odchází, protože ISP se nemusí líbit, že by z jeho sítě odcházely pakety, které do ní vůbec nepatří.

[linuxik]

Tak uplne pravda to neni, v rezimu active-backup je aktivni vzdy pouze jedna sitova karta. Podpora na strane switche je potreba pouze v pripade pouziti modu 4 (802.3ad). Dostupnost site se zjistuje arpingen na sitovku providera a problem s IP adresou odchozich spojeni resi NAT nebo maskarada. Takze jediny pripad kdy to takhle nefunguje, je v pripade kdy je sice dostupna GW providera, ale problem je az za ni.

ps. Souhlasim, ze bonding je urceny k necemu jinemu, ale funguje to.

[pavlix]

funguje to.

To bych chtěl docela vidět. Jak zajišťuješ, aby NAT natoval správnou adresou (tedy pro každého poskytovatele jinou?

[Filip Jirsák]

To, co popisujete vy, je normální propojení více sítí. Bonding znamená, že máte dvě zařízení, která by normálně byla propojena jedním spojem, vy je ale místo toho propojíte dvěma (nebo více) spoji. Tazatel má ale celkem tři zařízení – router a brány dvou ISP. Bonding by mohl udělat jedině tak, že by měl další router někde v internetu, a vytvořil by dva (virtuální) spoje mezi těma dvěma routery (tím ve vnitřní síti a tím venku) – třeba pomocí dvou tunelů, přes každého ISP jeden. Veškerá komunikace s internetem by pak šla přes ten venkovní router. Taková konfigurace se používá, pokud chcete mít tu vnitřní síť dostupnou nezávisle na ISP – vaše IP adresy jsou pak routované na ten venkovní router, a ten komunikaci pošle do vnitřní sítě tím tunelem, který zrovna funguje a je méně vytížený.

Ale aby to fungovalo, musíte mít pořád správně nastavené to routování přes oba ISP, a teprve přes to pak můžete natáhnout ty tunely.

[skunerq]

ono muze fungovat kde co, ale jedinym plne funkcnim reseni je BGP a vlatni AS. Eliminuje to problemy s DNS zaznamy, balancingem provozu, redundanci na vsech vrstvach ......

[slack13_1]

Jasan hned tazatel pobezi za poskytovatelem ci poskytovateli a nakaze mu (jim) pouzivat BGP.

reseni byla zminena pomoci scriptu resit dostupnost. nasledne menit vahu bran nebo jiny zpusob. Moznosti je spousta, staci se zeptat strycka googla.

[skunerq]

seriozni ISP s tim nema nejmensi problem, financne to take neni narocne, a hlavne to vyresi spoustu problemu, viz NATy, DNS .... ano, najdeme si cestu jak to docasne ochcat, v budoucnu se nam to ale vrati. jo a provider, ktery nema AS neni provider

[pavlix]

seriozni ISP s tim nema nejmensi problem, financne to take neni narocne, a hlavne to vyresi spoustu problemu, viz NATy, DNS .... ano, najdeme si cestu jak to docasne ochcat, v budoucnu se nam to ale vrati. jo a provider, ktery nema AS neni provider

A že takových providerů je :). Jsem k jednomu připojený a naprostá spokojenost.

[pavlix]

ono muze fungovat kde co, ale jedinym plne funkcnim reseni je BGP a vlatni AS. Eliminuje to problemy s DNS zaznamy, balancingem provozu, redundanci na vsech vrstvach ......

Tak to je samozřejmě ideální případ a doufám, že se k němu bude konvergovat už kvůli IPv6.