Re: Idee zur TCP-Paket-Manipulation gesucht
Am 20.11.2013 11:22, schrieb Christian Knoke:
Stefan Baur schrieb am 20. Nov um 01:05 Uhr:
Alles was irgendwie auf Stream-Komprimierung aus ist, taugt nicht.
Die Baustellen haben wir leider alle schon durch. (Was mich dazu
bringt, mich zu wundern, warum dort nicht ebenfalls GZIP, BZIP2 oder
XZ zum Einsatz kommen.)
Das ist also dein Problem?
Äh, nein. Das Problem ist, den Datenstrom auf einem Router oder einer
filtering Bridge abzufangen und umzuleiten, und dabei die ursprüngliche
Ziel-IP nicht aus den Augen zu verlieren, so dass man nicht für jede
neue Ziel-IP eine neue iptables/ebtables-Regel anlegen muss.
Der Teil "Komprimieren und weiterschicken" und der Teil "Entpacken und
an eine bekannte Ziel-IP weiterreichen" ist dagegen trivial.
Falls das aus meinen bisherigen Postings nicht so klar wurde:
Gesendet und empfangen werden die Daten von Nicht-Debian-Linux-Systemen
(genauer: auf der einen Seite ist es Windows, auf der anderen Seite ein
Embedded-Device), d.h. direkt auf diesen habe ich keine Möglichkeit,
einen Packer oder Entpacker einzubauen, ich muss die Daten unterwegs
abfangen und auf ein Debian-Linux-System weiterleiten, um sie zu
komprimieren, und auf der anderen Seite des VPN-Tunnels genauso -
Debian-Kiste, entpacken, weiterschieben an ursprüngliches Ziel.
ssh unterstützt lt. manpage Kompression nur in der Protokollversion 1, nicht
in 2.
Also ich verstehe die Manpage so, dass Komprimierung auch in Version 2
vorhanden ist, man nur keinen CompressionLevel mehr setzen kann. Aber
das tut nichts zur Sache, weil sowieso kein ssh verwendet wird und mir
das auch genau null beim Thema "wie fange ich ein TCP-Paket ab, schiebe
es an eine andere als die angegebene Ziel-IP weiter, und gebe dabei die
ursprüngliche Ziel-IP als Information mit" weiterhilft.
bzip2 kannst du in die netcat Übertragung einbauen.
Die Blocksize kannst du mit bzip2 -9 maximieren.
Alles bekannt, alles trivial, alles nicht das Problem.
Gruß
Stefan
Reply to: