Dotaz: Multihoming s policy routingom a DNATom

[timeos]

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...

---

---

Odpovědi

[NN]

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

[timeos]

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.

[Dejv]

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

[timeos]

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).

[NN]

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

[timeos]

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.

[Pindal]

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.

[timeos]

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

[Pindal]

Také jsem nic nanašel, proto jsem se díval přímo do zdrojáků jádra.

[NN]

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

[timeos]

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".

[NN]

Volny port na routeru nemas ?

NN

[timeos]

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...

[bakchus]

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.

[timeos]

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

[timeos]

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.