Synapse: NAT

[af0815]

"Aktiver Part" hat mich auf eine Idee gebracht. Der Serverthread bekommt eine Liste mit und merkt sich dort die Kommunikation. Jeder Client fragt in regelmäßigen Abständen (z.B. 10s) nach, ob irgendwas zu tun ist. Dadurch ist ein Chat freilich etwas zäh, aber prinzipiell könnte das doch gehen.

Ist ein Denkansatz, wird aber daran nichts ändern, das der Server über einen konfigurierten NAT verfügen muß (oder halt kein NAT verwendet).

Es ist das gleiche Spiel, entweder die Clientseitig oder der Serverseitig muß was konfiguriert werden. Beim Server ist es meist einfacher, da es ja nur ein Rechner ist.

[Hitman]

STUN nützt hier relativ wenig, da das - wie alle NAT Tricksereien - nur für UDP funktioniert

Es hilft schon, damit man die 'externe' IP Adresse innerhalb des geNATteten Netzwerk sicher herausbekommt. Beim richtigen Konfigurieren hilfts dann weniger. Deshalb sollte der, der einen Server(-Prozess) betreibt schon ein wenig mit dem Router umgehen können (So wie die Spielefreaks).

Aber wozu braucht der Server seine eigene IP Adresse? Der Server lauscht doch einfach nur an seinen lokalen Ports ... ob die Verbindungen dort direkt eintreffen oder weitergeleitet wurden, ist herzlich egal. Der Client muss ebenfalls seine eigene Adresse nicht kennen, sondern nur die des Servers - und da hilft STUN ihm auch nicht weiter.

[Scotty]

Die IP-Adressen kann ich leicht raus bekommen und ggf. beim Verbinden übermitteln. Aber es stimmt, dass der Server ja noch nicht mal das listen/accept ausführen wird, wenn der Router die Anfrage nicht durch lässt. Dummerweise kann man das alles auch nicht so einfach ausprobieren, da lokal ja alles bestens klappt.

[af0815]

Aber wozu braucht der Server seine eigene IP Adresse? Der Server lauscht doch einfach nur an seinen lokalen Ports ... ob die Verbindungen dort direkt eintreffen oder weitergeleitet wurden, ist herzlich egal. Der Client muss ebenfalls seine eigene Adresse nicht kennen, sondern nur die des Servers - und da hilft STUN ihm auch nicht weiter.

Es geht darum, wenn ein Router dazwischen NAT (eigentlich PAT) macht, dann muß dieser Router auch wissen, wohin er den empfangenen Port schicken soll. Das geht bei einer von aussen initierten Verbindung nur dann wenn er den entsprechenden Eintrag in seiner NAT Tabelle findet. Dort ist hinterlegt wer für den Port im inneren (hinter dem Router) zuständig ist.
Dieses verhalten wird auch für einfache Firewalls verwendet. Denn ohne Eintrag in der NAT Tabelle kann auch ein Rechner dahinter nicht so leicht gefunden werden.

Beim Client ist es einfacher, da wird die Verbindung von 'innen' her initiert, somit hat der Router die Möglichkeit sich zu merken wer das gesendet hat (interne temporäre NAT Tabelle) und somit bei einem Antwortpaket dieses richtig zuzuweisen.

[Hitman]

Aber das kümmert den Server selbst nicht - das ist einzig und allein Angelegenheit des Routers. Nur bei nicht-persistenten Verbindungen (wie UDP) würde es eine Rolle spielen ... dort würde aber STUN ansich auch wieder funktionieren *g* (...und Sinn machen)

[Scotty]

Der Server sitzt derzeit auch hinter einem Router und ist deshalb von NAT/PAT abhängig. Ich werde wohl nicht um einen Application Service herum kommen oder weiter Lehrgänge zu NAT halten müssen

[Scotty]

Wäre es möglich, die IP-Adresse zu verändern oder macht das ausschließlich der Router? Ich kenne ja sowohl die lokale als auch die offene IP-Adresse des Spielers.

[af0815]

Wäre es möglich, die IP-Adresse zu verändern oder macht das ausschließlich der Router? Ich kenne ja sowohl die lokale als auch die offene IP-Adresse des Spielers.

Die externe wird vom Provider vorgegeben - meist dynamisch. Die interen kann man durch den Router vorgeben lassen (Stchwort DHCP) oder auch fix dem Rechner zuweisen.

Bei DHCP gibts 3 Möglichkeiten.
Aus = Adresse fix im Rechner einstellen
Ein = Adresse wird durch den Router im konfigurierten Bereich vergeben
Ein reserviert = Reservierte Adresse wird durch den Router im konfigurierten Bereich vergeben (erscheint wie aus, das der Rechner immer dieselbe Adresse hat)

[Scotty]

Ein TCP-Header bekommt vom Router die externe Adresse zugewiesen. Kommt ein Reply, ersetzt der Router diese externe Adresse wieder durch die interne. So hab ich das zumindest verstanden. Schön wäre es nun, wenn tatsächlich im TCP-Header beide Adressen enthalten wären. Dann hätte ich zwar Unrecht, wüsste aber eine Lösung

[af0815]

Ein TCP-Header bekommt vom Router die externe Adresse zugewiesen. Kommt ein Reply, ersetzt der Router diese externe Adresse wieder durch die interne. So hab ich das zumindest verstanden. Schön wäre es nun, wenn tatsächlich im TCP-Header beide Adressen enthalten wären.

Das richtige ersetzten ist einer der Aufgabe des Routers bei NAT. Dein Verständnis ist soweit richtig.

Beide Adressen spielt es nicht. Denn das ist im Protokoll nicht vorgesehen, wozu auch, es gibt ja NAT. Eine Lösung wo es inderekt zwei adressen gibt ist, wenn du mit Tunneling arbeitest (aber das ist eine andere Geschichte).