Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: noob 05. 04. 2024, 08:28:14
-
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).
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.
-
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...
-
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.
-
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.
-
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.
*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
-
@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í :-)
-
Tohle je funkční řešení:
*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.
-
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))
-
Vyměnil jsem SNAT za MASQUERADE, výsledek je na první pohled stejný. Funguje to a cílový stroj nevidí IP adresy klientů.
-
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