Docker-Container -> Internet-Zugang sperren

[Benie]

Sobald das entsprechende DSM Update gemacht wird (Ich weiß nicht mehr genau welche das war- Rlease Notes lesen) steht der Containermanager auch im Paketzentrum zur verfügung. Vorher nicht. ggf. wird er auch gleich zum DSM Update dann mit installiert.

 

[Kachelkaiser]

Das Update auf 7.1.1

Je nach DS geht's weiter auf DSM 7.2.2. Welche hast du denn?

 

[ADB83]

Das Update auf DSM 7.2.2 ist nun auch vollzogen und es scheint auch alles notwendig noch zu funktionieren.
Wo wird denn nun das neue Netzwerk erstellt, damit ich dies anschliessend im Container auswählen kann?


Unter Systemsteuerung -> Netzwerk konnte ich kein Punkt finden, an dem ich ein neues Netzwerk erstellen könnte:

 

[geimist]

Container Manager ➜ Netzwerk ➜ Hinzufügen

 

[ADB83]

Container Manager ➜ Netzwerk ➜ Hinzufügen

Anhang anzeigen 102161

Manchmal hat man wirklich die "roten, runden Teils vom Garten" auf den Augen...
Danke! ;-)

Das Netzwerk konnte ich nun hinzufügen, doch als ich nach dem Zuweisen des Netzwerk zum Container auf dessen IP zugreifen wollte, war das WebInterface des Containers nicht erreichbar. Auch wenn ich die gelistete IP-Adresse unter "Allgemein" des Containers mit anschliessendem Port eingab, wollte es keine Verbindung aufbauen.

Ich muss es später nochmals testen. Ich muss jetzt noch einer "physischen" Weihnachtseinladung folgen...

 

[haydibe]

Das ist unerwartet. Ich stelle es nochmal kurz nach.

Update:
Bei mir funktioniert es wie es sein soll: der Container ist über den Published Port erreichbar, der Container selbst kann nicht raus.
Das Einige was mir hier einfallen würde: Firewall temporär deaktivieren und schauen, ob es dann geht.

 

[ADB83]

Danke fürs Testen.

Die Firewall wurde deaktiviert -> leider ohne Erfolg.
Welche IP steht denn bei dir im Register "Allgemein"? Bei mir steht eine 172.xx.x.x-IP-Adresse, obwohl bei mir das Standard-Netz ein 192.168.xxx.xxx ist.





Muss beim Erstellen des neuen Netzwerks "Automatisch" oder "Manuell" selektiert werden?

 

[haydibe]

Die Rückfrage nach der IP-Range irritiert mich. Die sollte bei einem Docker Bridge-Netzwerk irrelevant sein (außer für Syno Firewall-Freischaltungen).

Beim Anlegen des Netzwerks würde ich die ipv4 Konfiguration auf Automatisch lassen. Docker vergibt hier selbst Subnets.
Der Haken für "IP Masquerade deaktiveren" muss gesetzt sein, damit das Netzwerk keinen ausgehenden Traffic erlaubt.

Der Container muss so konfiguriert sein, dass er einen oder mehrere Container-Ports auf Host-Ports mapped. Dann greift man über nas-<Ip oder hostname>:<gemappter host port> (Protokoll davor nicht vergessen!) auf den Container zu.

 

[ADB83]

Leider hatte ich vergessen, den lokalen- sowie Container-Port beim Erstellen des Containers auszuwählen und habe deshalb nur mit dem Container-Port (IP NAS + ":" + Container-Port) gearbeitet.
Nun konnte ich wieder auf die Oberfläche vom Container zugreifen und der externe Streaming-Link von Go2RTC kann nicht mehr geladen werden.
Leider ist es so, dass nun auch im internen Netzwerk der Stream-Link nicht mehr erreichbar ist (Timeout). Kann es sein, dass go2RTC ohne Internet-Verbindung nicht funktioniert? Die NAS-Firewall habe ich temporär kurz deaktiviert...

 

[haydibe]

Mit deaktiviertem Masquerading kann der Container selbst keinen Traffic mehr nach außen initiieren. Er kann nur noch die Antworten auf die Anfragen auf dem gemappten Host-Port des Containers beantworten. Dann scheint deaktiviertes Masquerading mit Go2RTC keine passende Lösung zu sein.

 

[ADB83]

Mit "nach aussen" ist nun der Zugang zum Internet oder vom Container zu meinem internen LAN-Netzwerk gemeint?
Die CAM ist ja über einen rtsp-Stream-Link übers lokale Netzwerk erreichbar und benötigt keine direkte Verbindung ins Internet.

 

[haydibe]

vom Container zu meinem internen LAN-Netzwerk gemeint?

Genau das. Der Container ist isoliert und kann von sich aus keine Kommunikation mehr ins LAN (und damit auch nirgendwo anders hin) aufbauen. Er kann nur auf Anfragen vom gemappten Host-Port antworten.

Gerade bei Audio/Video Kommunikationsprotokollen ist es eher der Standard, dass die Anfrage vom Client sagt "Du erreichst mich für den Austausch der Mediendaten unter xyz" und der Prozess baut dann selbst die Verbindung auf. Genau das geht bei einem Container in einem Netzwerk mit deaktiviertem Masquerading nicht.

Sprich: mein Vorschlag ist nicht die Lösung für Dein Problem mit Go2RTC. Imho führt kein Weg an dem vorbei, was Tommes im ersten Abschnitt dieses Beitrags gepostet hast: https://www.synology-forum.de/threads/docker-container-internet-zugang-sperren.136817/#post-1215659.

 

[ADB83]

Genau das. Der Container ist isoliert und kann von sich aus keine Kommunikation mehr ins LAN (und damit auch nirgendwo anders hin) aufbauen. Er kann nur auf Anfragen vom gemappten Host-Port antworten.

Sehr schade...
Dass Video bzw. Bild-Material von einer Kamera das eigene interne Netzwerk verlässt ist meiner Meinung nach ein absolutes No-Go. Eigentlich sollte das Senden aller Daten vom Smarthome in Richtung Internet unterbunden werden.

Im Prinzip möchte ich "nur" die Video-Daten von Netzwerk-Kameras in der Visualisierung von IOBroker anzeigen und teilweise Standbilder per Pushover versenden. Der rtsp-Stream der Kamera kann anscheinend nicht direkt in der IOBroker-Vis eingebunden werden. Deshalb wollte ich als Zwischenlösung den Stream über go2RTC ins passende Format umwandeln.

Ich denke, die Lösung von Tommes wird meine Kenntnisse übersteigen und entsprechend im Nirvana enden.

Und zusätzlich noch einen Raspberry Pi zum Leben zu erwecken, damit ich diesen in der Fritzbox sperren kann? Darüber muss ich wohl nochmals schlafen...

Ich danke euch bereits einmal für eure Bemühungen. Falls euch weitere Ideen einfallen sollten, nehme ich dies natürlich gerne entgegen.

 

[geimist]

Bei go2rtc ist mir z.B. aufgefallen, dass hier ein externer Link erstellt werden kann, mit dem extern auf das Kamerabild zugegriffen werden kann.

Zu deiner einleitenden Frage:
Nur weil man einen Freigabelink erstellen kann, bedeutet das doch nicht, dass der Container von sich aus Daten sendet. Solch ein Link ist ja gerade für den externen Zugriff, also von außen nach innen. Und möchte man das nutzen, benötigt man zusätzlich eine Portfreigabe im Router und Firewall.
Ein selbstständiges Senden in die Cloud kenne ich eher von asiatischen IoT-Geräten als von OpenSource-Projekten.
Sollte das wirklich der Fall sein, hat man ja wie schon erwähnt, auch mit der FRITZ!Box-Kindersicherung die Möglichkeit, einzelne Domains oder IP-Adressen für das NAS zu sperren.

Kurz gesagt: Ich hätte hier keine Sorge.

 

[ADB83]

Kurz gesagt: Ich hätte hier keine Sorge.

Im Prinzip hast du vollkommen recht. Und doch weiss man nie genau, was trotzdem im Hintergrund alles versendet wird...