apache ouvindo em 80, mas não em qualquer outra porta

apache ouvindo em 80, mas não em qualquer outra porta

eu queria alterar uma configuração funcional do Apache de example.com (exampleIP = 1.2.3.4 ) para mudar da porta padrão 80 para a porta 8001, de modo quehttp://exemplo.com:8001Deveria trabalhar. Não consegui fazer isso e documentarei o que tentei. Acho que preciso de ajuda no iptables.

meu /etc/hosts em primeiro lugar está bem

1.2.3.4    example.com

Comecei substituindo a porta 80 pela 8001 nos seguintes locais

  1. /etc/apache2/ports.conf

    Ouça 1.2.3.4:8001

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

    NomeVirtualHost 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>

Quando substituo 8001 nos 3 casos acima por 80, funciona. com 8001 não consigo estabelecer uma conexão. tcpdump também não mostra solicitações recebidas.

Como o daemon apache quando reiniciado não gerou nenhum erro, tentei confirmar se o servidor web estava escutando em 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)

Parecia escutar no 8001. Até tentei aplicar as seguintes regras de iptable no terminal:

$ 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

nunca recebi um log negado. Aqui está o que o modo detalhado do iptables mostra

$ 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 

Não estou familiarizado com as regras do iptable, então dicas sobre quaisquer regras que perdi acima serão ótimas. Lendo outros tópicos, também me perguntei se isso poderia ser um motivo.

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

Dada esta informação, alguma dica sobre o que poderia estar impedindo a execução do servidor web em 8001, mas não em 80?

ATUALIZAÇÃO 1: eu tentei liberar todas as regras do iptable

$ sudo iptables -X
$ sudo iptables -F

eu também tentei ver se o tcpdump estava pegando alguma coisa

 sudo tcpdump -i eth0 port 8001 -v

Isso não acontece no 8001, mas mude a porta para 80 (em ^ 3 lugares novamente) e isso acontece.

tentei procurar processos estabelecidos e de escuta

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

Por último, na minha máquina local, tentei curl também

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

ATUALIZAÇÃO 2

Além disso, meu /etc/log/messages que detecta erros de iptables parecia gerar o seguinte. mas acontece que eles aparecem quando você entra e sai do 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

ATUALIZAÇÃO 3 encontrei isso nas perguntas frequentes do tcpdump

...Isso pode ocorrer porque a interface na qual você está capturando está conectada a um switch; em uma rede comutada, tráfego unicastentre duas portas não aparecerá necessariamenteem outras portas - apenas o tráfego de transmissão e multicast será enviado para todas as portas...

...o que indicaria que se você detectar uma porta de 10Mb,você não verá tráfego vindo enviado para uma porta de 100Mb e vice-versa...

...Se a sua máquina não estiver conectada a uma rede comutada ou a um hub de velocidade dupla, ou estiver conectada a uma rede comutada, mas a porta estiver configurada para ter todo o tráfego replicado para ela, o problema pode ser que a interface de rede em que você está capturando não suporta o modo "promíscuo", ou porque seu sistema operacional não consegue colocar a interface no modo promíscuo...

então, para resumir este caso peculiar:

  • iptables foram liberados com -F, -X
  • solicita bem com o apache ouvindo em 1.2.3.4:80
  • tcpdump não pega nada com o apache ouvindo em 1.2.3.4:8001 (veja UPDATE 1,3)

Responder1

Na etapa 3 você mencionou

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

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

O que não está correto. Deveria ser

<VirtualHost 1.2.3.4:8001>ServerName exemplo.com ...</VirtualHost>

Responder2

Se isso não incomoda você, tente vincular a qualquer interface com:

Listen 0.0.0.0:8001

E ServerName deveria ser:

ServerName example.com

O resto você mantém como já configurou. Observe que NameVirtualHost e VirtualHost devem ter a mesma assinatura. E por ser um host virtual baseado em nome, você precisa adicionar ao seu arquivo hosts na máquina com o navegador uma linha como:

1.2.3.4 example.com

e usar emhttp://exemplo.com:8001/como URL no navegador (curl, wget,MSIE, Firefox)

Para depuração, use:

tshark -V -i eth0 port 8001 or port 80

Veja o que está acontecendo em error.log e em access.log

Responder3

Listen não implementa hosts virtuais. http://httpd.apache.org/docs/2.0/bind.html#virtualhost

Adicione ao /etc/apache2/ports.conf apenas ouça 8001

certifique-se de que a inclusão seja antes da inclusão dos virtualhosts no arquivo apache2.conf. Você também pode colocar o comando Listen diretamente no arquivo apache2.conf antes de incluir linhas.

Saúde

Responder4

afinal, era um problema de firewall quando entrei em contato com o pessoal da hospedagem.

Tentarei fazer com que eles expliquem o que de fato fizeram para impor isso.

acabou sendo um bom exercício de administrador de sistema. obrigado a todos...

informação relacionada