Přesměrování UDP přes iptables

[noob]

Zdravím vespolek.

Používám démon uredir pro přesměrování UDP portu na serveru na jiný stroj v internetu (a jiný port).

Kód: [Vybrat]

uredir -n -s  [port] [cílová ip] [cílový port] Funguje to svěle, pokud není démon pod velkou zátěží, pak má tendenci spadnout. Můžu vytvořit watchdog, ale na serveru jsou k dispozici i iptables, což by bylo elegantnější řešení.

Zkoušet jsem hledat jak na to, nicméně tuhle trivialitu prostě neumím dotáhnout do konce.

[Reklama]

[František Ryšánek]

iptables -t nat -I PREROUTING -d <moje_ip_adre_sa> -p udp --dport <cilovy_port> -j DNAT --to <adresa>:<port>

Pokud dokážete zajistit, aby odpovědi chodily zpátky stejnou cestou, tak se to nejspíš i přeloží zpátky (pro NAT zafunguje automatický connection tracking). Případně se tomu zpětnému směrování asi dá dopomoci následujícím SNATem v chainu POSTROUTING...

[Zdenek -]

Kód: [Vybrat]

iptables -t nat -I PREROUTING  -i <ETH_S_KLIENTY> -p udp --dport <NASLOUCHAJICI_PORT_ROUTERU> -j DNAT --to <IP_SERVERU>:<PORT_SERVERU>
iptables -t nat -I POSTROUTING -o <ETH_K_SERVERU> -p udp --dport <PORT_SERVERU> -j MASQUERADE
Tenhle příklad je o něco spolehlivější, protože nahradí zdrojovou adresu paketů adresou routeru, takže server nemusí umět spojení zpět ke klientovi.
Možná by se to dalo přepsat čistěji s využitím targetu MARK, protože v tomto případě se spoléhá při napasování obou pravidel jen na ten port.
A druhá nevýhoda je, že server uvidí jako IP klientů jen IP routeru, takže věci jako logování nebo fail2ban postrádají na serveru smysl, muselo by se jedině dobastlit na tom routeru.

[Hamparle]

Trví tazatel na tom, aby viděl cíl  skutečnou IP zdroje místo DNATované?

PAk v tom případě není možné použít SNAT/(MASQUERADE??).
Pak se to dělá přes iptables -t mangle prerouting -j fwmark (nevím, jestli connmark, mám zkušeosti jen s UDP) a tuším že je ntutné i do PREROUTING přidat resoremark, ale to bych chtěl objasnit. Bez něj mi to nefungovalo
A to hlavní přidat ip rule add  (selektor) table 3455  a ip route add default table 3455
 
Existuje lepší řešení, jak ajistit přes ip route+rule vracení přes správné rozhraní? Takhle je tam interface zadrátovaný napevno. ALe existuje nějaká konstrukce typu: odešli paket na stejné rozhraní, jako ze kterého přišel?

Taky bude nutné pořešit rp_filter, pokud je strict.

[noob]

Díky za odpovědi. Zkoušel jsem obě varianty a zatím stále neúspěšně. IP klientů vidět nemusím, dokonce bych řekl, že ani nechci.

Pro dokreslení situace, takhle vypadá ta první varianta. Konfigurační soubor jsem postupně osekal na minimum.

Kód: [Vybrat]

*nat
:PREROUTING ACCEPT
:INPUT ACCEPT
:POSTROUTING ACCEPT
:OUTPUT ACCEPT
-I PREROUTING -d <ip routeru> -p udp --dport 53 -j DNAT --to <cilova ip>:54
COMMIT
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
COMMIT


[Reklama]

[František Ryšánek]

@Hamparle má pravdu s tím rp_filterem. Pokud to nechce fungovat, zkuste rp_filter dočasně vypnout (pokud je to potřeba vypnuté, tak nahradit IPtables pravidly). To že paket přišel rozhraním a odejde tím samým, podle mého není třeba nijak moc explicitně řešit, pokud tomu následující firewallová pravidla nějak explicitně nebrání.

Ještě mě zaujalo: lapáte pakety určené pro port 53 (DNS dotazy) a forwardujete na konkrétní další stroj na port 54? Na jednu stranu mám sklon v tom hledat nedorozumění, pokud se ptáte na triviální NAT pomocí IPtables - na druhou stranu, pokud Vám to fungovalo skrz user-space proxy prográmek, tak asi víte co děláte = samotný záměr asi není blbě... a tím pádem mi do něj nic není :-)

[noob]

Tohle je funkční řešení:

Kód: [Vybrat]

*nat
-A PREROUTING -p udp --dport 53 -j DNAT --to-destination <cílová ip>:54
-A POSTROUTING -p udp -d <cílová ip> --dport 54 -j SNAT --to-source <ip routeru>
COMMIT
*filter
COMMIT

S rp_filtrem jste měli pravdu, když ho zapnu, jde to do kytek.

A ano, žongluji s DNS servery na různých portech

Díky za rady.

[František Ryšánek]

Ještě mi přijde, že má @Zdeněk možná pravdu s tou maškarádou. Prostý SNAT jenom přeloží zdrojovou IP adresu, podle mého neřeší zdrojový port. Pokud použijete maškarádu, měla by taky rozházet source UDP port, a díky tomu být schopna, párovat zpětně odpovědi k dotazům, i pokud je klientů víc a jejich transakce se mohou "překrývat v čase". S prostým SNATem se snáze stane, že pokud se sejdou transakce od více DNS klientů, nemusí mapování odpovědí k dotazům na straně NATujícího routeru klapnout správně.

[Ħαℓ₸℮ℵ ␏⫢ ⦚]

Ono je nutné rozlišovat upravidel i směr , pak mají dvojí kontext
, ostatnè terminologie  asi od cisco se nazývá inside(LAN),outside(ven(ku)),global,local.

Typicky  ve směru LAN→ven se SNAT+MASQ. se používá pro  to domácí natování a v opačnem směru  DNAT pro forwarding na vybraný pc za routerem

Ale i v opačnym směru mají opodstatnění ty pravidla taky- toto vlákno je důkaz. V případě kontextu port forwardingu (Dnat outside do inside) SNAT(out→in) právě  zamaskuje adresy původce. (Kromě mandatorního DNAT)

Ale u kontextu nat (snat /masq in→out) Dnat (in→out)nedává smysl... Nebo nějaký obskurní by se asi našel...

(Conntrack tak jako tak upraví korektně   pakety v v obou směrech, to je druhá nezávislá věc))

[noob]

Vyměnil jsem SNAT za MASQUERADE, výsledek je na první pohled stejný. Funguje to a cílový stroj nevidí IP adresy klientů.

[Adam Kalisz]

S tím rp_filtrem by asi šlo použít i 2 (tam se testuje jestli je zdrojová adresa přímo dostupná, pokud ne, paket se zahodí): https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt