iptables: pakketten naar andere publieke host

[Boudewijn]

Hoihoi


Ik heb een debian doos staan met daarop een ip, .90 .
Wegens administratieve redenen (MX record verkeerd ingesteld door iemand, is even niet 1-2-3 aan te passen door bureaucratie etc etc) wil ik alle traffic op poort 25 redirecten naar ip .93.
.93 is een guest os op de main doos, en draait dan ook een SMTP daemon.
.90 doet dit niet, en hier heb ik ook niet echt behoefte aan (separation of concerns, security etc).


Ik heb nu wat met nat zitten te prutsen, maar krijg het niet voor elkaar. Ook weet ik niet of NAT wel is wat ik zoek.
Ik wil dus alles op poort 25 van het ene publieke IP naar het andere publieke IP doorsturen . Hier is ook een redirector daemon voor, maar dat vind ik niet echt een fijne optie.

Googlen levert vooral nat achtige oplossingen op, en ik weet niet of dat nou juist is wat ik wl.

code:

iptables -t nat -I PREROUTING -p tcp -d $host --dport 25 -j DNAT --to guest
iptables -I FORWARD -p tcp -d guest --dport 25 -j ACCEPT
iptables -A FIREWALL -p tcp -m tcp --dport 25 --syn -j ACCEPT

Uiteindelijk ben ik hierop uitgekomen, en de connectie naar host:25 wordt niet gereject, maar werken doet het ook niet .
Probleem is dat het guest os ook via het host os terug moet kunnen communiceren met de client gok ik.


Zou iemand me een zet in de juiste richting willen geven?

IPs omdraaien etc is geen optie (dan sloop ik tig andere records nml).

[ Voor 3% gewijzigd door Boudewijn op 04-10-2008 00:14 ]

[BoAC]

Heb je ip forward wel aan gezet?

code:

echo 1 > /proc/sys/net/ipv4/ip_forward

[blaataaps]

Boudewijn schreef op zaterdag 04 oktober 2008 @ 00:12:
Hoihoi


Ik heb een debian doos staan met daarop een ip, .90 .
Wegens administratieve redenen (MX record verkeerd ingesteld door iemand, is even niet 1-2-3 aan te passen door bureaucratie etc etc) wil ik alle traffic op poort 25 redirecten naar ip .93.
.93 is een guest os op de main doos, en draait dan ook een SMTP daemon.
.90 doet dit niet, en hier heb ik ook niet echt behoefte aan (separation of concerns, security etc).


Ik heb nu wat met nat zitten te prutsen, maar krijg het niet voor elkaar. Ook weet ik niet of NAT wel is wat ik zoek.
Ik wil dus alles op poort 25 van het ene publieke IP naar het andere publieke IP doorsturen . Hier is ook een redirector daemon voor, maar dat vind ik niet echt een fijne optie.

Dti is echter wel de werkende optie. Je guest zal retourverkeer terugsturen met zijn eigen IP, en de connectende client zal dat verkeer gewoon negeren, want die heeft niks met dat ip te maken. Je kunt met wat policy-based routing verkeer met als source-poort 25 (het retourverkeer dus) via je host routeren, die dan weer NAT naar zijn eigen IP moet doen. Moet jij maar bedenken wat je een fijnere optie vindt: een redirector of nodeloos gecompliceerde routering

[Boudewijn]

ipforwarding staat aan ja.

blaataaps: ja maar bij nat wordt ook het ip van de server herschreven, een locaal IP wordt omgeschreven naar een publiek ip.
Dus dat is volgens mij wel het zelfde principe als hier.

[Boudewijn]

Hmm raar zeg.
Toch maar voor rinetd gekozen, en net even geconfigged.
Dit als config:

code:

194.109.117.90 25 194.109.117.93 25
194.109.117.90 684 194.109.117.93 25

Dus zowel poort 25 als poort 684 (niet in gebruik) redirecten naar mijn guest os op 25.
Telnetten naar 25 van het host os werkt niet , maar naar 684 wel.

Met netstat vind je niets op 25 op het host os, want daar zou ik het probleem verwachten. Iemand nog ideeen?

offtopic:
Ohh fuck dubbelpost

