[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Idee zur TCP-Paket-Manipulation gesucht



Hallo Liste,

ich habe folgende Situation:

Eine relativ große Datenmenge, die ziemlich aufgebläht ist, soll per TCP über eine WAN-Strecke transportiert werden. Latenz ist für den Anwendungszweck vernachlässigbar, die Datenmenge sorgt aber dafür, dass man längere Zeit die WAN-Strecke zustopft. Mittels Traffic Shaping kann man den Traffic natürlich so beeinflussen, dass die anderen Anwender der WAN-Verbindung nicht sonderlich darunter leiden, aber eben nur um den Preis, dass die Übertragung der Daten noch länger dauert.

Die Daten lassen sich aber relativ gut komprimieren - nur leider nicht mit der im zur WAN-Strecke gehörenden VPN-Router eingebauten Komprimierungsfunktion. Aber selbst GZIP wirkt schon Wunder.

Momentan löse ich das so, dass ich daher auf einem anderen Computer unter einer anderen IP-Adresse im Netz der Absender-IP auf dem gleichen Port einen Dienst betreibe, der die Daten entgegennimmt, komprimiert, und dann zu einem weiteren Computer, diesmal im Zielnetz am anderen Ende der WAN-Verbindung, überträgt. Dort werden die Daten dann wieder ausgepackt und an den Zielrechner übertragen. Dem Absendersystem sage ich einfach, dass das Zielsystem die IP hätte, auf der mein Komprimierer läuft.

Das klappt so lange, wie es nur ein Zielsystem gibt und man die IP daher hart ins Entpackskript eincodieren kann.

Geht es auch irgendwie eleganter, so dass das auch für n>1 Zielsysteme skaliert? Vielleicht per iptables auf dem Router, ähnlich wie man bei HTTP einen transparenten Proxy einklinken kann? Bzw. geht es per ebtables (filternde Bridge statt Router)?

Wenn es per iptables/ebtables geht, sind die zwei zentralen Fragen wohl:
1) Wie greife ich das Paket ab und leite es an mein Komprimierungsskript weiter? 2) Wie komme ich an die Ziel-IP, die der Absender eigentlich erreichen wollte, so dass ich sie ebenfalls an das Skript übergeben kann?

"Wie übertrage ich die Ziel-IP an den Entpack-Rechner" ist dagegen schon gelöst.

Ansonsten lautet die Frage: Wenn nicht per iptables/ebtables, wie dann?

Gruß
Stefan


Reply to: