Ich entschuldige mich im Voraus, wenn ich technische Begriffe falsch verwende. Ich bin noch ein Neuling in Sachen Linux/Netzwerke.
Ich versuche seit über einer Woche, dieses Problem zu lösen, und keine der entsprechenden Fragen anderer hat mir geholfen. Ich habe vor kurzem einen auf Apache2 laufenden Webserver gebaut, um meine eigene Website zu hosten. Ich wollte ihn auch für SSH, FTP und VNC verwenden. Ich habe bei GoDaddy eine Domäne registriert, cokongwu.com. Für den Server wurde eine statische IP (192.168.0.105) eingerichtet, und ich habe auch eine Portweiterleitung für die Ports 80, 21, 23, 53 und 443 zur statischen IP eingerichtet. Als ich die Anleitungen zum Einrichten eines öffentlich zugänglichen Webservers las, dachte ich, das wäre alles, was nötig ist, da es zunächst perfekt funktionierte. Aber natürlich stellte ich fest, dass ich keine Verbindung herstellen konnte, als ich versuchte, außerhalb des Netzwerks mit dem Domänennamen auf den Webserver zuzugreifen. Nach etwas weiterer Suche fand ich heraus, dass ich meinen A-Eintrag in meiner Zonendatei bei GoDaddy in meine öffentliche IP ändern musste. Nachdem ich das getan hatte, stellte ich fest, dass ich überhaupt keine Verbindung mehr zu meinem Webserver herstellen konnte, weder innerhalb des Netzwerks, wo ich stattdessen auf die Router-Seite umgeleitet wurde, noch außerhalb des Netzwerks, wo die Verbindung einfach ablief. Später fand ich heraus, dass ich, da meine öffentliche IP nicht auf statisch eingestellt werden konnte, einen Dienst verwenden musste, nämlich Dyndns, damit die IP bei Änderungen ständig aktualisiert werden konnte. Ich richtete den Dyndns-Updater vom Software-Update-Center ein und richtete mein Dyndns-Konto cokongwu.com mit einem A-Eintrag ein, der auf meine öffentliche IP verweist, und einem Alias www.cokongwu.com, der auf cokongwu.com verweist. Ich richtete außerdem einen Hostnamen ein, cokongwu.dyndns.org, der auch auf meine öffentliche IP verweist, und fügte die Dyndns-Nameserver zu den Nameservern von Godaddy hinzu. Der A-Eintrag, den ich für cokongwu.com bei GoDaddy habe, verweist immer noch auf meine interne IP und die CName-Einträge (www und cokongwu.com) verweisen beide auf cokongwu.dyndns.org. (Da ich jedoch die Nameserver von GoDaddy durch Dyndns-Nameserver ersetzt habe, kann ich die Zonendatei für die Domäne nicht mehr verwalten.)
Nach all dem verursacht der Versuch, auf hostname.com zuzugreifen, immer noch dieselben Probleme wie zuvor. Der Zugriff darauf verweist auf meine öffentliche IP statt auf meine interne IP, aber innerhalb des Netzwerks werde ich einfach auf die Einstellungsseite meines Routers weitergeleitet und außerhalb des Netzwerks tritt einfach eine Zeitüberschreitung auf. Ich habe keine Ideen mehr, wie ich das beheben kann, also sind alle Ideen willkommen. Sollte sie (die öffentliche IP) nicht auf meine interne IP umgeleitet werden?
Entschuldigen Sie nochmals, falls ich diese Fachbegriffe falsch verwende, ich bin in dieser ganzen Sache noch ein ganz neuer Mensch.
Ich weiß, dass es viele Fragen zu diesem Posten bestimmter Befehle gibt, deshalb werde ich es auch so machen:
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.1:5556 0.0.0.0:* LISTEN 3387/dyn_updater
tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 2729/vino-server
tcp6 0 0 :::80 :::* LISTEN -
tcp6 0 0 :::21 :::* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 ::1:631 :::* LISTEN -
tcp6 0 0 :::5800 :::* LISTEN 2729/vino-server
tcp6 0 0 :::5900 :::* LISTEN 2729/vino-server
udp 0 0 0.0.0.0:5353 0.0.0.0:* -
udp 0 0 127.0.1.1:53 0.0.0.0:* -
udp 0 0 0.0.0.0:39124 0.0.0.0:* -
udp 0 0 0.0.0.0:631 0.0.0.0:* -
udp6 0 0 :::5353 :::* -
udp6 0 0 :::53973 :::* -
ufw:
sudo ufw status
[sudo] password for fender:
Status: inactive
000-default.conf:
<VirtualHost *:80>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
ServerName cokongwu.com
ServerAlias www.cokongwu.com
ServerAdmin webmaster@localhost
DocumentRoot /var/www/html
# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined
# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>
# vim: syntax=apache ts=4 sw=4 sts=4 sr noet
Antwort1
So wie ich es verstehe, haben Sie folgende Probleme:
1 - Kein Zugriff auf den Webserver (mit dem FQDN, „vollqualifizierter Domänenname“ www.cokongwu.com) voninnendas LAN?
2 - Sie können die Funktionalität der Website nicht vomdraußen?
1 – Zugriff auf den Webserver von innen mittels FQDN.
Ich kann Ihrer Frage nicht entnehmen, von wo aus Sie versuchen, auf den Webserver zuzugreifen, daher nehme ich an, dass dies von einem separaten Client innerhalb des LAN aus geschieht.
Da Sie höchstwahrscheinlich einen externen DNS-Server verwenden, wird Ihre Anfrage für www.cokongwu.com die öffentlich verfügbare IP-Nummer auflösen, also die außerhalb Ihres Internet-Routers (siehe unten). Da dieser Router den Verkehr nicht weiterleitet,zur externen IP-Nummervon innenzurück nach innen, wird der Verkehr an dieser Stelle angehalten.
Damit die Dinge funktioniereninnenIm Netzwerk muss www.cokongwu.com als IhrinternIP-Nummer (192.168.0.105). Sie können versuchen, den Webserver über die interne IP-Nummer zu durchsuchen. Da Sie jedoch SSL verwenden möchten, müssen Sie letztendlich über den FQDN auf den Webserver zugreifen, da Sie sonst Zertifikatsfehler erhalten.
Der „harte Weg“, die interne Namensauflösung zu reparieren, besteht darin, einen internen DNS-Server einzurichten, aber die oben genannten Schritte funktionieren bei der Fehlerbehebung und bei kleinen Bereitstellungen. Sie scheinen kein Neuling bei Google zu sein, und wenn Sie einen internen DNS-Server einrichten möchten, gibt es im Internet viele Anleitungen dazu.
Sobald Sie durch die interne Namensauflösung die interne IP-Adresse erhalten, erhalten Sie beim Surfen zum Webserver dieselbe Antwort, als ob Sie ein von außen kommender Client wären.
2 - externer Zugriff auf den Webserver.
Die Auflösung von www.cokongwu.com dig www.cokongwu.com +noall +answerergab die folgende Antwort.
www.cokongwu.com. 0 IN CNAME cokongwu.com.
cokongwu.com. 59 IN A 69.171.137.28
Dies zeigt, dass diewwwHost ist ein CNAME (Alias), der aufwww.cokongwu.com Das ist ein A-Eintrag. Durchführen einer umgekehrten Suche nach69.171.137.28mit dig -x 69.171.137.28 +shortergibt:
dsl-69-171-137-28.acanac.net
Dies sieht nach einem dynamischen Host aus. Wenn das DynDNS-Update funktioniert, sollte dies Ihre aktuelle öffentliche IP-Adresse sein. Überprüfen Sie dies mit dem folgenden Befehl in einer Befehlszeile:
curl -s checkip.dyndns.org | sed -e 's/.*Current IP Address: //' -e 's/<.*$//'
(schamlos gestohlen vonHier) Oder indem Sie zuwww.whatismyip.com
Vorausgesetzt, dies ist Ihr aktueller Standort, navigieren Sie zuwww.cokongwu.comsollte von außen klappen...
Ich habe das versucht, aber es hat nicht funktioniert. Das kann Folgendes oder eine Kombination davon bedeuten:
A - Der DynDNS-Dienst hat Ihre IP-Adresse nicht aktualisiert
B - Die Weiterleitung in Ihrem externen Router funktioniert nicht
C - Der Webserver antwortet nicht
Ein kurzer Test mit telnet <ip number> <port number>liefert keine Antwort von einer der oben aufgeführten Portnummern. Das lässt mich annehmen, dass der Grund A oder B sein sollte. Wenn es B ist, könnte es sein, dass Sie die Portweiterleitung nicht richtig durchgeführt haben oder, wenn Sie einen Router in Verbindung mit Ihrem Modem verwenden, das Modem nicht richtig mit dem Router verbunden haben, damit es alle Portweiterleitungsanforderungen verarbeiten kann.
Einige weitere Gedanken
Ich stelle fest, dass Sie erwähnt habenHafen 53als einer der an den Webserver weitergeleiteten Ports.Anschluss 53 UDPist der Standard für eingehendeDNS-Anfragen. Sofern Sie nicht tatsächlich einDNS ServerWenn dieser Port auf dem Webserver ausgeführt wird, können Sie ihn bedenkenlos schließen, da er ohnehin keinem Zweck dient.
Mir ist auch aufgefallen, dass Sie die Verwendung von SSH und FTP erwähnen, aber Port 21 und 23 in der Firewall geöffnet und an den Webserver weitergeleitet haben. Port 23 ist derTelnetPort und Port 21 ist derFTP-Port. Ich rate dringend davon ab, einen dieser Dienste zu verwenden, da es sich bei beiden um unsichere Protokolle handelt, dieallesim Klartext, einschließlich Benutzernamen und Passwörtern.
Ich empfehle nur das Öffnen und WeiterleitenAnschluss 22in der Firewall.Anschluss 22wird verwendet vonssh, der verschlüsselte Ersatz für Telnet.Anschluss 22wird auch verwendet von derscpService, der dieSSH-Dienstfür die Dateiübertragung.sshUndscpanstelle von Telnet und FTP wird Ihren gesamten Datenverkehr zum und vom Webserver sicher halten.
Eine weitere Empfehlung wäre, einen anderen Port für eingehende SSH-Verbindungen zu verwenden, vorzugsweise eine Portnummer über 1000, wie Port 1522 (nur ein Beispiel). Dies soll verhindern, dass der eingehende SSH-Dienst von externen Port-Scans entdeckt wird. Ändern Sie einfach den eingehenden Port von 22 auf eine höhere Portnummer (z. B. 1522), aber leiten Sie ihn weiterhin weiter anAnschluss 22auf dem Webserver. Greifen Sie dann von außen über die hohe Portnummer (1522) und von innen über Port 22 auf den SSH-Server zu.
Ich hoffe, das hilft Ihnen weiter und löst Ihr Problem =)