Warum funktioniert der Zugriff vom Heimnetzwerk - also einer "internen" IP - nicht ohne Weiteres über Dyndns + Portweiterleitung auf ein Gerät im gleichen Heimnetz? Diese Frage taucht öfter auf...
Dazu folgendes Beispiel: Von einem Smartphone (interne IP: 192.168.1.100) soll über den Dyndns Namen "mycamera.dyndns.org" (externe IP: 94.79.177.182) zugegriffen werden. Eine Weiterleitung für Port 80 zu einer IP-Kamera mit interner IP 192.168.1.110 ist auf dem Access-Router (interne IP: 192.168.1.1) eingerichtet.
Der Zugriff von 192.168.1.100 auf 94.79.177.182 löst im NAT des Access-Routers eine Portweiterleitung auf 192.168.1.110 aus. Dabei wird die ursprüngliche Ziel-IP (94.x.x.x) durch die interne IP-Adresse der Kamera ersetzt: also 94.79.177.182 durch 192.168.1.110. Die Quell-IP 192.168.1.100 wird dabei allerdings nicht verändert.
Deshalb schickt die IP-Kamera, auf deren IP-Adresse (192.168.1.110) die Weiterleitung zielt, ihre Antwort-Pakete nicht an den Router, sondern direkt an die Adresse 192.168.1.100 des Smartphone, da sich die Kamera im selben Netzwerk-Segment wie das Smartphone befindet. Der Access-Router, der für das NAT gesorgt hat, ist nicht mehr involviert.
Das Smartphone wiederum erwartet aber Antwortpakete von der externen IP-Adresse 94.79.177.182 und verwirft die vermeintlich falschen Antwortpakete von der internen IP-Adresse der Kamera (192.168.1.110).
So kann keine Kommunikation zwischen dem Smartphone und der IP-Kamera zustande kommen.
Um dieses Verhalten zu verändern, wäre es denkbar, dass ein DNS Server für internen Clients (hier: Smartphone) den (externen) DNS-Namen der Kamera zur internen IP der Kamera auflöst und für externe Clients zur externen IP-Adresse - also unterschiedliche Namensauflösung je nach Client-Typ (intern / extern).
Oder man besitzt einen Router, der via Quellen-NAT die Quell-IP aller an die Kamera adressierten Pakete mit der IP des Access-Routers ersetzt (im Beispiel 192.168.1.100 durch 192.168.1.1, Stichwort: HairPin-NAT). Dadurch wird die Kamera ihre Antwort-Pakete an den Access-Router schicken. Der kann schließlich das NAT wieder korrekt auflösen: Beim Quellen-NAT die Ziel-IP in den Antwortpaketen wieder von 192.168.1.1 in 192.168.1.100 ändern und danach beim Ziel-NAT wieder von 192.168.1.100 auf 94.79.177.182.
Der Nachteil des Quellen-NAT ist, dass das Zielgerät - hier die Kamera, könnte aber auch ein Webserver sein - die Anfragen nicht mehr nach Clients unterscheiden kann, da alle Anfragen vom Access-Router (im Beispiel 192.168.1.1) kommen.
Beides funktioniert mit den weit verbreiteten Routern von AVM, Asus, DLink oder TP-Link leider nicht. Dazu ist schon ein "dickeres" Router-Kaliber notwendig, z.B. von Mikrotik. Oder der Router unterstützt die Funktion "NAT Loopback".
Bei einem Mikrotik-Router muss zur Einrichtung eines HairPin-NAT folgende NAT-Regel eingefügt werden, wenn das LAN-Segment, für das das NAT-Loopback funktionieren soll, das IP-Subnetz 192.168.1.0/24 besitzt:
Dazu folgendes Beispiel: Von einem Smartphone (interne IP: 192.168.1.100) soll über den Dyndns Namen "mycamera.dyndns.org" (externe IP: 94.79.177.182) zugegriffen werden. Eine Weiterleitung für Port 80 zu einer IP-Kamera mit interner IP 192.168.1.110 ist auf dem Access-Router (interne IP: 192.168.1.1) eingerichtet.
Der Zugriff von 192.168.1.100 auf 94.79.177.182 löst im NAT des Access-Routers eine Portweiterleitung auf 192.168.1.110 aus. Dabei wird die ursprüngliche Ziel-IP (94.x.x.x) durch die interne IP-Adresse der Kamera ersetzt: also 94.79.177.182 durch 192.168.1.110. Die Quell-IP 192.168.1.100 wird dabei allerdings nicht verändert.
Deshalb schickt die IP-Kamera, auf deren IP-Adresse (192.168.1.110) die Weiterleitung zielt, ihre Antwort-Pakete nicht an den Router, sondern direkt an die Adresse 192.168.1.100 des Smartphone, da sich die Kamera im selben Netzwerk-Segment wie das Smartphone befindet. Der Access-Router, der für das NAT gesorgt hat, ist nicht mehr involviert.
Das Smartphone wiederum erwartet aber Antwortpakete von der externen IP-Adresse 94.79.177.182 und verwirft die vermeintlich falschen Antwortpakete von der internen IP-Adresse der Kamera (192.168.1.110).
So kann keine Kommunikation zwischen dem Smartphone und der IP-Kamera zustande kommen.
Um dieses Verhalten zu verändern, wäre es denkbar, dass ein DNS Server für internen Clients (hier: Smartphone) den (externen) DNS-Namen der Kamera zur internen IP der Kamera auflöst und für externe Clients zur externen IP-Adresse - also unterschiedliche Namensauflösung je nach Client-Typ (intern / extern).
Oder man besitzt einen Router, der via Quellen-NAT die Quell-IP aller an die Kamera adressierten Pakete mit der IP des Access-Routers ersetzt (im Beispiel 192.168.1.100 durch 192.168.1.1, Stichwort: HairPin-NAT). Dadurch wird die Kamera ihre Antwort-Pakete an den Access-Router schicken. Der kann schließlich das NAT wieder korrekt auflösen: Beim Quellen-NAT die Ziel-IP in den Antwortpaketen wieder von 192.168.1.1 in 192.168.1.100 ändern und danach beim Ziel-NAT wieder von 192.168.1.100 auf 94.79.177.182.
Der Nachteil des Quellen-NAT ist, dass das Zielgerät - hier die Kamera, könnte aber auch ein Webserver sein - die Anfragen nicht mehr nach Clients unterscheiden kann, da alle Anfragen vom Access-Router (im Beispiel 192.168.1.1) kommen.
Beides funktioniert mit den weit verbreiteten Routern von AVM, Asus, DLink oder TP-Link leider nicht. Dazu ist schon ein "dickeres" Router-Kaliber notwendig, z.B. von Mikrotik. Oder der Router unterstützt die Funktion "NAT Loopback".
Bei einem Mikrotik-Router muss zur Einrichtung eines HairPin-NAT folgende NAT-Regel eingefügt werden, wenn das LAN-Segment, für das das NAT-Loopback funktionieren soll, das IP-Subnetz 192.168.1.0/24 besitzt:
Code:
/ip firewall nat
add action=masquerade chain=srcnat comment="HairPin NAT" dst-address=192.168.1.0/24 src-address=192.168.1.0/24
Zuletzt bearbeitet: