Serverfunktionen hinter NAT erreichbar machen?

19/11/2008 - 00:37 von Michael Reichenbach | Report spam
Bei dyndns Providern erhàlt man einen stabilen Hostnamen der immer auf
die aktuelle (dynamische) IP auflößt.

Was kann man das machen, wenn man providerbedingt (UMTS) keine
Serverports öffnen kann (man kann sie schon öffnen, aber sie sind von
außerhalb nicht erreichbar) und trotzdem Serverdienste anbieten will die
von Außerhalb erreichbar sind?

Ich möchte vermeiden einen dritten Server zu mieten dessen Ports von
Außerhalb erreichbar sind und der dann den kompletten Traffic als Proxy
weiterleitet.

Kann man das eleganter lösen?

In etwa stelle ich mir das so vor... A bin ich, dynamische IP und keine
Serverports möglich, aber ausgehende Verbindungen funktionieren
natürlich (wie hinter einem nicht-konfigurierten Router mit NAT).

B ist ein "dyndns und Port Provider".

C ist jemand der z.B. auf Port 80 über einen bei dem Dyndns Hostnamen
eine Anfrage startet.

A meldet an B stets die aktuelle IP und welche Ports weiter geleitet
werden sollen.

A fragt über ausgehende Verbindungen regelmàßig bei B an ob neue
Anfragen vorliegen.

C startet eine Anfrage bei B, B antwortet "bitte warten", B wartet bis C
abfragt ob neue Anfragen vorliegen, B hilft A und C per TCP bzw. UDP
holepunching direkt miteinander zu kommunizieren.

Die ganze Idee ist noch etwas wage.

Am liebsten hàtte ich den ganzen Vorgang soweit herunter gebrochen das
man ganz normale Serverdienste dann nur an einem virtuellen Adapter
lauschen lassen muss und dann seine Serverdienste von Außerhalb
erreichbar hat.

Irgendwelche Vorschlàge? :)

-mr
 

Lesen sie die antworten

#1 Thomas Rachel
19/11/2008 - 14:10 | Warnen spam
Michael Reichenbach schrieb:

Ich möchte vermeiden einen dritten Server zu mieten dessen Ports von
Außerhalb erreichbar sind und der dann den kompletten Traffic als Proxy
weiterleitet.

Kann man das eleganter lösen?



Mir nix bekannt.


A meldet an B stets die aktuelle IP und welche Ports weiter geleitet
werden sollen.



Die aktuelle IP braucht er nicht.

Ich habe an verschiedenen Stellen was àhnliches laufen: eine
Tunnel-Lösung, die Ports weiterleitet.

Ok, wir sind hier in *.ms-windows.*, da kenn ich mich nicht so aus. Aber
meine Lösung arbeitet prinzipiell so:

A verbindet sich per SSH mit B und fragt ihn, ob er über die
freigegebenen Ports auf A kommt. Wenn ja, ist alles gut. Wenn nein,
teilt ihm B die eingestellte Portkonfiguration mit, die A dann
seinerseits über eine weitere SSH-Verbindung anfordert.

Damit gibt es auf B Ports, die über die bestehende, 2. SSH-Verbindung
auf A weitergeleitet werden. die A-Seite der 2. SSH-Verbindung tunnelt
diese Verbundungen dabei direkt auf den Zielport, so daß die
Zielanwendung (in meinem Fall: wiederum SSH) davon gar nix zu wissen
braucht.

So kann ich von außen auf B:6974 zugreifen und erreiche damit A:22.

Widerspricht natürlich Deiner Vorgabe "vermeiden, dritten Server zu
verwenden", aber andere Lösung kenne ich nicht.


HTH trotzdem,

Thomas

Ähnliche fragen