Forward trafficu na jiný server, se zachováním původní cesty

[Buh_skoro]

Ahoj,

potřeboval bych poradit s problémem, který mi už delší dobu leží v hlavě. Máme server, kam nám různá zařízení posílají přes UDP data. Nyní bych potřeboval pro určitou skupinu příchozího trafficu jedním vpn tunelem zajistit forwarding na jiný server, ovšem zároveň potřebuji, aby se vracely odpovědi těm konkrétním zařízením stejnou cestou. Ale ne jen po omezenou dobu, ta odpoěď může být odeslána i několik hodin po žádosti. Máme na to C-čkový script, který si tvoří vlastní databázi a handluje to podle ní, ale pochopitelně se nám to nelíbí, nejspíš existují mnohem elegantnější cesty. Může prosím někdo poradit, co s tím?

Moc díky.

Jim

[Reklama]

[Filip Jirsák]

Buď si musíte na tom cílovém serveru pamatovat, že požadavek přišel tunelem, a odpověď odeslat opět do tunelu, nebo si na tom přeposílajícím serveru musíte zapamatovat, odkud paket přišel, změnit jeho zdrojovou adresu na ten přeposílací server (SNAT) a odpověď pak podle zapamatovaných údajů zase přepsat zpátky. Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

[Miroslav Šilhavý]

přes UDP data. Nyní bych potřeboval pro určitou skupinu příchozího trafficu jedním vpn tunelem zajistit forwarding na jiný server, ovšem zároveň potřebuji, aby se vracely odpovědi těm konkrétním zařízením stejnou cestou. Ale ne jen po omezenou dobu, ta odpoěď může být odeslána i několik hodin po žádosti. Máme na to C-čkový script, který si tvoří vlastní databázi a handluje to podle ní, ale pochopitelně se nám to nelíbí, nejspíš existují mnohem elegantnější cesty.

V případě UDP nemáte jinou možnost, než do routeru doprogramovat helper, který podle učitých pravidel bude vědět, co je odpověď, a kam ji poslat.

V případě TCP je to jednoduché. Tam navážete spojení, a odpovědi v rámci spojení se vrací tam, odkud byl původní požadavek. U TCP Vám stačí zvýšit timeouty na conntracku, aby si je to pamatovalo i několik hodin.

V případě UDP neexistuje žádné spojené. Po UDP přijde paket na cílový server. Cílový server NEODPOVÍDÁ na spojení. Cílový server může jedině odeslat nový UDP paket "někam zpět". Díky tomu router neví, který paket dovnitř souvisí se kterým paketem ven. A od toho je právě "HELPER".

Helper budete potřebovat buďto v případě, že je v cestě NAT, nebo pokud chcete vybírat routovací tabulku ("stejná cesta ven").

[Miroslav Šilhavý]

Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

Souhlas, co píšete, jen se to týká TCP. U TCP je navázané spojení a na routeru je jasné, který packet směrem ven souvisí s s předchozím dovnitř. U UDP žádnou takovou možnost nemáte, musíte leda napsat helper, který to z něčeho vyvěští. Buďto, třeba, z kombinace portů, nebo, třeba, z obsahu packetu (L7).

[Filip Jirsák]

Ta druhá varianta je přesně to, co dělá NAT, ale nejsem si jistý, zda je možné nastavit limity linuxového NATu tak, aby držel tabulku spojení po dobu několika hodin. A i pokud by to uměl, nevím, jak se to bude chovat, je to daleko za předpokládaným způsobem použití.

Souhlas, co píšete, jen se to týká TCP. U TCP je navázané spojení a na routeru je jasné, který packet směrem ven souvisí s s předchozím dovnitř. U UDP žádnou takovou možnost nemáte, musíte leda napsat helper, který to z něčeho vyvěští. Buďto, třeba, z kombinace portů, nebo, třeba, z obsahu packetu (L7).

Ne, týká se to obojího. Linuxový NAT nepracuje na úrovni spojení, ale na úrovni paketů. NAT si eviduje tabulku spojení (což nemusí být jen TCP/IP spojení, ale i komunikace založené na UDP, řídící a datové spojení FTP) a ke každému spojení si eviduje údaje o parametrech příchozích paketů a údaje pozměněných paketů. Na základě této tabulky pak jednotlivé pakety transformuje. Spoustu těch helperů pro sledování spojení obsahuje už Netfilter – pro FTP, SIP, DNS…

[Reklama]

[Miroslav Šilhavý]

Ne, týká se to obojího. Linuxový NAT nepracuje na úrovni spojení, ale na úrovni paketů. NAT si eviduje tabulku spojení (což nemusí být jen TCP/IP spojení, ale i komunikace založené na UDP, řídící a datové spojení FTP) a ke každému spojení si eviduje údaje o parametrech příchozích paketů a údaje pozměněných paketů. Na základě této tabulky pak jednotlivé pakety transformuje. Spoustu těch helperů pro sledování spojení obsahuje už Netfilter – pro FTP, SIP, DNS…

Ano, ale to jsou přesně ty helpery. Čisté UDP není jak trackovat, a musí existovat pomocníček, který conntracku poradí, jaký UDP packet souvisí s jakým. Na TCP potřebujete helper, co já vím, jen na aktivní FTP, kdy je potřeba otevřít prostup zpět na ftp-data.

Bez programování modulu jádra prostě UDP kolega neodtrackuje, není se čeho chytit.

[Filip Jirsák]

Ano, ale to jsou přesně ty helpery. Čisté UDP není jak trackovat, a musí existovat pomocníček, který conntracku poradí, jaký UDP packet souvisí s jakým. Na TCP potřebujete helper, co já vím, jen na aktivní FTP, kdy je potřeba otevřít prostup zpět na ftp-data.

Bez programování modulu jádra prostě UDP kolega neodtrackuje, není se čeho chytit.

Nemyslím si, že by NAT byl nejvhodnějším řešením. Na sledování UDP spojení na základě IP adres a portů není potřeba nic psát, je to už součástí netfilteru, stejně jako to sledování TCP spojení. A i kdybyste chtěl psát vlastní helper, není nutné psát to do jádra, conntrack helpery mohou fungovat i v uživatelském prostoru.

[Miroslav Šilhavý]

Nemyslím si, že by NAT byl nejvhodnějším řešením. Na sledování UDP spojení na základě IP adres a portů není potřeba nic psát, je to už součástí netfilteru, stejně jako to sledování TCP spojení. A i kdybyste chtěl psát vlastní helper, není nutné psát to do jádra, conntrack helpery mohou fungovat i v uživatelském prostoru.

Pokud není v cestě NAT, pak není přeci co řešit. Paket dorazí na cílovou adresu. Jediná komplikace nastává právě v případě NATU. A to lze usuzovat z popsané situace v kombinaci s problemem

[Filip Jirsák]

Pokud není v cestě NAT, pak není přeci co řešit. Paket dorazí na cílovou adresu. Jediná komplikace nastává právě v případě NATU. A to lze usuzovat z popsané situace v kombinaci s problemem

Já jsem odpovídal na původní dotaz, kde se Jim ptá, jak komunikaci určenou pro jeden server (jednu IP adresu) přesměrovat na jiný server (jinou IP adresu). Což jde udělat NATem přímo přesměrováním paketů, jde to udělat proxy serverem (který v případě UDP bude pro vnějšího pozorovatele nejspíš k nerozeznání od NATu) a jde to udělat aplikační proxy (server data přijme a nějak zpracuje ve vlastní režii a následně je pošle dál).