pato Die interne IP, sonst würde es nicht funktionieren
Äh doch, das würde selbstverständlich auch funktionieren. Es nennt sich dann DNAT (“Destination-NAT”). Guckst Du:
Szenario
- eigene WAN-IP:
5.5.5.5
- LAN-Netz:
192.168.1.0/24
- Router (Gateway im LAN):
192.168.1.1
- Server im LAN:
192.168.1.2 - sagen wir mal https Port 443
- Port-Forwading auf dem Router von WAN Port 443 zu intern 192.168.1.2:443
Nun kommt ein TCP-Connect aus dem Internet- im Beispiel von einem https-Client mit Internet-IP 4.4.4.4.
Der Client wählt dabei eine eigene, zufällige Portnummer (“Ephemeral port”) - sagen wir mal 4444
Die IP-Pakete haben dann folgenden Inhalt:
Durch Internet läuft und kommt so beim WAN-Port des Routers an:
SRC-IP 4.4.4.4 SRC-Port 4444 DST-IP 5.5.5.5 DST-Port 443
Jetzt kommt das “Port-Forwarding” des Router. Da das faktisch ein “D-NAT” ist wird die DST-IP des Pakets angepasst zu:
SRC-IP 4.4.4.4 SRC-Port 4444 DST-IP 192.168.1.2 DST-Port 443
Insgesamt sind jetzt drei und nicht nur zwei Paare “IP und Port” an der Verbindung beteiligt. Dieses Mapping merkt sich der Router. Dieses Mapping wird nach einem TCP-FIN oder TCP-RST (oder nach einem Timeout) wieder verworfen.
Da die DST-IP ins LAN-Netzwerk passt (sie passt ja zu 192.168.1.0/24) weiss der Router, dass das IP-Paket auf den LAN-Port zu schicken ist.
Auf dem LAN empfängt nun der https-Server dieses Paket und sieht dabei als SRC-IP nach wie vor die ursprüngliche des Clients im Internet.
Die Antwortpakete vom LAN-https-Server sehen dann so aus:
SRC-IP 192.168.1.2 SRC-Port 443 DST-IP 4.4.4.4 DST-Port 4444
es sind also schlicht SRC und DST vertauscht (also IP und Portnummer)
Da diese DST-IP nicht zum LAN gehört (sie passt eben nicht zu 192.168.1.0/24) bemüht der http-Server seine Routing-Tabelle. Im einfachen Szenario gibt es keine spezifische Routing-Rule für 4.4.4.4 und damit greift der sog. Default-Gateway - also der Router (der ja im LAN die IP 192.168.1.1 hat). Er schickt das IP-Paket folgerichig zum Router. Wichtig dabei: die DST-IP bleibt dennoch bei “4.4.4.4”. Das Paket wird einfach zu dem Gerät gesendet, dessen MAC-Adresse zu 192.168.1.1 gehört.
Das ist hier genau derselbe Entscheidungspfad wie bei einem Connect “vom LAN ins Internet”, also wenn Du in deinem PC im LAN eine Internet-Webseite aufrufst.
Der Router schaut in seine Mapping-Tabelle und findet tatsächlich einen EIntrag für diese 4er-Kombination. Da jetzt aber DST und SRC vertauscht sind wird er nun für diesen ‘Rückweg’ die SRC-IP ersetzen. Das IP-Paket wird zu:
SRC-IP 5.5.5.5 SRC-Port 443 DST-IP 4.4.4.4 DST-Port 4444
Nun sucht er den Ethernet-Port wohin er das Paket ausgeben soll. Die DST-IP passt nicht zum LAN. Vermutlich passt sie auch nicht zum WAN-Netz (denn das ist ja auch nur ein ‘kleines Netz’ des Providers und nicht das ganze Internet). Also wird ‘dein’ Router das zu ‘seinem’ Default-Gateway weiterschicken - der wird von deinem Provider betrieben.
Es macht prinzipell auch keinen Unterschied, ob der Router dabei ‘einzelne Port-Forwardings’ oder ‘einen ganzen Host aus dem LAN exponiert’. Die SRC-IP bliebt bei Nutzung von DNAT erhalten.
Alternativ zu DNAT könnte ein Router bei einem Port-Forwarding aber auch DNAT und SNAT (Source-NAT) kombinieren und im LAN dann tatsächlich die eigene IP (vielleicht zusammen mit einem anderen random-Port) im LAN-IP-Paket eintragen. Damit würde die SRC-IP gegenüber deinem https-Server im LAN versteckt/verschleiert (darum heisst diese Funktionalität in Linux-Kernel übrigens ‘Masquerading’).
Eine weitere Alternative wäre auch, auf dem Router einen TCP- oder gar http(s)-Proxy zu nutzen (z.B. HAProxy). Der Router wäre dann aber nicht nur Router - sondern eben Proxy. Da er dabei nicht nur IP-Ebene arbeitet sondern noch invasiver an TCP bzw. UDP-Paketen oder gar am http-Protokoll (ggfls. sogar an TLS) operieren muss bedingt das schnell eine deutlich stärkere. Darum dürfte das bei den billigen Massen-Consumer-Routern kaum zu Einsatz kommen.
Zurück zu meiner Frage: Was macht die Sunrise’sche Connect-Box denn nun genau von all diesen Optionen?
