[linux] firewall routering m.b.v SNAT

[pretorian]

Ik moet op mijn ClarkConnect server, poort 82 forwarden, naar een server op mijn lan, welke een eigen verbinding heeft naar het internet. Probleem is echter dat als ik de poort simpel forward, de ontvangende server, de pakketten over zijn eigen internet verbinding terugstuurt naar de verzender, welke zich dus buiten het lan bevind, maardit verkeer moet dus over de internet verbinding van mijn clarkconnect gaan. Met een static route is dit niet op te lossen. Ik heb al een beetje zitten sleutelen in mijn firewall.rc maar ik kom er niet uit.


situatie is als volgt:

10.0.0.10 is het lokale ip van mijn clarkconnect en 10.0.0.7 is het lokale ip van de server met de onafhankelijke internetverbinding. het binnenkomend verkeer op eth0 poort 82 moet worden geforward naar 10.0.0.7:82, en de packets moeten als source adres 10.0.0.10 hebben.


ik krijg het met de ip tables niet voor mekaar. ik heb het onder andere geprobeerd met deze opdracht in mijn firewall.rc:

iptables -A POSTROUTING -t nat -p tcp --dport 82 -j SNAT --to 10.0.0.7:82 --to-source 10.0.0.10:82

Zodra ik de firewall restart krijg ik geen foutmelding dat er iets fout is aan de opdracht.
wat doe ik fout?

[Equator]

