ETS, IP-Router und DynDNS

[salixer]

Wenn der Kunde (aus welchem Grund auch immer) kein VPN will, bliebe noch die Möglichkeit einen SSH-Zugang (und das nach Möglichkeit auf einem Highport) zu schaffen und darüber zu tunneln...
Dann wäre wenigstens die Sicherheit gegeben...

Ein SSH-Tunnel kann von Haus aus leider nur TCP und kein UDP.

[ctr]

Ich vermute der Kunde will "auf Teufel komm raus" keine statische IP Adresse, deswegen eben DynDNS. Das ist durchaus legitim, hat aber mit der Art des Zugangs nicht unbedingt etwas zu tun.
Reines NAT (also übersetzen der Internet IP auf die IP der IP Schnittstelle) wäre auch in der reinen Duldung absolut fahrlässig. Wenn der Kunde das trotzdem will, hast Du ihm die Gefahren nicht richtig erklärt!
Selbst eine Filterung/Einschränkung auf Source-IP ist als Sicherheitsmaßnahme nicht zu empfehlen, da es sich um UDP Verkehr handelt und IP-Spoofing (fälschen der Absenderadresse) ohne weiteres möglich ist.

Es ist also auf jeden Fall eine "Art" VPN herzustellen, je nachdem was für Equipment lokal vorhanden ist entweder SSH, OpenVPN oder IPSec.
Über SSH bietet sich eine Verbindung per tun/tap an, über tap könnte man sogar Multicast-Traffic (also echtes KNX Routing) ziehen:
Multicast over SSH tunnel with TAP bridge « { radak.org }

[Norbe]

nun ja ich habe dem Kunden gar nichts erklärt, sondern ich arbeite im Auftrag des Crestron-Programmierers und der hat den direkten Kontakt.
Er hats auch schon versucht, aber ich halte mich da inzwischen raus, ich glaube, die haben das schon oft genug durchgekaut.
Mit VPN hätte ich ein Wiregate reingesetzt und der Fisch wäre gegessen gewesen, so muss ich jetzt halt mit den Vorgaben leben.
Aber trotzdem ist es eine interessante und lehrreiche Diskussion !

[makki]

Ein SSH-tunnel ist für mich nichts anderes als eine Spielart eines VPN's (was durchaus auch eine sichere Lösung sein kann!)

Das habe ich ja auch schon versucht zu sagen: VPN und statische IP haben weder etwas miteinander zu tun, noch schliesst das eine das andere aus, haben wir hundertfach..

Worum es hier IMHO im Kern geht, im sinne des Kunden!: harakiri vermeiden.

Ich leg jetzt mal den Finger in die Wunde: Welche Qualifikation zeichnet den Crestron-Menschen aus, Fernzugriff übers Internet gut, stabil&sicher machen und beurteilen zu können?
Dillentantismus oder Halbwissen ist kein Gesetz, das kann man angreifen
-> Ernsthaft: Schaff mir den zusammen mit dem Bauherrn ne viertelstunde ans Telefon, dann sehen wir wer welchen Layer des OSI Modells wie gut kennt und welche Risiken der Bauherr danach noch - ja ohne jegliche Not dazu - eingehen will..

Makki

[Norbe]

so jetzt muss ich nochmal nachhaken :

Muss eigentlich der IP-Router in den Parametern (bei IP Kommunikation) auf Unicast gestellt werden ? (da kommen dann tausend Warnhinweise von wegen Spezifikation) ??

[makki]

Nein.
- KNXnet/IP Routing ist per se Multicast (one->any)
- KNXnet/IP Tunneling ist Unicast (one->one)
- beides 3671/UDP

Der Rest bewegt sich im Bereich TCP/IP-Basics, da nehm ich morgen(heute) doch mal lieber den Telefonhöhrer in die Hand

Makki

[Norbe]

ich frage deswegen :

Erst gingen die Konfigurationstests alle schief, dann habe ich die dyndns-Adresse in Zahlenform eingetragen, dann funktionierte auch der Ping-Test.
Nur der Unicast-Test funktionierte nicht, somit stellte sich für mich die Frage, ob ich hier auf Unicast stellen müsste.
Es hat nämlich nicht funktioniert und keine Seite wusste genau, woran es lag.

Makki, ich möchte das zukünftig eh anders lösen, diesbezüglich hast du auch ne email bekommen.

Schläfst du eigentlich auch manchmal ?