Encaminhamento de porta para o servidor local

1

Eu quero poder acessar um servidor que está sendo executado na minha máquina local pela Internet. Eu configuro o encaminhamento de porta no meu roteador:

Public Port Range: 80-80
Target IP Address: 192.168.0.4
Target Port Range: 80-80

Eu verifiquei se as portas estão abertas com link , que indica: a porta 80 está aberta em ...

Eu também tentei com um servidor Apache com um servidor nodeJS na porta 3000, mas nunca tive acesso ao servidor.

Eu verifiquei se minha máquina está ouvindo nessas portas com netstat

netstat -ltn | grep 80

Saída:

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN

Quais opções eu tenho para chegar ao final disso, quaisquer outras verificações que eu possa executar?

Se isso ajudar aqui, é a configuração do Apache.

<VirtualHost *:80>
    ServerAdmin webmaster@localhost
    ServerName lebensmittel-schulung.local

    DocumentRoot /home/dominic/workspace/lebensmittel-schulung/public
    <Directory />
        Options FollowSymLinks
        AllowOverride None
    </Directory>
    <Directory /home/dominic/workspace/lebensmittel-schulung/public>
        Options Indexes FollowSymLinks MultiViews
        AllowOverride All
        Order allow,deny
        allow from all
        Require all granted
    </Directory>


    # Redirect www to non-www
    RewriteEngine on
    RewriteCond %{HTTP_HOST} ^www\.(.+)$ [NC]
    RewriteRule ^(.*)$ http://%1 [L,R=301]

    ErrorLog ${APACHE_LOG_DIR}/error.log

    # Possible values include: debug, info, notice, warn, error, crit,
    # alert, emerg.
    LogLevel warn

    CustomLog ${APACHE_LOG_DIR}/access.log combined

    Alias /doc/ "/usr/share/doc/"
    <Directory "/usr/share/doc/">
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    </Directory>

</VirtualHost>

Também fiz uma reinicialização de fábrica e reiniciei meu roteador para evitar uma configuração incorreta

iptables antes:

Chain INPUT (policy ACCEPT 1330K packets, 1422M bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

iptables depois de abrir a porta 80 manualmente

Chain INPUT (policy ACCEPT 68 packets, 9825 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:80
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:53
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:53
    0     0 ACCEPT     udp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            udp dpt:67
    0     0 ACCEPT     tcp  --  virbr0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:67

Esta é a saída do tcpdump depois de fazer um pedido ao meu ip público da mesma máquina em que o servidor está rodando, embora a abertura da porta 80 não altere nada. Eu acho que esta é a requisição de saída que é capturada pelo tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:46:42.402748 IP 192.168.0.4.34870 > chello080108157035.6.12.vie.surfer.at.http: Flags [S], seq 2878976956, win 29200, options [mss 1460,sackOK,TS val 4294937394 ecr 0,nop,wscale 7], length 0
21:46:42.405078 IP chello080108157035.6.12.vie.surfer.at.http > 192.168.0.4.34870: Flags [R.], seq 0, ack 2878976957, win 0, length 0
21:46:43.473378 IP 192.168.0.4.34871 > chello080108157035.6.12.vie.surfer.at.http: Flags [S], seq 1711479299, win 29200, options [mss 1460,sackOK,TS val 4294937661 ecr 0,nop,wscale 7], length 0
21:46:43.473897 IP 192.168.0.4.34872 > chello080108157035.6.12.vie.surfer.at.http: Flags [S], seq 2157458117, win 29200, options [mss 1460,sackOK,TS val 4294937662 ecr 0,nop,wscale 7], length 0
21:46:43.475335 IP chello080108157035.6.12.vie.surfer.at.http > 192.168.0.4.34871: Flags [R.], seq 0, ack 1711479300, win 0, length 0
21:46:43.476463 IP chello080108157035.6.12.vie.surfer.at.http > 192.168.0.4.34872: Flags [R.], seq 0, ack 2157458118, win 0, length 0
    
por Dominic Bartl 14.05.2015 / 19:41

1 resposta

2

Supondo que a configuração de encaminhamento de porta no seu roteador está correta, você precisa garantir algumas coisas:

  • A máquina 192.168.0.4 tem um servidor web em execução (OK).
  • Está escutando 192.168.0.4:80 ou 0.0.0.0:80 (OK).
  • O firewall que pode estar sendo executado nele permite conexões de entrada na porta 80 / tcp (UNKNOWN).

Com relação ao último ponto - não sei quais são as regras do iptables. Por favor poste a saída de

sudo iptables -vL INPUT -n

Se as conexões de entrada em 80 / tcp forem de fato permitidas, mas de alguma forma você não conseguir acessar seu servidor da web de fora da rede, talvez você queira fazer login no servidor web e usar tcpdump para capturar tráfego de entrada para ver se algum tentativas de conexão estão chegando a ele.

Uso:

export ext_if=$(ip ro | awk '/^default via/ {print }')
sudo tcpdump -i ${ext_if} port 80

Se você não vir nenhuma conexão quando estiver tentando se conectar ao seu servidor da Web de fora da sua rede, precisará corrigi-lo primeiro.

Se o firewall em sua máquina não permitir que as conexões de entrada atinjam a porta 80 / tcp, corrija isso executando o comando abaixo e verifique:

sudo iptables -I INPUT -p tcp --dport 80 -j ACCEPT

UPDATE: você também mencionou:

  

Esta é a saída do tcpdump depois de fazer um pedido ao meu ip público de   a mesma máquina em que o servidor está sendo executado

Isso provavelmente não funcionará. O caminho do seu pedido é:

192.168.0.4 =>
<public_ip> (doing source and destination NAT, aka port forwarding) =>
192.168.0.4

Como você pode ver na saída do tcpdump, existem 3 solicitações HTTP iniciadas por qualquer ferramenta usada para abrir a conexão com seu servidor web, o roteador rejeita todas as conexões respondendo com pacotes com RST ("reset", ie " vá embora, feche a conexão ") flag set.

Até onde eu sei, muitos dispositivos que fornecem NAT não permitem que você inicie uma solicitação dentro da rede por trás do NAT para seu endereço IP público e depois para o host por trás do mesmo NAT por meio do encaminhamento de porta (destino NAT ).

Você deve tentar fazer uma solicitação de fora da sua rede. Se você não tiver um host externo em que possa efetuar login e usar, por exemplo, wget / curl para fazer a solicitação, tente algumas das muitas ferramentas baseadas na Web para fazê-lo, como link

Se isso funcionar e você obtiver um resultado que contenha pelo menos o código de status da solicitação HTTP (por exemplo, 200, 302, 404 etc.) e alguns cabeçalhos de resposta, como Server, Content-Type, isso confirmará que:

  • seu IP público é acessível de fora
  • o encaminhamento de porta configurado funciona
  • o servidor da sua rede realmente recebe a solicitação e responde a ela.

Se você quiser acessar seu servidor da web usando seu IP público na mesma rede, você pode:

  • adicione uma entrada apropriada ao seu arquivo / etc / hosts, apontando o nome do domínio do servidor para o endereço particular do seu servidor da web (um hack temporário).
  • execute o chamado servidor split-dns (preferido, mas não vale a pena se for apenas para você)
  • reconfigure seu roteador para permitir essas conexões. Isso pode ser feito, mas é improvável que o seu roteador doméstico (se é isso que você tem) possa fazer isso.
por Marcin Kaminski 14.05.2015 / 20:38