Zum Inhalt springen

Empfohlene Beiträge

Geschrieben

Holla,

ich nutze einen Internetzugang über einen Router (Speedport W 701V).

Im LAN habe ich auf einem Rechner Debian frisch installiert. Darauf läuft ein Web-Server und ein SSH Dämon. Ich kann beide über das LAN nutzen.

Jetzt möchte ich die Dienste auch aus dem Internet erreichen. Ich habe eine DynDNS Subdomain, die auch korrekt aufgelöst wird.

Im Router habe ich den Port 80 für den Webserver und den Port 22 für den SSH Dienst an die interne IP Adresse des Servers weitergeleitet (NAT Portregeln).

Leider kann ich bisher auf keinen der Dienste von außen zugreifen. Die Einstellungen zum Portforwarding im Router sind sehr einfach gehalten. Da kann man nicht so viel falsch machen. Außerdem hat das ganze schon mal funktioniert. Da lief auf dem Server allerdings eine alte SuSE Version.

Deshalb frage ich mich, ob das an dem Debian System liegt.

- Kann der Server unterscheiden ob von intern oder extern zugegriffen wird?

- Läuft da vielleicht eine Firewall oder ähnliches?

- Wo könnte das Problem sonst liegen?

Ich hoffe ihr könnt mir helfen, vielen Dank im Voraus.

Geschrieben

Hi,

von wo aus versuchst du den Zugriff?

Vom Lan nach draußen auf die WAN IP?

Wenn ja dann merkt das der Router und du würdest einen Loopback Route benötigen.

Ansonsten hast du die Möglichkeit ein Paket Trace zu machen?

mfg

andi

Geschrieben

Danke für deine Antwort.

Also tracert gibt als erstes die interne IP meines Routers aus. Die zweite Zeile zeigt die externe WAN IP, gekennzeichnet mit dem Namen des Internet Einewahl-Knotens oder so ähnlich. Also bloß zwei Stationen.

Ich teste zuerst immer die Verbindung vom internen LAN mit der externen URL.

Der Aufruf der Webseite, mit der URL hat ja von intern und extern schon einmal funktioniert, als ich ein anderes System auf dem Server hatte!

Allerdings hatte ich da auch schon Schwierigkeiten mit SSH. Ich konnte mich LAN intern und vom LAN über die URL verbinden, aber nicht von extern.

Selbst wenn hier ein Fehler in meiner Errinerung vorliegt:

Da mir die Seite meines Webservers auch von einem Webproxy nicht angezeigt werden kann, gehe ich davon aus, dass die Verbindung von externen Clients mit den Diensten des Servers nicht zu stande kommt. Oder Schlussfolgere ich falsch?

Geschrieben

Teste es im LAN, ohne ueber den Router zu gehen.

putty.exe -ssh lan-ip-des-Servers

Simuliere beim Webserver-Aufruf die DNS-Aufloesung durch Editieren der hosts-Datei.

z.B. myhost.dynalias.com 192.168.2.2

Dann kannst Du im Browser die URL im LAN ohne DNS-Aufloesung aufrufen, ohne ueber den Router zu gehen.

Wenn diese beiden genannten Tests funktionieren, dann liegts an Deiner Portweiterleitung und/oder an der DynDNS-Aktualisierung.

Letzteres kannst Du testen, indem Du Dich auf Deinen DynDNS-Dienst einloggst und die IP Deines angelegten Hosts mit Deiner aktuellen oeffentlichen IP vergleichst (z.B. auf Wie ist meine IP-Adresse? anzeigbar).

Geschrieben

Danke für deine Antowort.

Die LAN interne Verbindung funktionert. Wenn ich die hosts Datei entsprechend editiere funktioniert es auch. Die DynDNS Auflösung funktioniert ebenfalls und die IP ist aktuell. Ich sollte vielleicht noch anmerken, dass alle Stationen über den integrierten Swicht im Router verbunden sind.

Beim Router kann ich für die Portregeln folgende Angaben machen:

- Name der Regel

- externer Port

- interne IP

- interner Port

- Protokoll

Da kann man jetzt nicht so viel falsch machen und es hat ja auch schon mit selben Router und der selben Firmware funktioniert. Das ruft in mir folgende Frage hervor: Beantwortet der Linux Server nur Anfragen aus dem lokalen Netz?

Geschrieben

Ich habe mal kurz die Portregel umgestellt, auf die IP eines Access Points im LAN, der eine Web GUI hat. Dort funktioniert das Forwarding sofort. Ich gehe also davon aus, dass das Problem in diesem Fall tatsächlich beim Linux Server liegt. Ich werd den Server noch mal unter die Lupe nehmen und ggf. einen neuen Thread im Linux Forum öffnen. Oder soll dieser Thread lieber verschoben werden?

Geschrieben
[...]Das ruft in mir folgende Frage hervor: Beantwortet der Linux Server nur Anfragen aus dem lokalen Netz?
Hast du es denn von Port 22 auf den lokalen Port 22 des richtigen PC weitergeleitet?

Wird auf dem Linux-PC iptables genutzt oder eine sonstige Firewall?

Welches Protokoll hast du ausgewählt? UDP / TCP oder beides?

Was für eine Fehlermeldung gibt deine SSH-Client aus? Dass der Server nicht erreichbar ist bzw nicht antwortet, oder dass die Verbindung abgelehnt wurde?

Geschrieben

Ich leite für SSH den Port 22 nach 192.168.1.2:22 weiter und für den Webserver Port 80 nach 192.168.1.2:80. Mit der IP-Adresse kann ich LAN intern problemlos die Verbindung aufbauen. Protokoll ist jeweils TCP. Oder brauch ich für SSH noch UDP?

Ob Iptables läuft muss ich noch heraus finden. Ich kenn mich mit Linux noch nicht gut genug aus. ps -e gibt jedenfals keinen Eintrag "IPtables" oder "Netfilter" aus.

Ich verwende Putty als SSHClient. Putty gibt die Fehlermeldung "Network Error: Connection timed out" aus.

Ich muss dazu sagen, das ich Debian über das Internet installiert habe. Für Installation habe ich die IP 192.168.1.50 verwendet. Die steht jetzt noch in mindestens einer Konfigurationsdatei. Ich habe mit ifconfig auf 192.168.1.2 umgestellt. Allerdings wird nach einem Neustart wieder die ursprüngliche IP verwendet. Könnte das Problem damit zusammenhängen?

Geschrieben

iptables -L gibt jedenfalls folgendes aus:

Chain INPUT (policy ACCEPT)

target     prot opt source               destination


Chain FORWARD (policy ACCEPT)

target     prot opt source               destination


Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination

Ich weiß aber nicht ob die Regeln auch angewendet werden.

Geschrieben

Iptables hat keine Regeln definiert. Sonst würden die da auftauchen.

SSH sollte eigentlich nur über TCP Port 22 gehen. Zumindest die Initialisierung läuft darüber. Den hohen Port auf dem die Kommunikation dann stattfindet, handeln Client und Server dann selbständig miteinander aus.

Falls iptables, ohne Regeln definiert zu haben, aktiviert ist, weiss ich nicht, was es standardmässig macht. Also ob alles durchlassen, oder alles blocken. Ich tippe aber auf alles durchlassen - sonst kämst du ja von lokal auch nicht drauf.

Ich würde den nach aussen ansprechbaren Port aber an deiner Stelle auf einen anderen Port legen und einfach auf den internen Port 22 weiterleiten. So umgeht man nervige Wörterbuchattacken. Zusätzlich Zertifikate verwenden statt nur User-Passwort-Kombinationen.

Geschrieben

Danke für deine Antwort.

Falls iptables, ohne Regeln definiert zu haben, aktiviert ist, weiss ich nicht, was es standardmässig macht. Also ob alles durchlassen, oder alles blocken. Ich tippe aber auf alles durchlassen - sonst kämst du ja von lokal auch nicht drauf.

Das denke ich auch.

Ich würde den nach aussen ansprechbaren Port aber an deiner Stelle auf einen anderen Port legen und einfach auf den internen Port 22 weiterleiten. So umgeht man nervige Wörterbuchattacken. Zusätzlich Zertifikate verwenden statt nur User-Passwort-Kombinationen.

Richtig. Dazu gibt es auch ein Kapitel in der Debian Referenz.

Anleitung zum Absichern von Debian - Absichern von Diensten, die auf Ihrem System laufen

Ich werde mich jetzt mit den Netzwerkeinstellungen des Servers beschäftigen. Vielleicht komme ich da weiter.

Geschrieben

Es funktioniert jetzt.

Ich muss dazu sagen, das ich Debian über das Internet installiert habe. Für Installation habe ich die IP 192.168.1.50 verwendet. Die steht jetzt noch in mindestens einer Konfigurationsdatei. Ich habe mit ifconfig auf 192.168.1.2 umgestellt. Allerdings wird nach einem Neustart wieder die ursprüngliche IP verwendet. Könnte das Problem damit zusammenhängen?

Offensichlich hats daran gelegen. Ich habe die /etc/network/interfaces angepasst und jetzt läuft es!

Danke noch mal.

Dein Kommentar

Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung wiederherstellen

  Nur 75 Emojis sind erlaubt.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...