☰

Apache lauscht auf 80, aber nicht auf einem anderen Port

tag-icon • tag-icon ubuntu apache-2.2 iptables port-forwarding lsof
Apache lauscht auf 80, aber nicht auf einem anderen Port

ich wollte eine funktionierende Apache-Konfiguration von example.com (exampleIP = 1.2.3.4 ) ändern, um vom Standardport 80 auf Port 8001 zu wechseln, so dasshttp://example.com:8001sollte funktionieren. Mir ist es nicht gelungen und ich werde dokumentieren, was ich versucht habe. Ich glaube, ich brauche vielleicht Hilfe bei iptables.

meine /etc/hosts ist zunächst in Ordnung

1.2.3.4    example.com

Ich habe damit begonnen, den Port 80 an den folgenden Stellen durch 8001 zu ersetzen

  1. /etc/apache2/ports.conf

    Hören Sie 1.2.3.4:8001

  2. /etc/apache2/conf.d/virtual.conf

    NameVirtualHost 1.2.3.4:8001

  3. /etc/apache2/sites-enabled/example.com

    <VirtualHost 1.2.3.4:8001>

          ServerName example.com:8001
      #UPDATE: ServerName example.com doesn't make a difference either

    </VirtualHost>

Wenn ich in den obigen drei Fällen 8001 durch 80 ersetze, funktioniert es. Mit 8001 kann ich keine Verbindung herstellen. tcpdump zeigt auch keine eingehenden Anfragen an.

Da der Apache-Daemon beim Neustart keine Fehler ausgab, versuchte ich zu bestätigen, ob der Webserver auf 8001 lauschte

$ sudo lsof -i |grep 8001
apache2     731     root    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
apache2     734 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
apache2     736 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
apache2     737 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
apache2     738 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)
apache2     739 www-data    3u  IPv4 46858730       TCP example.com:8001 (LISTEN)

Es schien auf 8001 zu lauschen. Ich habe sogar versucht, die folgenden iptable-Regeln im Terminal anzuwenden:

$ sudo iptables -A INPUT -p tcp --dport 8001 -j ACCEPT
$ sudo iptables -A OUTPUT -p tcp --sport 8001 -j ACCEPT
$ sudo iptables -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied:  " --log-level 7

ich habe nie ein Denied-Log bekommen. Hier ist, was der ausführliche Modus von iptables zeigt

$ sudo iptables -L -v -n
Chain INPUT (policy ACCEPT 3052M packets, 785G bytes)
pkts bytes target     prot opt in     out     source               destination         
   25  1690 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8001 
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8001 
   92  6484 LOG        all  --  *      *       0.0.0.0/0            0.0.0.0/0           limit: avg 5/min burst 5 LOG flags 0 level 7 prefix `iptables denied:  ' 

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 4317M packets, 695G bytes)
 pkts bytes target     prot opt in     out     source               destination         
   20  1760 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp spt:8001

Ich bin mit den iptable-Regeln nicht vertraut, daher wären Hinweise zu den Regeln, die ich oben übersehen habe, sehr hilfreich. Beim Lesen anderer Threads habe ich mich auch gefragt, ob dies ein Grund sein könnte.

$ cat /proc/sys/net/ipv4/conf/eth0/forwarding 
0

Gibt es angesichts dieser Informationen Hinweise darauf, warum der Webserver auf 8001 nicht läuft, aber nicht auf 80?

UPDATE 1: Ich habe versucht, alle iptable-Regeln zu löschen

$ sudo iptables -X
$ sudo iptables -F

Ich habe auch versucht zu sehen, ob tcpdump etwas abfing

 sudo tcpdump -i eth0 port 8001 -v

Bei 8001 funktioniert das nicht, aber ändern Sie den Port auf 80 (noch einmal an den ^3 Stellen), und es funktioniert.

Ich habe versucht, nach etablierten und Hörprozessen zu suchen

$ netstat -an
tcp        0      1.2.3.4:8001            0.0.0.0:*               LISTEN

Zuletzt habe ich von meinem lokalen Rechner aus auch curl ausprobiert

curl http://1.2.3.4:8001 -v
* About to connect() to 1.2.3.4 port 8001 (#0)
*   Trying 1.2.3.4... No route to host
* couldn't connect to host
* Closing connection #0
curl: (7) couldn't connect to host

AKTUALISIERUNG 2

Darüber hinaus schien meine Datei /etc/log/messages, die iptables-Fehler abfängt, Folgendes auszuwerfen. Es stellte sich jedoch heraus, dass diese beim Aufrufen und Beenden von tcpdump auftreten.

Jan 22 09:30:31 node1 kernel: device eth0 entered promiscuous mode
Jan 22 09:30:31 node1 kernel: audit(1264152631.798:54): dev=eth0 prom=256 old_prom=0 auid=4294967295
Jan 22 09:30:33 node1 kernel: device eth0 left promiscuous mode

AKTUALISIERUNG 3 habe dies in den FAQs von tcpdump gefunden

...Dies kann daran liegen, dass die Schnittstelle, auf der Sie erfassen, an einen Switch angeschlossen ist. In einem Switched-Netzwerk wird Unicast-Verkehrzwischen zwei Ports wird nicht unbedingt angezeigtan anderen Ports – nur Broadcast- und Multicast-Verkehr wird an alle Ports gesendet …

...was bedeuten würde, dass wenn Sie einen 10Mb-Port abhören,du wirst nicht sehen eingehender Datenverkehr wird an einen 100-MB-Port gesendet und umgekehrt …

...Wenn Ihr Computer nicht an ein Switched Network oder einen Dual-Speed-Hub angeschlossen ist oder wenn er an ein Switched Network angeschlossen ist, der Port jedoch so eingerichtet ist, dass der gesamte Datenverkehr dorthin repliziert wird, liegt das Problem möglicherweise darin, dass die Netzwerkschnittstelle, auf der Sie Daten erfassen, unterstützt den "Promiscuous"-Modus nicht, oder weil Ihr Betriebssystem die Schnittstelle nicht in den Promiscuous-Modus versetzen kann ...

Um diesen besonderen Fall zusammenzufassen:

  • iptables wurden mit -F, -X geleert
  • Anfragen werden problemlos ausgeführt, wenn Apache bei 1.2.3.4:80 lauscht
  • tcpdump fängt nichts ab, wenn Apache bei 1.2.3.4:8001 lauscht (siehe UPDATE 1,3)

Antwort1

In Schritt 3 haben Sie erwähnt

/etc/apache2/sites-enabled/example.com

<VirtualHost 1.2.3.4:80>ServerName example.com:8001 ...</VirtualHost>

Das ist nicht richtig. Es sollte

<VirtualHost 1.2.3.4:8001>Servername beispiel.com ...</VirtualHost>

Antwort2

Wenn es Sie nicht stört, versuchen Sie die Bindung an eine beliebige Schnittstelle mit:

Listen 0.0.0.0:8001

Und der Servername sollte sein:

ServerName example.com

Den Rest belassen Sie so, wie Sie ihn bereits konfiguriert haben. Bitte beachten Sie, dass NameVirtualHost und VirtualHost die gleiche Signatur haben müssen. Und da es sich um einen namensbasierten virtuellen Host handelt, müssen Sie in Ihre Hosts-Datei auf dem Rechner mit dem Browser eine Zeile wie diese einfügen:

1.2.3.4 example.com

und Verwendung inhttp://example.com:8001/als URL im Browser (curl, wget, MSIE, Firefox)

Verwenden Sie zum Debuggen:

tshark -V -i eth0 port 8001 or port 80

Sehen Sie, was in error.log und in access.log passiert

Antwort3

Listen implementiert keine virtuellen Hosts. http://httpd.apache.org/docs/2.0/bind.html#virtualhost

Zu /etc/apache2/ports.conf hinzufügen, einfach Listen 8001

Stellen Sie sicher, dass der Include vor dem Include der virtuellen Hosts in der Datei apache2.conf steht. Sie können den Listen-Befehl auch direkt in die Datei apache2.conf einfügen, direkt vor den Include-Zeilen.

Prost

Antwort4

als ich die Leute vom Hosting kontaktierte, handelte es sich letztlich um ein Firewall-Problem.

Ich werde versuchen, sie dazu zu bringen, näher darauf einzugehen, was sie tatsächlich getan haben, um dies durchzusetzen.

war am Ende eine nette Übung für den Systemadministrator. Danke an alle ...

verwandte Informationen