abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 02:20 | Zajímavý článek

David Revoy, autor open source webového komiksu Pepper&Carrot nebo portrétu GNU/Linuxu, upozorňuje na svém blogu, že nový Inkscape 0.92 rozbíjí dokumenty vytvořené v předchozích verzích Inkscape. Problém by měl být vyřešen v Inkscape 0.92.2 [reddit].

Ladislav Hagara | Komentářů: 0
včera 02:02 | Komunita

Øyvind Kolås, hlavní vývojář grafických knihoven GEGL a babl, které využívá grafický program GIMP, žádá o podporu na Patreonu. Díky ní bude moci pracovat na vývoji na plný úvazek. Milník 1000 $, který by stačil na holé přežití, se již téměř podařilo vybrat, dalším cílem je dosažení 2500 $, které mu umožní běžně fungovat ve společnosti.

xkomczax | Komentářů: 12
21.1. 23:54 | Pozvánky

DevConf.cz 2017, již devátý ročník jedné z největších akcí zaměřených na Linux a open source ve střední Evropě, proběhne od pátku 27. ledna do neděle 29. ledna v prostorách Fakulty informačních technologií Vysokého učení technického v Brně. Na programu je celá řada zajímavých přednášek a workshopů. Letos je povinná registrace.

Ladislav Hagara | Komentářů: 0
21.1. 22:11 | Nová verze

Byla vydána verze 1.0.0 emulátoru terminálu Terminology postaveného nad EFL (Enlightenment Foundation Libraries). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
20.1. 17:00 | Nová verze

Byl vydán Docker 1.13. Přehled novinek na YouTube a v poznámkách k vydání na GitHubu. Docker umožňuje běh aplikací v softwarových kontejnerech (Wikipedia).

Ladislav Hagara | Komentářů: 5
20.1. 15:51 | Komunita

Mozilla.cz informuje, že nástroje pro webové vývojáře se možná oddělí od Firefoxu a stanou doplňkem. Nástroje pro webové vývojáře prošly velkým přepisem a tým, který se stará o jejich vývoj, by uvítal možnost jejich častějších aktualizacích nezávisle na vydávání nových verzí Firefoxu.

Ladislav Hagara | Komentářů: 10
20.1. 07:00 | Humor

Čtenářům AbcLinuxu vše nejlepší k dnešnímu Dni zvýšení povědomí o tučňácích (Penguin Awareness Day).

Ladislav Hagara | Komentářů: 0
20.1. 06:00 | Komunita

Bylo spuštěno hlasování o přednáškách a workshopech pro letošní InstallFest, jenž proběhne o víkendu 4. a 5. března v Praze. Současně byla oznámena změna místa. InstallFest se letos vrací zpět na Karlovo náměstí do budovy E.

Ladislav Hagara | Komentářů: 0
20.1. 02:48 | Komunita

Greg Kroah-Hartman potvrdil, že Linux 4.9 je jádrem s prodlouženou upstream podporou (LTS, Long Term Support). Podpora je plánována do ledna 2019. Aktuální jádra s prodlouženou podporou jsou tedy 3.2, 3.4, 3.10, 3.12, 3.16, 3.18, 4.1, 4.4 a 4.9.

Ladislav Hagara | Komentářů: 0
20.1. 00:11 | Zajímavý článek

Výrobce síťových prvků, společnost Netgear, spustila nový program, který slibuje vývojářům, expertům, ale i běžným uživatelům vyplacení finanční odměny za nalezení bezpečnostních chyby v jejich produktech. Za nalezení zranitelnosti v hardware, API nebo mobilní aplikaci nabízí odměnu od 150 do 15 tisíc dolarů (dle závažnosti).

Michal Makovec | Komentářů: 0
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (10%)
 (2%)
 (74%)
 (4%)
 (10%)
Celkem 367 hlasů
 Komentářů: 25, poslední 21.1. 13:34
Rozcestník
Reklama

Dotaz: Multihoming s policy routingom a DNATom