Het is toch destination NAT..
Je DNAT (Portmapped) poort 82 (tcp naar de interne server. Deze server zal dan zijn replay geven op de originator van dat pakketje. (en voor hem is dat de firewall) De firewall zet dat weer terug naar de officiele originator en stuurt hem via zijn eigen internet verbinding.

M.a.w. De server op 10.0.0.7 ziet in het inkomende pakketje dus nog steeds het source IP adres van de officiele originator.

Doe die poort 82 een gewoon portmappen naar de interne server. werkt het dan niet

iptables -A PREROUTING -t nat -p tcp --dport 82 -j DNAT --to 10.0.0.7:82

[ Voor 8% gewijzigd door Equator op 19-12-2002 14:12 ]

[pretorian]

ja, maar sinds hij dus een eigen internet verbinding heeft, en de uiteindelijke verzender zich buiten het lan bevind zal ie altijd zijn packets terug sturen over zijn eigen internet verbinding, behalve als ik een static route zou aanmaken op de betreffende server, wat dus niet mogelijk is.

[pretorian]

M.a.w. De server op 10.0.0.7 ziet in het inkomende pakketje dus nog steeds het source IP adres van de officiele originator.

klopt als een bus...

Doe die poort 82 een gewoon portmappen naar de interne server. werkt het dan niet

zoals ik al in mijn post zij, dit werkt dus niet...

[Equator]

Nee, de server met IP adres 10.0.0.7 zal het packetje terug sturen naar de verzender. (voor hem is dat de ClarkCOnnect firewall).
Hij zien in het hele packetje niet eens het externe IP adres staan, dus hij weet niet beter als dat de ClrkConnct doos een verbinding met hem maakt.

[Equator]

pretorian schreef op 19 December 2002 @ 14:22:
[...]

klopt als een bus...

[...]

zoals ik al in mijn post zij, dit werkt dus niet...

Omdat jij een iptables regel met SOURCE NAT erin zet. Maar het moet destination nat zijn.

M.a.w. De server op 10.0.0.7 ziet in het inkomende pakketje dus nog steeds het source IP adres van de officiele originator.

hiermee bedoelde ik te zeggen, dat het nu zo is, dat de server op 10.0.0.7 nog steeds het originele originator adres ziet. I.p.v. het ip adres van de clarckconnect. De clarck connect moet dat met NAT veranderen.

[ Voor 38% gewijzigd door Equator op 19-12-2002 14:27 ]

[Verwijderd]

Je moet beide gebruiken, zowel SNAT als DNAT.. daarnaast zit er een fout in je DNAT regel (Zoals hij zelf al aangeeft)..

de regels:

code:

iptables -A PREROUTING -t nat -p tcp --dport 82 -j DNAT --to 10.0.0.7
iptables -A POSTROUTING -t nat -p tcp --dport 82 -j SNAT --to 10.0.0.10

die :<port nummers> zijn niet echt nodig, aangezien het dezelfde poort betreft.

Let even op dat je wel het juiste verkeer pakt, vooral het verschil tussen dport en sport kan in dit geval van belang zijn, echter dat hangt ook van het gebruikte protocol af.

//edit

uitleg: pakketje komt binnen met afzender-IP en als destination router IP. De router/firewall haalt de destination eraf en vervangt het door 10.0.0.7 in de prerouting chain. Daarna wordt het pakketje gerouted naar 10.0.0.7. Als laatste haalt hij er in de postrouting-chain het source-ip eruit en vervangt het door z'n eigen.

Voor de client lijkt het dus alsof hij met de firewall communiceert, en voor de server ook.

[ Voor 29% gewijzigd door Verwijderd op 19-12-2002 14:31 ]

[pretorian]

bedankt mensen! Het is gelukt nu...

[Verwijderd]

pretorian schreef op 19 december 2002 @ 14:44:
bedankt mensen! Het is gelukt nu...

Wat was het nu dan?

[Equator]

Jij hezik.. Jij snapt er meer van

[Verwijderd]

Nog even voor de duidelijkheid. Je wilde dus een soort asymmetrische routering? Dus pakket heen en terug via verschillende internet verbindingen?

[Verwijderd]

Verwijderd schreef op 19 December 2002 @ 14:54:
Nog even voor de duidelijkheid. Je wilde dus een soort asymmetrische routering? Dus pakket heen en terug via verschillende internet verbindingen?

Yupz en dat gaat alleen werken op Hezik's manier

[Equator]

Nee, heen en terug via dezlefde weg. Althans, dat was imo de bedoeling..

[Verwijderd]

Verwijderd schreef op 19 December 2002 @ 14:59:

[...]

Yupz en dat gaat alleen werken op Hezik's manier

Ja, dat snap ik wel. Hetgeen ik alleen aan zat te denken is dat je geen connectie tracking moet gaan toepassen in dit geval. De router ziet namelijk de pakketten die terug komen niet langs komen, omdat die via die andere internetverbinding gaan. Krijg je in dat geval niet een TCP tracking tabel met allemaal niet beantwoorde verbindingen? Ok, ze zullen uiteindelijk een timeout krijgen, maar als de tabel nou vol is voordat de timeout afloopt?

[Verwijderd]

Ik moet zeggen dat ik er zelf nog nooit mee gespeeld heb, maar hetgeen ik vernomen/gelezen heb wil dat inderdaad soms de grootst mogelijke problemen opleveren. Ik geloof dat het zelfs specifiek afgeraden wordt ergens in de iptables documentatie.

[ Voor 54% gewijzigd door Verwijderd op 19-12-2002 15:45 ]

[Verwijderd]

ja precies, ik meen mij ook zoiets te herinneren, maar ook ik heb dit nog nooit getest. Het is een vrij exotische config en ik vraag mij ook af wat de reden is hiervoor. Misschien kan dit topic starter aangeven wat zijn beweegreden is en anders is dit gewoon een opmerking dat er mogelijk problemen kunnen optreden indien het een druk bezochte/veel gebruikte applicatie is.

[Verwijderd]

Jongens, er is hier juist geen sprake van een asymmetrische verbinding. De clou van het verhaal is dat zonder aanpassing de verbinding asymmetrische zou zijn, iets wat topicstarter juist niet wil.

Er wordt idd gewaarschuwd in de documentatie van iptables voor de combinatie connection tracking met asymmetrische verbindingen:

If you are doing NAT on a connection, all packets passing both ways
(in and out of the network) must pass through the NAT'ed box,
otherwise it won't work reliably. In particular, the connection
tracking code reassembles fragments, which means that not only will
connection tracking not be reliable, but your packets may not get
through at all, as fragments will be withheld.

bron

maar nogmaals, daarvan is hier geen sprake..

[Verwijderd]

Hhm, blijkbaar begrijp ik de configuratie dan niet helemaal

zoals ik het had begrepen:

code:

internetcon1 -------server--------------|
                                        |
                                      hub
internetcon2-------clarke con router----|

Dus connecties komen binnen op internetcon2 worden door de clarke connect router geforward naar de server en de replies gaan via internetcon1. Of zit ik nu helemaal verkeerd

Als dit namelijk de setup is heb je wel degelijk assymmetrische routering en kun je het hierboven beschreven probleem op de clarke connect router krijgen.

[ Voor 25% gewijzigd door Verwijderd op 19-12-2002 17:03 . Reden: in gevecht met ascii art :( ]

[Verwijderd]

Zo begreep ik het ook

[Verwijderd]

Dat zou idd de situatie zijn, zonder wijziging. Pakket komt binnen via con1, wordt naar server gestuurd en exit via con2. Dit wilde de topicstarter niet, die wil dat alles (zowel inkomend als uitgaand) via con1 gaat.

Dit blijkt overigens ook heel duidelijk uit de iptables regels die ik hier gepost heb, valt me een beetje van je tegen (nelske)


//edit
kleine type, ik!=meervoud

[ Voor 6% gewijzigd door Verwijderd op 19-12-2002 17:10 ]

[Verwijderd]

Nu ik er nog een keer naar kijk snap ik inderdaad hoe het werkt. De openingspost is alleen niet al te duidelijk (2 mensen die het verkeerd begrijpen) en ik begreep juist dat de topicstarter asymmetrische routering wilde ipv het voorkomen. Daarom ben ik wel voor acsii tekeningen en kun je dit soort verwarring voorkomen.

[Equator]

Probleem is echter dat als ik de poort simpel forward, de ontvangende server, de pakketten over zijn eigen internet verbinding terugstuurt naar de verzender, welke zich dus buiten het lan bevind, maardit verkeer moet dus over de internet verbinding van mijn clarkconnect gaan.

uit dit stukje haalde ik dus duidelijk dat het verkeer ook terug moest gaan via de zelfde nat box als dat het binnen kwam.

Maar, ik ben toch nog wel even benieuwd of ik dan zo verschrikkelijk dom heb zitten denken.

een pakketje komt binnen op de clarkconnect, en zijn ip destination wordt herschreven naar het interne IP adres.
Dan komt het binnen op de interne server. Wat is nu voor die server de originator De clarkconnect box toch of wordt bij Destination nat (portmappen) het originator adres niet herschreven zoals bij sourceNAT.

[Verwijderd]

De DNAT zorgt ervoor dat het destination ip adres wordt herschreven naar het interne adres (10.0.0.7). Alleen deze regel zorgt ervoor dat het source adres ongewijzigd blijft. Als je dit zo laat stuurt de interne server het antwoord hierop via zijn eigen internet connectie.(default gateway)

De SNAT veranderd het source ip adres van de client in die van de clarke connect gateway. Hierdoor wordt het pakket dus ook weer via de clarke connect gateway terug gestuurd ipv. waar de default gateway van de interne server heen wijst. Het source adres is namelijk veranderd in een adres op het lokale netwerk.

Dus als het pakket aankomt bij de interne server heeft het bij toepassing van SNAT en DNAT als source ip het adres van de clarke connect gateway/router (10.0.0.10) en destination het adres van de server (10.0.0.7). De interne server denkt dus tegen de lokale clarke connect router de aanvraag heeft gestuurd. Die de-NAT (zowel SNAT als DNAT) alles weer keurig en stuurt het reply terug naar de client.

Hoop dat je het een beetje snapt.

[Equator]

Yep, is nu allemaal een stuk duidelijker. Daarstraks in de auto zat ik er ook al over te denken, en toen werd het mij eigelijk al een stukkie duidelijker.

Hulde balou de beer