Wenn man einen Server hinter NAT oder einer Firewall erreichen will, verwendet man üblicherweise einen reverse ssh-tunnel (ssh -R) oder gleich VPN. (eine Lösung durch Portforwarding soll ausgeschlossen sein) Was ist, wenn mich die sicherheit (SSL) gar nicht interessiert, und ich mir Rechenzeit und den ganzen SSL-Stack sparen will? für ssh gibt es ja die nicht-sichere Variante rsh bzw. rcp. Ich habe geschaut, ob man da einen "reverse tunnel" ohne ssl einrichten könnte, aber nichts gefunden. Vorschläge?
Gast
#5029433
L2tp oder pppoet
Du willst von außen rein, aber kein Portforwarding. Du willst also wahrscheinlich nicht jeden außen rein lassen sondern nur Leute die sich authentifizieren können. Aber du willst Nicht verschlüsseln, also alles, samt der Authentifizierung im klartext übertragen, sehe ich das Richtig?
Gast
#5029456
vtun ist sehr simpel und schnell. http://vtun.sourceforge.net/
Gast
#5029853
J. W. schrieb: > Wenn man einen Server hinter NAT oder einer Firewall erreichen will, > verwendet man üblicherweise einen reverse ssh-tunnel (ssh -R) oder > gleich VPN. (eine Lösung durch Portforwarding soll ausgeschlossen sein) Was bedeutet: Man erreicht nicht wirklich den Server. Der Server erreicht vielmehr den Client (der dadurch in gewissem Sinne natürlich auch zum Server wird). Das setzt natürlich voraus, dass der "Client", der bezüglich der Verbindungsaufnahme zum "Server" wird (besser wäre wohl der Begriff "Responder", wie er für VPNs in diesem Zshg. verwendet wird) seinerseits nicht hinter NAT/Firewall sitzt UND obendrein auffindbar ist, also im Minimum über DynDNS. > Was ist, wenn mich die sicherheit (SSL) gar nicht interessiert, und ich > mir Rechenzeit und den ganzen SSL-Stack sparen will? Dann bist du in erster Näherung ein Vollidiot. Damit exponierst du nämlich deinen Client vollkommen ungeschützt. Das geht (bestenfalls) dann gut, wenn er ausser dem für die Responder-Funktionalität nötigen Kram keinerlei Serverdienste anbietet. > Vorschläge? Laß es sein.
VPN-Endpunkt im Router. Das kann jede Fritzbox (Cisco-IPSec), Draytek oder Lancom ... und sicher noch ein Dutzend andere ...
J. W. schrieb: > (eine Lösung durch Portforwarding soll ausgeschlossen sein) > Was ist, wenn mich die sicherheit (SSL) gar nicht interessiert, und ich > mir Rechenzeit und den ganzen SSL-Stack sparen will? Dann ergibt das überhaupt keinen Sinn. "Port Forwarding" aka "exposed host" ist genau die Variante die man verwendet, um ein Gerät hinter einem NAT resp. einer Firewall nach außen sichtbar zu machen wenn man keinen Tunnel von innen nach außen aufbauen will.
> J. W. schrieb: >> (eine Lösung durch Portforwarding soll ausgeschlossen sein) Ich meinte: Ich kann nicht den Router konfigurieren und selber ports zum entsprechenden Gerät im lokalen Netz weiterleiten. Z.b. kann man in der Fritzbox Ports eingehender Verbindungen, z.B. 22, zu einem Gerät mit fester lokaler IP-Adresse (z.B. 192.168.178.50) weiterleiten. Dieser Gerät könnte sofort als SSH-Server arbeiten. Das geht in diesem Fall nicht. Ich kann den (nicht-privaten) Router nicht modifizieren.
Gast
#5032751
IPv6 Tunnel und darüber dann Telnet. Oder besser: Tinc/OpenVPN oder einen klassischen Reverse Tunnel, Verschlüsselung kann NIE schaden.
Gast
#5032755
Und ganz retarded: HTTP REST API nutzen, die automatisch in einem gewissen Intevall vom Client aufgerufen wird vom Server, damit kommt man durch fast jede Firewall, noch besser funktioniert ein DNS Tunnel. Aber wie gesagt, auf Verschlüsselung zu verzichten ist einfach nur gaga.
Harry schrieb: > Verschlüsselung kann NIE schaden. > Es geht um IoT mit möglichst sparsamen Prozessoren, Sicherheit spielt keine wesentliche Rolle. D.h. es geht nicht um Fernsteuerung eines AKW.
J. W. schrieb: > Harry schrieb: >> Verschlüsselung kann NIE schaden. >> > > Es geht um IoT mit möglichst sparsamen Prozessoren, > Sicherheit spielt keine wesentliche Rolle. Die Prozessoren sind tendenziell schon leistungsfähig genug. Also entweder spart man in der Entwicklung oder der Entwickler ist faul/inkompetent. Es gibt wenige, nahezu keine Grüne keine richtige Verschlüsselung ein zu bauen. Die Firmen sind eh schon unfähig Software Updates über die Lebensdauer der IoT Produkte an zu bieten (Samsung Kühlschränke?). Dann gleich mal alles unverschlüsselt zu machen ist nur eine verschlechterung. Hat man ein, ein einziges infiziertes Gerät im Netzwerk macht man es diesem unnötig leicht andere Geräte zu übernehmen. Dazu kommt das meiste IoT Zeug auf die Idee gleich mal ein loch via Upnp (falls es nicht abgeschaltet ist) in die firewall zu stanzen und übers Internet zu kommunizieren.
J. W. schrieb: > Es geht um IoT mit möglichst sparsamen Prozessoren, > Sicherheit spielt keine wesentliche Rolle. Ich seh das ja so: Wenn es dir komplett egal ist er wann was schaltet, dann spare dir den Aufwand und bau nen zufalls-schalter. Wenn dir das NICHT egal ist brauchst du Verschlüsselung.
Harry schrieb: > noch besser funktioniert ein DNS Tunnel. Nicht unbedingt. DNS wird gerne gefiltert.
Gast
#5034636
Was du möchtest ist IP über IP tunneln. Die Protokolle dafür heißen IP-in-IP oder GRE-Tunnel
J. W. schrieb: > Ich meinte: Ich kann nicht den Router konfigurieren und selber ports zum > entsprechenden Gerät im lokalen Netz weiterleiten. > > Z.b. kann man in der Fritzbox Ports eingehender Verbindungen, z.B. 22, > zu einem Gerät mit fester lokaler IP-Adresse (z.B. 192.168.178.50) > weiterleiten. Dieser Gerät könnte sofort als SSH-Server arbeiten. > Das geht in diesem Fall nicht. Ich kann den (nicht-privaten) Router > nicht modifizieren. Du willst an Euren Systemadministratoren vorbei und unter Umgehung Eurer Securitypolicy eine Verbindung von außen nach innen schaffen, richtig?