Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenloses um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereiche, welche für Gäste verwehrt bleiben

USG Schnelleres VPN durch weniger/keine Sicherheit?

Status
Für weitere Antworten geschlossen.

mensa

Hacker
Registriert
5. Oktober 2010
Beiträge
361
Reaktionspunkte
35
Punkte
88
Hallo,

ich nutzee momentan ein Site-to-Site VPN mit jeweils einem USG 3P an beiden Standorten.
Der Upload an Standort 1 beträgt 50 Mbit. An Standort 2 kommen über VPN aber leider nur 25 bis 28 Mbit über Site-to-Site VPN an. Das ist vermutlich auf Grund der lahmen Hardware der kleinen USGs.
Mit einem Windows Client und L2TP kommen immerhin gut 45 Mbit an Standort 2 an.

Da mir in diesem Fall die Sicherheit egal wäre habe ich überlegt, ob evtl. ein reiner VPN Tunnel ohne Verschlüsselung / Sicherheit nicht deutlich schneller wäre.
Wisst ihr zufällig, ob das unterstützt wird? Aktuell ist eingetellt: SHA1, AES128, IKEv1. Gibt's da was schnelleres evtl. über Command Line?
 
Es ist ein Xoro 8100, der wäre schon auf Unicast konfiguriert. Das Problem ist, dass er auf die RTSP Anfragen immer seine private IP Adresse sendet. Habe das ja mit Port Forwarding getestet und dann mit Wireshark gesehen.
Wäre natürlich für Tipps dankbar, wie es dennoch übers Internet ohne VPN funktionieren könnte.
 
Alternativ zu VPN gibt es auch dafür andere Wege,
Zum Beispiel die Senderliste die man für VLC bereit stellt von Enigma2 Webif, einfach konvertieren mit IPTV Enigma2 (4097) Converter by SATmax
Danach "Suchen und Ersätzen"der IP mit der dyndns
 
Genau das habe ich auch gemacht, das funktioniert aber nicht, da der Sat>IP Server eben immer seine private IP sendet und somit beim entfernten VLC Client nichts mehr ankommt bzw. die Kommunikation einfach nicht funktioniert (das verpixelte ist immer die externeIP):

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!
 
Zuletzt bearbeitet von einem Moderator:
Irgendwas ist ja immer :smile:
Die Idee mit dem schlüssel losen VPN ist dann zumindest nicht schlecht, wenn man nicht die Geräte tauschen will...
 
Zuletzt bearbeitet:
So schlecht sieht das doch für eine direkte Verbindung ganz ohne VPN nicht aus. Es wird RTSP/RTP zur Steuerung/Übertragung verwendet.

Das läuft in etwa so ab:
  • Eine TCP-Verbindung rtsp://[server-IP]:554, über die der Client dem Server Kommandos übermittelt.
  • Ein UDP/RTP-Stream mit darin verpacktem Transportstream vom Server zur Client-IP oder den Client-Port (scheint die Portrange 52600...52700 zu sein, wenn ich mich nicht irre).
  • Ein UDP/RTCP-Stream für Zusatzdaten an die Client-IP oder den Client-Port+1 Port (also z.B. 52657, wenn vorher 52656 gewählt wurde???). Das ist aber nicht unbedingt notwendig, denke ich.
Da fehlt dir wahrscheinlich nur auf der Client-Seite das Portforwarding. Das eigentliche Problem wird sein, dass die Ports aus der Portrange von den Clients wahrscheinlich dynamisch gewählt werden (können). Kann man bei dem/den SAT>IP Client/s die für den RTP-Stream zu verwendenden Ports vielleicht statisch festlegen???
 
Ich könnte es als Client mit dem VLC Player testen, wüsste aber absolut nicht, wie man da "Client-Ports" festlegen sollte.
Im Endeffekt würd's mir aber eh nichts bringen, da ich als Client ja eine vu+ Uno 4K verwenden möchte und da kann man als Sat>IP Client lediglich die Server IP festlegen, sonst nichts.
 
Mein Gott, als Client einen Vu+ Receiver und auf der Gegenseite keinen Vu+ Receiver, der die Programmstreams problemloser als ein SAT>IP Server liefern könnte. Ich verstehe die Welt nicht mehr.

Hab mir mal die Dokumentation zum Xoro 8100 SAT>IP Server angesehen. Das ist wohl der schlechteste SAT>IP Server, den man kaufen kann. Dagegen ist ein Digibit R1 ja ein Wunderwerk der SAT>IP Server. Hatte mich mal mit dem beschäftigt, um eventuell Sat-Empfang vom Nachbarn über eine knapp 1000m WLAN-Bridge realisieren zu können. Für die Digibit R1 gibt es auch Alternative Firmwares.

