linux-l: IP-Nummer Wechsel ueberleben ?

[Steffen Dettmer]

* Jens Dreger wrote on Tue, Apr 10, 2001 at 10:43 +0200:
> On Tue, Apr 10, 2001 at 10:40:37AM +0200, Steffen Dettmer wrote:
> > Das kann man einfach mit PPP over SSH probieren. Ein SSH Connect,
> > der Streamverbindung wird ein Device zugeordnet, und dann pppd
> > darauf gestartet. Bei IP Änderung kracht die SSH zusammen, das
> > muß man dann entsprechend abfangen (und neuconnecten). Weiß aber
> > nicht, ob man auf ein "altes" device überhaup reconnecten kann,
> > oder da noch einen diald oder so einbauen muß.
> 
> Das habe ich nun leider nicht verstanden. Vor allem den Mittelteil. 
> Kannst Du nochmal auf das "das muß man dann entsprechend abfangen" 
> genauer eingehen ?

:) Muß man drüber nachdenken, meinte ich. Normalerweise läuft
pppd over ssh so: man connected via ssh, und legt ein tty drauf
(für den pppd), dazu gibt's ein kleines Tool (der Kram liegt
bestimmt irgentwo auf http://sws.dett.de/ --> search). Wenn die
SSH Verbindung stribt, ist auch das tty ungültig, klar. Damit
stirbt vermutlich der pppd sofort --> schlecht. Vermutlich bringt
es wenig, danach das gleiche tty neu zu connecten (weiß nicht,
wie tolerant pppd da ist). pppd kennt ein "connect"-Mechanismus,
das wäre ideal, nur leider muß _vor_ dem connect das Deivce schon
da sein. Bei der SSH Methode "entsteht" es aber es während des
connects. Ich glaube, connect geht hier also nicht (vielleicht
gibt's aber auch einen Trick. Hab da mal mit gespielt, aber zu
lange her, jetzt verwende ich nur noch IPSec. Sollte hier
übrigens auch funktionieren, aber das ist ein anderes Thema).
Deshlab die Idee mit dem Diald. Der steht vor pppd und kann
mehrere tty-Devices (mehrere Modems). Diald macht da irgentwie
eine Auswahl. Damit sollte es einen Weg geben, über diald einen
neuen pppd auf einem "neuen" tty zu starten, ohne das die
Verbindung abreißt und Packete verloren gehen. Das mit dem Diald
habe ich aber nie probiert. Damals hatte ich nur UDP, das hat
davon eh nix gemerkt, und es war immer die gleiche IP, also hatte
ich dieses Problem auch nicht.


Na, und mit IPSec (bei SuSE gibt's ein RPM, kann man also
"schnell mal probieren" - wenn man sich rudimentär mit IPSec
auskennt). Einfach mal FreeS/WAN anschmeißen, ist ne
Alternative...

> > Oder man baut irgendeine Art X-Proxy, der sowas kann. Auf beiden
> > Seiten läuft irgentsowas magisches, das mit IP Änderungen
> > klarkommt.
> 
> Ich glaube, genau nach diesem 'magischen' suche ich...

Bin mir jetzt nicht sicher, alles wilde Spekulation. Also. Man
baut einen Mini-Deamon (vie proxy.pl von meiner Homepage). Der
lauscht an lokalem Socket. Dieser wird als DISPLAY verwendet.
Wenn da was ankommt, connectet der Proxy zu einem zweiten,
remote-Proxy, der die Verbindung dann auf das lokale X-Display
forwarded (eben das, was SSH port forwarding nennt, bloß ganz
rudimentär). Der Proxy merkt, wenn die TCP Verbindung wegfliegt.
Da der andere Socket lokal ist, merkt der client davon erstmal
nix. Nu kann der Proxy nochmal connecten (wieder zu dem anderen
Proxy). Der ander Proxy muß merken, daß es die gleiche Verbindung
ist, und darf nicht neu lokal zum X-Server connecten, sondern muß
die Verbindung entsprechend zu ordnen. Die Proxies müssen
aufpassen, daß keine Daten doppelt kommen, oder fehlen, das ist
sicherlich ein Problem (wenn Socket in der Übertragung wegfliegt,
weiß man ja nicht, was übertragen wurde, kann aufwendig werden,
dieser Punkt, vielleicht noch ein eigenes Protokoll drüberlegen).
Vielleicht ist es aber auch gar nicht tötlich, wenn X Daten
doppelt kriegt (kann ich mir aber nicht vorstellen). 

Das "eigene Protokoll" kann man auch vom Kernel machen lassen.
Dann erzeugt z.B. der remote-Proxy echte TCP-Packete (die man
über einen Raw Socket zusammenbaut). Die IP-Absenderadresse wird
dabei eben geändert. Natürlich ist das aufwendig, weil man die
Antwortpackete via Raw-Socket abfangen und parsen muß, viel Spaß.
Das sollte aber ebenfalls funktionieren: man fängt einfach die
"falschen" IP Packete ab, leitet sich "manuell" weiter, und
sendet passende Antwortpackete via Raw-Socket (dabei muß man dann
auf Sequenznummern achten, und sich sehr gut mit TCP/IP auskennen
:) Ist sicherlich viel Bastelei).

Persönlich würde ich zuerst FreeS/WAN probieren, vermutlich der
schnellste und sicherste Weg zum Ziel. 

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.