22.9.2011 00:17 timeos | skóre: 32
Multihoming s policy routingom a DNATom
Přečteno: 355×
Zdravim vospolok, riesim nasledujuci problem pre nasledovnu situaciu:
                                                                 ________
                                          +------------+        /
                                          |            |       |
                            +-------------+ Provider 1 +-------
        __                  |             |            |     /
    ___/  \_         +------+-------+     +------------+    |
  _/        \__      |     if1      |                      /
 /             \     |              |                      |
| Local network -----+ Linux router |                      |     Internet
 \_           __/    |              |                      |
   \__     __/       |     if2      |                      \
      \___/          +------+-------+     +------------+    |
                            |             |            |     \
                            +-------------+ Provider 2 +-------
                                          |            |       |
                                          +------------+        \________

Linux router je klasicky nastaveny na multihoming (s pouzitim viacerych smerovacich tabuliek pre jednotlivych providerov, pravidiel "ip rule", a iptables Maskarady pre oba rozhrania (if1 a if2) v pripade spojeni inicializovanych z vnutra lokalnej siete)... toto chodi bezproblemovo.

V lokalnej sieti (privatny IP rozsah) sa nachadza sluzba (nad protokolom TCP), ktora ma byt dostupna zvonka cez Providera 2 na IP adrese rozhrania if2 Linux routra a na definovanom porte.

To znamena, ze bolo potrebne do iptables pravidiel pridat DNAT pravidlo (aj s prislusnym FWD pravidlom pre filter tabulku), pre prichadzajuce TCP spojenia na IP adresu rozhrania if2 a konkretny tcp port.

Na linux routri je predvolena brana v main tabulke nastavena cez providera 1.

V com je problem? Packet prichadzajuci na DNATovanu sluzbu zvonka dorazi na router, spravne je DNATovany a forwardnuty na lokalny server s verejnou sluzbou. Avsak odpoved z tejto sluzby (odpovedny TCP segment) je naspat cez smerovac forwardnuty sice so spravnou prelozenou adresou (IP adresa rozhrania if2) ale preposlany von rozhranim if1 miesto if2!!

Je mi jasne, ze v uvedenom scenari zafungovala predvolena brana na providera 1 z primarnej smerovacej tabulky... otazka je vsak, ci je to bug alebo feature? Da sa nejak zapnut kontrola odpovedajucich paketov so spojeni prichadzajucich zvonka v pripade multihomed linux servera? Myslel som, ze taketo spojenia su nejak trackovane a system vie urcit spravny odchadzajuci interfejs smerom do internetu.

Ano.. workaround existuje... staci na routri markovat pakety posielane z lokalneho servera a tym ich posielat spravne cez providera 2... ale toto nie je uz dynamicke, ale staticke rozhodovanie o odpovedajucej cesty naspat pre dany IP packet na zaklade mnou napisaneho pravidla...


Řešení dotazu:


Odpovědi

22.9.2011 11:14 NN
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Od jader 2.6 a vise nefunguje 'ip route nat', ktery umoznuje na zaklade zdrojove ip adresy smerovat provoz pres konkretniho providera ven a to tak ze se na server pro kazdeho providera povesi jina adresa a podle ni se vybira rozhrani.

Nicmene podle navodu na LARTC a pouziti tzv. "split access" se trafic rozdeli do dvou siti pro kazde vnejsi rozhrani. To vypada jako reseni tveho problemu, ale doporucuji precit cele az do konce..

Zdroje:

http://linux-ip.net/html/adv-multi-internet.html

http://lartc.org/lartc.html#AEN268

NN
22.9.2011 11:28 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

Prave takto to mam nastavene teraz... ok, aby som bol presny, pre terajsiu situaciu pouzivam split access (popisovany v uvedenej kapitole z druheho vasho linku)... dokonca aj ten obrazok pre tuto otazku som bral odtial. Vysledok? Ten ktory popisujem v otazke.. smerom spat sa pakety smeruju cez main tabulku... nie je tam ziadna kontrola toho, ci packet povodne naozaj prisiel providerom 1 alebo nie.

Predstavoval som si funkcnost na principe, ze napr. do hlavnej smerovacej tabulky sa prida docasny host record s informaciou o tom, ktora brana (provider) sa ma pre dany IP packet cestou spat pouzit resp. podobne riesenie na zaklade internych tabuliek.

22.9.2011 11:49 Dejv | skóre: 36 | blog: Jak ten blog nazvat ... ? | Ostrava
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

Ahoj

Jeden (asi hloupy) napad - na lokalnim rozhrani mit dve adresy (samozrejme z ruznych podsiti), na servery taky a pakety od Providera_1 posilat na LAN_Addr_1 a od Providera_2 na LAN_Addr_2? Myslenka je ta, ze server posle odpoved do stejne subsite a router podle toho pozna, pres ktereho providera ji ma poslat ven.

Mozna taky pouzit virtualni rozhrani (eth1.1, eth1.2)...

Dejv

Pevne verim, ze zkusenejsi uzivatele me s mymi napady usmerni a poslou tam, kam tyto napady patri...
22.9.2011 13:37 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

Ahoj, dik za reakciu.

rozmyslal som aj nad tymto variantom. Problem vsak je, ze ak tych verejnych sluzieb v lokalnej sieti je viac (per server), tak sa pre kazdy server nasobia adresy a vznika podla mna este vacsia neprehladnost. Jednoduhsia varianta je markovat pakety od lokalneho servera s verejnou sluzbou a tym ich posielat von spravnym providerom. Avsak toto riesenie sa neda pouzit pre pripad, kedy by mala byt rovnaka sluzba dostupna cez oboch providerov zaroven a teda rozhodovanie Linux routra by muselo byt dynamicke (avsak tento scenar zatial nehrozi).

22.9.2011 13:20 NN
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
No on ten popis toho 'split access' je dost divny, kdyz v prvni vete tvrdi, ze to funguje pro pakety ktere jdou dovnitr a vraci se pres stejneho providera a v posledni vete tvrdi, ze to funguje pouze pro lokalni sit a router samotny..

Jses si jisty ze to mas presne podle toho navodu ? Samostatne routovaci tabulky, prirazeni rozhrani a siti a prirazeni vnejsich adres ?

NN
22.9.2011 13:33 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

Split access funguje pri kontaktovani samotneho Linux routra konfigurovaneho na SplitAccess, takze ak je cielovym hostom pre IP packet zvonka samotny Linux router (a jeho nejaka verejna adresa), tak smerovanie cestou spat bude spravne (zafunguje ip rule from <IP> lookup <table> s naslednym lookupom do smerovacej tabulky priradenej danej kontaktovanej IP adrese).

Ano, mam to presne tak, a tento moj vyssie popisovany postup SplitAccessu funguje (overene). Avsak pri mojom probleme sa jedna o jeho modifikaciu, kedy packet neskonci na samotnom Linux routri (konfigurovany na SplitAccess), ale je presmerovany kdesi do priamo pripojenej lokalnej siete. A v tom je ten rozdiel... to znamena ze nezafunguje ip rule from <IP> lookup <table> na vracajuci sa IP packet od vnutornej sluzby, ale linux router sa k nemu sprava ako k normalnemu paketu, ktory v jeho tabulkach podlieha jedine spetnemu DNATtu (resp. od-DNAT-ovaniu). A ja riesim ci to tak ma byt a ci sa to neda nejak dynamicky osetrovat.

22.9.2011 14:52 Pindal
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Mám úplně stejnou zkušenost. Problém, že překlad lokální adresy odchozího paketu na příslušnou veřejnou, se dělá až _po_ určení odchozího rozhraní. V současných kernelech bez patche to není možné ovlivnit. Jako řešení jsem použil již zmiňované dvě různé IP adresy na lokálním serveru. Další možnost jsou VLAN.
22.9.2011 22:52 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
neviete o nejakom oficialnom threade (lwn.net, diskusie, maillisty a pod..), kde by sa tento problem riesil? chcel by som si o tom nieco viac precitat. neviem ani pod akymi klucovymi slovami to hladat...nic rozumne som nenasiel. diki
23.9.2011 08:15 Pindal
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Také jsem nic nanašel, proto jsem se díval přímo do zdrojáků jádra.
22.9.2011 23:49 NN
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Jeste by to slo jinak. Kdyz se zbavis toho NATu a procpes tu sluzbu na verejnou ip adresu az do vnitrini site(respektive DMZ) a potom to staticky naroutujes na routeru. Imho sluzba pristupna zvenku nema ve vnitrni siti co delat. Prave proto, ze se to takto standartne nedela, moc informaci o tom nenajdes.

NN
23.9.2011 00:02 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

zial varim z toho co je (nedostatok verejnych adries). sluzba je zaroven dostupna inou formou pre inych klientov. toto je alternativa, ktora je pouzitelna a da sa povedat ze aj nutna. a ak sa nemylim DNAT je urceny prave pre taketo pripady pouzitia.

Ale ano, nie je to podla kucharok typu "Best Practices".

23.9.2011 00:24 NN
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Volny port na routeru nemas ?

NN
23.9.2011 00:30 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
eh? volny port na co? mam a vyuzil som ho tak ako som to spisal... na routri sluzba nebezi, lebo nemoze. bezi na vnutornom serveri kam je forwardovana...
24.9.2011 17:21 bakchus
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Podobny problem som riesil aj ja. Multihoming som mal nastaveny pomocou shorewall a tcrules (rad ho pouzivam, je prehladny a skoro dokonaly). Vsetko slo ako ma, ale jeden svinsky server vovnutri siete zacal vzdy komunikovat skor, ako shorewall nabehol a postaral sa o kompletnu konfiguraciu iptables. A pakety von sli s IP adresou WAN1 rozhrania cez WAN1 interfejs. Vyriesil som to tak, ze vzdy po starte shorewalu vymazem tabulku conntrack. Potom to uz ide vsetko ako ma.
Řešení 1× (timeos (tazatel))
24.9.2011 17:53 tomk
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom
Ahoj,

doufam, ze to spravne chapu, ale myslel jsem si, ze na podobne veci je mozne pouzit connection marking (-j CONNMARK) ve spolupraci s packet markem (-j MARK).

Nekde v preroutingu si nova spojeni z venku omarkovat, pro vracejici established obnovit connection marky a podle nich pak paket nechat s pomoci "ip rule fwmark" odroutovat spravnou smerovaci tabulkou.

Tomas
25.9.2011 18:45 timeos | skóre: 32
Rozbalit Rozbalit vše Re: Multihoming s policy routingom a DNATom

Vyborne, toto je presne to, co zabralo a zaroven je to dynamicke :). O cieli CONNMARK som len pocul, nevedel na co je a kvoli comu realne vzniklo (prave kvoli tomuto typu problemu... "Very useful especially for asymmatric routing in combination with MASQUERADE" ...vid lwn.net)

V principe na linux routri staci pridat nasledovne pravidla:

-t mangle -A PREROUTING -j CONNMARK --restore-mark
-t mangle -A PREROUTING -i $if1 -j MARK --set-mark 1
-t mangle -A PREROUTING -i $if1 -j CONNMARK --save-mark
-t mangle -A PREROUTING -i $if1 -j MARK --set-mark 0
-t mangle -A PREROUTING -i $if2 -j MARK --set-mark 2
-t mangle -A PREROUTING -i $if2 -j CONNMARK --save-mark
-t mangle -A PREROUTING -i $if2 -j MARK --set-mark 0

...a packet cestou spat dostane znova znacku (-j CONNMARK --restore-mark), ktoru dostal jeho paket predchodca (-j MARK --set-mark X) z toho isteho spojenia ked vchadzal routrom dnu.

Pravidla, ktore tu pisem som musel doplnit pravidlami so "--set-mark 0", nakolko konektivita bez nich nefungovala - Lebo vchadzajuci paket bol hned oznackovany, tym automaticky vyhovel pravidlu "ip rule from all fwmark 0xZNACKA lookup <table>" a hned zbehol to odchodzej smerovacej tabulky pre zvoleneho ISP. Preto som tym pridanym pravidlom znacku paketu zas odstranil (ale ta uz bola zapamatana v connmark (-j CONNMARK --save-mark) takze to nevadilo) a nasledne bol paket smerovany spravne.

tomk, velke dik. Ostatnym diki za rady a napady.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.