apache слушает 80, но не любой другой порт

Я хотел изменить рабочую конфигурацию apache example.com (exampleIP = 1.2.3.4), чтобы изменить порт 80 по умолчанию на порт 8001, чтобы http://example.com:8001 должно сработать. Я не смог этого сделать и буду документировать свои попытки. Думаю, мне может понадобиться помощь по iptables.

мой / etc / hosts во-первых в порядке

1.2.3.4    example.com

Я начал с замены порта 80 на 8001 в следующих местах

1. /etc/apache2/ports.conf

   Слушай 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>

Когда я заменяю 8001 в трех вышеуказанных случаях на 80, он работает. с 8001 я не могу установить соединение. tcpdump также не показывает входящие запросы.

Поскольку демон apache при перезапуске не вызывал ошибок, я попытался подтвердить, прослушивал ли веб-сервер 8001

$ 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)

Казалось, что он слушает 8001. Я даже попытался применить к терминалу следующие правила iptable:

$ 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

я никогда не получал отказанный журнал. Вот что показывает подробный режим iptables

$ 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 

Я не знаком с правилами iptable, поэтому подсказки по любым правилам, которые я пропустил выше, будут отличными. Читая другие темы, я тоже задавался вопросом, может ли это быть причиной.

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

Учитывая эту информацию, есть ли какие-либо намеки на то, что может останавливать работу веб-сервера на 8001, но не на 80?

ОБНОВЛЕНИЕ 1: Я попытался очистить все правила iptable

$ sudo iptables -X
$ sudo iptables -F

Я также попытался увидеть, ловит ли что-нибудь tcpdump

 sudo tcpdump -i eth0 port 8001 -v

Это не на 8001, но измените порт на 80 (снова в местах ^ 3), и это так.

я попытался найти устоявшиеся и прослушивающие процессы

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

Наконец, с моей локальной машины я также попробовал завить

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

ОБНОВЛЕНИЕ 2

Вдобавок мой / etc / log / messages, который обнаруживает ошибки iptables, похоже, выдал следующее. но оказывается, что они появляются, когда вы входите и выходите из tcpdump.

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

ОБНОВЛЕНИЕ 3 нашел это в часто задаваемых вопросах по tcpdump

... Это может быть связано с тем, что интерфейс, на котором выполняется захват, подключен к коммутатору; в коммутируемой сети, одноадресный трафик между двумя портами не обязательно появится на других портах - на все порты будет отправляться только широковещательный и многоадресный трафик ...

... что будет означать, что если вы обнюхиваете порт 10 Мб, ты не увидишь трафик, поступающий на порт 100 Мб, и наоборот ...

... Если ваш компьютер не подключен к коммутируемой сети или двухскоростному концентратору, или он подключен к коммутируемой сети, но порт настроен на репликацию всего трафика на него, проблема может заключаться в том, что сетевой интерфейс на котором вы захватываете не поддерживает "неразборчивый" режим, или потому что ваша ОС не может перевести интерфейс в неразборчивый режим ...

Итак, чтобы резюмировать этот особый случай:

• iptables были сброшены с помощью -F, -X
• запросы в порядке с прослушиванием apache на 1.2.3.4:80
• tcpdump ничего не улавливает при прослушивании apache на 1.2.3.4:8001 (см. ОБНОВЛЕНИЕ 1,3)