[ Voor 3% gewijzigd door Boudewijn op 04-10-2008 16:53 ]

[BoAC]

Je vergeet de terugkerende pakketten weer te source-natten. Wat je moet doen is een full destination nat: http://linux-ip.net/html/nat-dnat.html zie paragraaf 5.7

[Boudewijn]

BoAC: Is dat als reactie op mijn geklooi met rinetd, of met iptables? Volgens mij zou het met rinetd zonder verdere iptables rules moeten kunnen werken.
Heb die full destination nat idd ook al gevonden ,maar lijkt niet te werken helaas met:

code:

echo 1 > /proc/sys/net/ipv4/ip_forward
#iptables -t nat -A PREROUTING -p tcp  -d 194.109.117.90 --dport 25 -j DNAT --to 194.109.117.93
#iptables -A FORWARD -p tcp -d 194.109.117.93 --dport 25 -j ACCEPT


iptables -t nat -A PREROUTING -d 194.109.117.90 -j DNAT --to 194.109.117.93
iptables -t nat -A POSTROUTING -s 194.109.117.93 -j SNAT --to 194.109.117.90

Zowel met de 2 bovenste als 2 onderste regels werkt het niet, als je telnet naar het host os op 25.
De connectie timet gewoon uit dus.

Wat ik aan rinetd raar vind is het feit dat 684 naar 25 wel werkt, maar 25 naar 25 niet. Ondanks dat er geen daemon op 25 draait op het host os.

[Boudewijn]

Update voor het nageslacht: na een reboot werkt het prima met rinetd.
Raar maar waar (er lijkt dus toch nog iets op poort 25 actief te zijn geweest).

[blaataaps]

Dat kan wel ja, de state table of iets anders heeft een vrij lange timeout, als er nog een geforwarde verbinding in de connection tracking table staat kan het behoorlijk lang duren voor je weer iets zinnigs met die poort kan doen, heb ik ook ervaren

[Boudewijn]

Voor de toekomst, is daar nog een tweak mee te doen om een reboot te voorkomen?
iptables was compleet leeg, netstat gaf ook niets aan en ps vond ook niets bij the usual suspects (exim, postfix etc).

[blaataaps]

Geen idee eigenlijk, in /proc/net/ip_conntrack staat dan nog van alles, maar of je daar iets aan kunt veranderen weet ik zo niet.

[Verwijderd]

HO, STOP, WACHT! Wat je nu doet, heeft de potentie levensgevaarlijk te worden!
Als jij gaat zitten SNAT-ten of gebruik maakt van een man-in-the-middle daemon, breek je afzender-controles, spam-controles, en nog veel meer... maar het ergste van alles, is dat je mogelijk een open relay aan het maken bent. (Sommige mailservers laten alles uit het eigen subnet toe.)

Doe dit niet, tenzij je weet wat je doet, en dat je weet hoe je kan controleren of jouw mailserver een open relay is geworden.

Ik zou er destination NAT van proberen te maken, met assymetrische terug-routering.

[ Voor 4% gewijzigd door Verwijderd op 06-10-2008 15:36 ]

[Boudewijn]

Mja dat accepteert hij dus niet.
Volgens de open relay check van abuse.net zit het ook wel snor .

All tests performed, no relays accepted.


Spam controle is dan maar even jammer, beter mail met wat spam dan geen mail... het is maar voor een paar dagen.
Ik snat trouwens volgens mij niet maar werk met rinetd.

[Verwijderd]

Boudewijn schreef op maandag 06 oktober 2008 @ 15:34:
Ik snat trouwens volgens mij niet maar werk met rinetd.

ik pas net m'n eerdere post aan...
voor rinetd geldt hetzelfde: het source ip wat de destination server ziet, is anders.

[Boudewijn]

Uhh ja maar waarom is dat nou in dit geval zo slecht?
Open relaying is niet het geval, en idd een grote fout als je het doet.
Spam-filter dat niet optimaal werkt neem ik voor lief, als dat al zo is.
Ook voor locale netwerk (alles behalve localhost) wordt alles gefilterd.

Enige probleem dat er zou kunnen komen is dat die server na een spamrun het ip van rinetd bant.