Ich glaube, weiß es aber nicht genau (weil nie gebraucht), dass Lancom-Router VPN/L2TP Verbindungen können. Hab noch zwei ausgemusterte Lancom 1611+ hier, geb die gerne zum Experimentieren ab.
 
Danke für die Tipps.
Also am Besten wäre auf der anderen Seite einfach auch einen Vu+ Receiver hinzustellen und dann über den 8100er Port zu streamen?
Wenn das besser funktioniert, könnte ich den Xoro 8100 eh noch zurückgeben. Aber aus welchem Grund würde das besser funktionieren denkst du? Hat der Stream zwischen 2 Enigma2 Boxen eine andere Technik / anderen Codec / Fehlerkorrektur als Sat>IP?

Sat>IP wäre ja eigentlich ein Standard, oder? Deshalb verstehe ich nicht wirklich, dass es Unterschiede gibt.
Was mich aber auch stark wundert ist, dass dieser Digibit Sat>IP Server deutlich schlechter (extreme Klötzchenbildung und mehr Aussetzer) funktioniert hat als der Xoro 8100: Telestar Digibit Twin Satelliten-IP Netzwerk Transmitter (HDTV, 2 SAT Eingänge, 1 LAN Ausgang) silber: Amazon.de: Heimkino, TV & Video
War jetzt natürlich nicht der Digibit R1, aber vermutlich ziemlich ähnlich, nur halt mit nur 2 Eingängen.
Ich dachte Sat>IP wäre eigentlich komplett standardisiert, deshalb wundert es mich auch, dass es hier überhaupt Unterschiede gibt.
 
Zuletzt bearbeitet:
Nein, andersherum. Den zusätzlichen Vu+ Receiver ohne Sat>IP Server direkt verwenden und den dann die Programmstreams über RemoteChannelStreamConverter dem entfernten Receiver zukommenzulassen. Ob das auch geht, wenn der zusätzliche Vu+ seine Sat-Programme vom SAT>IP Server übers lokale LAN bezieht, weiß ich nicht und da die Receiver auch nur einen LAN-Port haben, könnte das schon problematisch werden, wenn es möglich wäre. Da muss ja über den einen LAN-Port des Receivers erst das SAT>IP reinkommen und dann wieder zur Weiterleitung wieder ausgesandt werden (nicht mehr als SAT>IP, sondern als TCP TS).

Ja SAT>IP ist standardisiert und die genutzten Protokolle eben für ein lokales LAN gut geeignet, aber nicht über Internet-Router!!!
 
Zuletzt bearbeitet:
Ja, also so hätte ich ja gemeint:
- Sat>IP Server zurückgeben und dafür einen zweiten vu+ Receiver kaufen
- Standort 1 (wo eine Sat-Schüssel vorhanden ist): Sat-Kabel vom LNB an einen vu+ "Server" Receiver anschließen
- Port 8100 Forwarding auf vu+ "Server" Receivver
- Standort 2: vu+ "Client" Receiver mittels RemoteChannelsStreamConverter auf vu+ Server Box zugreifen lassen

So werde ich es in den nächsten Tagen eh probieren. Aber ich frage mich halt noch, warum das besser funktionieren soll, als wie mit einem Sat>IP Server.
Hat der Stream zwischen 2 Enigma2 Boxen eine andere Technik / anderen Codec / Fehlerkorrektur als Sat>IP?
 
SAT>IP basiert auf RTSP/RTP-Protokoll mit (teilweise) dynamischen Portzuweisungen und Enigma2-Receiver nutzen stattdessen einfaches TCP-Protokoll mit festen Portzuweisungen. Das ist der Unterschied.
 
Danke für die Info.
Sollte es bei Enigma2 Receivern dann eigentlich zu keinen Ausfällen/Rucklern oder Klötzchenbildung, wenn TCP verwendet wird? Also werden nicht empfangen Pakete erneut gesendet, oder wie?
 
Wenn die Leitung es nicht her gibt, sprich das Bild/Video Datenrate nicht übertragen werden kann, weil die Bandbreite fehlt, dann kannst du auch mit einen E2 Reciver die Ausfällen/Rucklern oder Klötzchenbildung haben.
 
Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!
Hier wird der Unterschied beschrieben. Beim Receiver hast du eine feste Portzuweisung anstatt einer dynamischen Zuweisung. Die feste Zuweisung eines Port würde dir helfen beim forwarding und NATen am Router, wenn es von außerhalb deines Privaten Netzes erreichbar sein soll.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben