Server auf 2. PVC lauschen lassen?

[frank_m24]

Hallo,

inspiriert durch diesen Beitrag kam ich auf die Idee, einige Server Dienste auf der 2. PVC lauschen zu lassen. Wenn der Rechner gerade mal größere Downloads macht, können Fernzugriffe über SSH oder OpenVPN ganz schön zäh werden. In der 2. PVC schlummern dann aber einige 100 ungenutzt kBit/s, die für einen Zugang von außen schon reichen würden, man wäre auf jeden Fall flotter unterwegs, als sich in schnelle Downloads einreihen zu müssen.
Tja, nur wie? Ich kann die Adresse pingen, ich kann dyndns darauf einrichten, ich kann aber nicht SSH oder OpenVPN darauf erreichen. Kennt jemand eine Möglichkeit, die Server an die IP der 2. PVC zu binden? Oder ist die dem voipd vorbehalten?

 

[iphektor]

Hi,

kann zu dem SSH- bzw Telnet-Server auf der Fritte nicht viel sagen. Von OpenSSH weiß ich, dass man dem Daemon/Server über das Config-File sagen kann auf welcher IP-Adresse er lauschen soll. Dem kann man dann die IP-Adresse des 2. PVC geben. Unschön daran ist, dass sich diese Adresse ja ändert und man dann den SSHD neu starten müsste.

Als Defaulteinstellung wird die Host-Adresse 0.0.0.0 genommen was bedeutet, dass der Server auf allen Adressen lauscht, eigentlich sollte das ja Deine Funktion erfüllen.

Zunächst würde ich mal mit einem simplen tool wie netcat nachsehen ob das Routing der Fritte eine Verbindung darauf zulässt, wenn das tut dann kann man sich immer noch um den internen SSH-Server oder einen alternativen Server kümmern.

Bye Jo

 

[RalfFriedl]

Gibt es denn für die 2. PVC ein normales Linux-Interface oder nicht?
Wenn ja, bleibt nur die Frage, ob/wie man das in der AVM-Firewall freigeben kann.
Wenn nicht, ist es bestenfalls schwierig.

 

[stinkstiefel]

Gibt es denn für die 2. PVC ein normales Linux-Interface?

Nein, gibt es nicht!

 

[Chatty]

Eine zweite Zeile á la
ar7cfg { dslifaces { dsldpconfig { forwardrules = "tcp 0.0.0.0:443 0.0.0.0:443 1"
hilft leider auch nicht.

 

[cuma]

Ich tippe darauf, dass der Rückweg vom 2.pvc-interface ins Internet keine korrekte Route hat. Die Box sendet dann die Antwort über den nomalen Gateway. (bin nicht sicher ob iphektor das gemeint hat)

 

[RalfFriedl]

Wenn es erst gar nicht ein normales Linux-Interface für die 2. PVC gibt, dann kommen die Pakete vermutlich erst gar nicht beim Linux-Kernel an. Man könnte das noch mit tcpdump überprüfen.

 

[frank_m24]

Hallo,

so, heute Abend hatte ich noch mal ein bisschen Zeit, mich dieser Problematik zu widmen. Wahrscheinlich hatte ich im ersten Anlauf beim Thema Portweiterleitungen nicht richtig nachgedacht. Nun habe ich jedenfalls alle relevanten Portweiterleitungen auch in den Block voip_forwardrules eingetragen:

        voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060",
                            "tcp 0.0.0.0:5060 0.0.0.0:5060",
                            "tcp 0.0.0.0:22 0.0.0.0:22",
                            "udp 0.0.0.0:1194 0.0.0.0:1194",
                            "udp 0.0.0.0:7078+32 0.0.0.0:7078";

Ich dachte mir, die Ports, die da drin stehen, sind wahrscheinlich diejenigen, die auf der 2. PVC geöffnet werden. Schwupps noch schnell den dyndns Account eingerichtet und rumgespielt. Und jetzt wirds lustig:
OpenVPN funktioniert, SSH nicht. Einige Versuche mit vertauschten Portnummern förderte dann relativ schnell zutage, dass UDP Weiterleitungen auf der 2. PVC im System ankommen, TCP Weiterleitungen aber nicht. Man muss nichts an der OpenVPN Konfiguration besonders einstellen, die UDP Pakete der 2. PVC erreichen das System trotzdem. Ab sofort ist der OpenVPN Server auf beiden PVCs erreichbar. Ich habe es sowohl mit den dyndns Accounts als auch mit den IPs probiert. Umgekehrt ist dem SSH Server nur auf der 1. PVC, also der Internetverbindung, ein Lebenszeichen zu entlocken. Ein Portscan auf die jeweiligen TCP Weiterleitungen zeigt auch an, dass die Ports dicht sind. Die UDP Ports hingegen werden als offen angezeigt. Das alles habe ich wie gesagt mit mehreren Portnummern durchgespielt, um z.B. einen Einfluss der Portbereiche (z.B. alles kleiner 1024) auszuschließen.

Hat jemand von euch eine Erklärung? Oder gar eine Idee, wie man dem Konstrukt TCP beibringen könnte?