Fernwartung und IP Adressen

[Robert L. (manateemoo)]

Hallo

Ich mochte von einem zentralen Rechner aus viele (z.B. 500) unserer 
Endgeräte warten und steuern. Da die Engeräte über grosse Distanzen 
verteilt sind ist eine Verbindung über das Internet am sinnvollsten.
Ganz Grob hab ich es mir so vorgestellt:
- Die Endgeräte erhalten eine Ethernet Schnittstelle und einen TCP/IP 
Stack.
- Die Endgeräte kommen über DSL Modems oder Fernsehkabel Modems in 
Internet.
- Auf dem Rechner lassen wir eine eigene Applikation laufen welche:
   o Status Informationen der Endgeräte abruft.
   o Alarme von den Endgeräten entgegen nimmt
   o Manuelle Befehle an die Geräte sendet.
   o Firmware Updates ermöglicht.

Wenn alle statische IP Adressen haben würden, könnte man auf dem Rechner 
sowie auf den Endgeräten einen Port als Server laufen lassen. Somit 
können beide PC und Endgeräte Clients sein und eine Verbindung aufbauen.

Da aber kaum ein Kunde 500 statische IP Adressen zu Verfügung hat wird 
das wohl nicht gehen.

Wenn nur der PC eine feste IP hat, müssen die Endgeräte die Verbindung 
aufbauen. Was aber beim Senden von Befehlen vom PC and die Endgeräte 
problematisch ist, ausser es sind alle Endgeräte dauernd verbunden. Was 
wiederum bedeutet, dass der Rechner 500 clients „gleichzeitig“ bedienen 
muss!? Wenn die Endgeräte nach übertragen der Daten die Verbindung 
wieder kappen  können Befehle vom Rechner zu den Endgeräten erst dann 
gesendet werden wenn diese wieder eine Verbindung aufbauen.

Mache ich irgendwelche Denkfehler? Ich nehme an diese Problematik ist 
nicht neu. Es gibt sicherlich erprobte Strategien um dies zu lösen. Ich 
wäre für hinweise sehr dankbar.

[Condi (Gast)]

Ja gibt es, aber das sind zu wenige Informationen. Was sind das für 
Clients?

[(prx) A. K. (prx)]

dyndns

[gast (Gast)]

ist im budget evtl. noch platz für ein kleines embedded linux?
damit ließen sich die meisten probleme erschlagen:
- das emb-sys sammelt die daten im lokalen netz und gibt sie als block 
an den server weiter.
- für verbindungen von außen gibt es einen ansprechpartner, der dann die 
daten im lokalen netz weiterverteilt.

ergibt eine (höchstwahrscheinlich) brauchbare schichtenarchitektur

[Frag Billi (Gast)]

Das ist noch "etwas" Wissen + Aufwand nötig, bis der optimale Zustand 
erreicht ist.

Die Clients könnten sich über eine getunnelte Verbindung an einen Server 
anmelden, den Du im Netz hinter einem Firewall betreibst.

[Christian M. (rabbit)]

eine übliche vorgangsweise bei ähnlichen setups ist es, daß sich die 
clients beim server regelmäßig melden und der sich die aktuellen 
IP-adressen der clients merkt; wenn er dann was zu senden hat, sendet 
er's halt dorthin, wenn dann kein ACK kommt, muß man warten, bis sich 
der client erneut meldet.

wenn aber (was bei DSL wahrscheinlich ist) noch ein router dazwischen 
ist, mußt du dort entweder die entsprechenden ports von außen auf dein 
device weiterleiten oder die kommunikation vom client aus initiieren; 
man könnt den client zb einfach per UDP alle 10 sekunden (oder, je nach 
anforderung seltener) beim server anfragen lassen, ob's was zu tun gibt. 
der server kann daran auch recht zeitnah sehen, wenn ein client nimmer 
erreichbar ist, und performance-mäßig wird das den server auch nicht in 
die knie zwingen.

wenn das ganze übers Internet passiert, sollt man natürlich die clients 
authentisieren, die daten je nach vertraulichkeitsanforderungen 
verschlüsseln und dafür sorgen, daß der code recht robust ist...

cm.

[Peter (Gast)]

du kannst ja davon ausgehen, das sich die IP nicht ständig ändern 
(normaler weise nur nach 24 stunden). Wenn jetzt jeder client 
regelmässig eine verbindung zum Server aufbaut (z.b. 1 mal die Stunde) 
dann kannst du dir ja einfach die IP merken. Wenn du jetzt mit dem 
client reden musst nimmst du einfach die Letzte bekannte IP.

Das setzt aber vorraus, das in dem Router der den client mit dem 
Internet verbindet eine Portforwarding eingetragen wird, sonst kommst du 
eh nicht von aussen drauf.

[Peter (Gast)]

> wenn das ganze übers Internet passiert, sollt man natürlich die clients
> authentisieren, die daten je nach vertraulichkeitsanforderungen
> verschlüsseln und dafür sorgen, daß der code recht robust ist...
man kann es auch recht einfach und ausreichend sicher machen. Wenn der 
Server eine Feste IP hat, dann wird einfach ein Packetfilter 
eingerichtet der nur verbindungen mit dieser zulässt.

[Klaus W. (mfgkw)]

Ich würde vorschlagen, daß einfach alle Rechner in einem lokalen
Netz hängen.
Den Rest macht ein VPN; damit sind auch gleich Probleme wie
Authentifizierung, Abhören, Manipulieren etc. erschlagen.