web-dev-qa-db-fra.com

Transfert de port sur le serveur local

Je souhaite pouvoir accéder à un serveur qui s'exécute sur ma machine locale via Internet. Je configure la redirection de port sur mon routeur:

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

J'ai vérifié si les ports sont ouverts avec http://www.yougetsignal.com/tools/open-ports/ qui indique: Le port 80 est ouvert le ...

Je l'ai essayé avec un serveur Apache ainsi qu'avec un serveur nodeJS sur le port 3000, mais je n'ai jamais accès au serveur.

J'ai vérifié si ma machine écoute sur ces ports avec netstat

netstat -ltn | grep 80

Sortie:

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN

Quelles options dois-je avoir pour aller au fond de cette affaire, toutes les autres vérifications que je pourrais exécuter?

Si cela vous aide, voici la configuration 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$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>

Également effectué une réinitialisation d'usine et un redémarrage de mon routeur pour éviter une configuration incorrecte

iptables avant:

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 après ouverture manuelle du port 80

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

Ceci est la sortie de tcpdump après avoir envoyé une demande à mon adresse IP publique à partir de la même machine sur laquelle le serveur est exécuté, bien que l'ouverture du port 80 ne change rien. Je pense que c'est la requête sortante qui est capturée par 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
1
Dominic Bartl

En supposant que la configuration de la redirection de port sur votre routeur soit correcte, vous devez vous assurer que:

  • La machine 192.168.0.4 possède un serveur Web en cours d'exécution (OK).
  • Il écoute soit 192.168.0.4:80 ou 0.0.0.0:80 (OK).
  • Le pare-feu qui s'exécute peut autoriser les connexions entrantes sur le port 80/TCP (INCONNU).

En ce qui concerne le dernier point - je ne suis pas sûr de ce que sont vos règles iptables. S'il vous plaît poster la sortie de

Sudo iptables -vL INPUT -n

Si les connexions entrantes sur 80/TCP sont bien autorisées, mais que vous ne pouvez pas accéder à votre serveur Web de l'extérieur du réseau, vous pouvez vous connecter au serveur Web et utiliser tcpdump pour capturer le trafic entrant afin de voir si des tentatives de connexion sont en cours. l'atteindre.

Utilisation:

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

Si vous ne voyez aucune connexion lorsque vous essayez de vous connecter à votre serveur Web en dehors de votre réseau, vous devez d'abord résoudre ce problème.

Si le pare-feu de votre ordinateur n'autorise pas les connexions entrantes à atteindre le port 80/TCP, corrigez le problème en exécutant la commande ci-dessous et vérifiez:

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

UPDATE: vous avez également mentionné:

Ceci est la sortie de tcpdump après avoir envoyé une demande à mon adresse IP publique à partir de la même machine sur laquelle le serveur est exécuté

Ce n'est pas susceptible de fonctionner. Le chemin que prend votre demande est:

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

Comme vous pouvez le voir dans la sortie de tcpdump, il y a 3 requêtes HTTP lancées par l'outil que vous avez utilisé pour ouvrir la connexion à votre serveur Web, le routeur refuse toutes les connexions en répondant avec des paquets avec RST ("reset", c'est-à-dire "disparaître", fermer la connexion ").

Pour autant que je sache, de nombreux périphériques fournissant NAT ne vous permettent pas de lancer une demande depuis le réseau situé derrière NAT vers son adresse IP publique, puis de revenir à l'hôte derrière celui-ci. NAT au moyen d'un transfert de port (NAT de destination).

Vous devriez essayer de faire une demande en dehors de votre réseau. Si vous ne disposez pas d'un hôte externe sur lequel vous pouvez vous connecter et utiliser par exemple wget/curl pour faire la demande, essayez quelques-uns des nombreux outils Web permettant de le faire, tels que http: //www.infobyip. com/httpservertest.php

Si cela fonctionne et que vous obtenez un résultat contenant au moins le code d'état de la requête HTTP (200, 302, 404, etc.) et certains en-têtes de réponse tels que Serveur, Type de contenu, vous obtenez les informations suivantes:

  • votre IP publique est accessible de l'extérieur
  • le transfert de port configuré fonctionne
  • le serveur de votre réseau reçoit effectivement la demande et y répond.

Si vous souhaitez pouvoir accéder à votre serveur Web à l'aide de son adresse IP publique depuis le même réseau, vous pouvez:

  • ajoutez une entrée appropriée à votre fichier/etc/hosts, en pointant le nom de domaine du serveur vers l'adresse privée de votre serveur Web (un hack temporaire).
  • lancez un serveur dit split-dns (préféré mais qui ne vaut pas si c'est juste pour vous)
  • reconfigurez votre routeur pour autoriser de telles connexions. Cela peut être fait, mais il est peu probable que votre routeur domestique (si c'est ce que vous avez) puisse le faire.
2
Marcin Kaminski