Connexion impossible à mon serveur Web

Support Debian
#1

Bonjour,

Je me monte un petit serveur chez moi, et j’aimerai y installer un serveur web : pour ça, j’utilise Lighttpd et PHP5. Malheureusement, après avoir installé Lighttpd, je n’arrive pas à accéder à la page de test :frowning:

Je me connecte à mon serveur en SSH (qui est chez moi je le rappelle, donc sur le même réseau que mon PC). Quant je me connecte à l’adresse de mon serveur (192.168.0.2/), Firefox me sort :

[quote]La connexion a échoué

Firefox ne peut établir de connexion avec le serveur à l’adresse 192.168.0.2.[/quote]
Et si je fais un petit wget pour récupérer la page de teste de Lighttpd, j’ai :

[quote]wget 192.168.0.2/index.lighttpd.html
–2010-01-02 17:00:33-- 192.168.0.2/index.lighttpd.html
Connexion vers 192.168.0.2:80… échec: Connexion refusée.[/quote]
Et si je fais en SSH sur mon serveur un wget, pareil !:

[quote]wget 127.0.0.1/index.lighttpd.html
–2010-01-02 17:01:38-- 127.0.0.1/index.lighttpd.html
Connexion vers 127.0.0.1:80…échec: Connexion refusée.[/quote]
Même en “désactivant” iptables avec “iptables -F” et “iptables -X”, impossible !

Dans /etc/hosts.allow, en mettant “ALL: ALL”, et en ne mettant rien dans /etc/hosts.deny, marche toujours pas.

Je commence à désespérer : je ne vois vraiment pas d’où vient le problème. Un peu d’aide me serait précieuse :slightly_smiling:

Je vous remercie par avance,
Cordialement,
Merci.

NB : je suis sous Debian Squeeze.

#2

En premier, il faut vérifier si lighttpd est lancé sur la machine et si le port TCP 80 est ouvert en écoute, par quel processus et sur quelle(s) addresse(s).

ps aux netstat -tlnp # à exécuter en root pour l'option -p

Note : “iptables -F” ne désactive pas iptables, il ne fait que vider les chaînes. Les politiques par défaut restent inchangées, et si elles sont à DROP tout est bloqué !

#3

Alors, ps aux me sort (pour lighttpd) :

Et netstat -tlnp me sort (pour lighttpd) :

:wink:

Donc tout à l’air de marcher nickel ! :smt017

#4

Faut voir… C’est une socket IPv6. Normalement, par défaut une socket IPv6 en écoute sur l’adresse indéfinie (::slight_smile: accepte aussi les communications en IPv4 donc ça devrait être bon avec 127.0.0.1 ou 192.168.0.2. Regarde dans la configuration de lighttpd s’il n’y a pas une option pour spécifier sur quelle(s) adresse(s) il écoute. Que donne la connexion en IPv6 sur l’adresse ::1 (localhost) depuis le serveur lui-même (par exemple "telnet ::1 80) ?

#5

Alors, je suis allé voir dans le fichier de configuration de lighttpd pour voir si y’avait un endroit avec IPV6, ce qui fût le cas :

J’ai commenté la deuxième ligne, et maintenant, c’est bon, ça marche :smt007 J’en déduis donc que Lighttpd n’utilisait que les IPV6, alors que je dois être en IPV4. Mais de quel côté marchait cette option !? Au niveau serveur ou client ? (je sais pas si je suis clair).

Merci beaucoup de votre aide en tout cas :slightly_smiling: Je vais pouvoir profiter de mon serveur web ! Merci !!! :smt007 :wink: :smt002 :smt001

#6

Côté serveur. Si tu refais un netstat -tnlp, la socket devrait maintenant être de type IPv4 (tcp4) en écoute sur l’adresse 0.0.0.0 au lieu de ::.
Mais ça ne dit pas pourquoi la socket IPv6 n’acceptait pas les communications en IPv4. Que dit “/sbin/sysctl net.ipv6.bindv6only” ?

#7

netstat -tnlp :

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1759/lighttpd

Oui, la soket est bien en IPv4 maintenant.

Et pour l’autre commande :

/sbin/sysctl net.ipv6.bindv6only :

net.ipv6.bindv6only = 1

:wink:

#8

Ben voilà, tout s’explique : quand bindv6only=1 une socket IPv6 ouverte en écoute sur :: n’accepte pas les communications IPv4. Mais la valeur par défaut est 0, et je pensais être un des rares originaux utilisateurs d’IPv6 à la mettre à 1 (pour contourner un bug pénible avec bind9 qui n’existe peut-être plus dans la version actuelle, et un problème de lisibilité des adresses IPv4 avec sshd notamment). Je serais curieux de savoir ce qui la met à 1. Tu pourrais jeter un oeil dans /etc/sysctl.conf et les éventuels fichiers dans /etc/sysctl.d/ stp ?

#9

Merci pour l’explication :wink:

Et voici ce que tu demandes :wink: :

/etc/sysctl.conf :

#
# /etc/sysctl.conf - Configuration file for setting system variables
# See /etc/sysctl.d/ for additonal system variables
# See sysctl.conf (5) for information.
#

#kernel.domainname = example.com

# Uncomment the following to stop low-level messages on console
#kernel.printk = 3 4 1 3

##############################################################3
# Functions previously found in netbase
#

# Uncomment the next two lines to enable Spoof protection (reverse-path filter)
# Turn on Source Address Verification in all interfaces to
# prevent some spoofing attacks
#net.ipv4.conf.default.rp_filter=1
#net.ipv4.conf.all.rp_filter=1

# Uncomment the next line to enable TCP/IP SYN cookies
# See http://lwn.net/Articles/277146/
#net.ipv4.tcp_syncookies=1

# Uncomment the next line to enable packet forwarding for IPv4
#net.ipv4.ip_forward=1

# Uncomment the next line to enable packet forwarding for IPv6
#net.ipv6.conf.all.forwarding=1


###################################################################
# Additional settings - these settings can improve the network
# security of the host and prevent against some network attacks
# including spoofing attacks and man in the middle attacks through
# redirection. Some network environments, however, require that these
# settings are disabled so review and enable them as needed.
#
# Do not accept ICMP redirects (prevent MITM attacks)
#net.ipv4.conf.all.accept_redirects = 0
#net.ipv6.conf.all.accept_redirects = 0
# _or_
# Accept ICMP redirects only for gateways listed in our default
# gateway list (enabled by default)
# net.ipv4.conf.all.secure_redirects = 1
#
# Do not send ICMP redirects (we are not a router)
#net.ipv4.conf.all.send_redirects = 0
#
# Do not accept IP source route packets (we are not a router)
#net.ipv4.conf.all.accept_source_route = 0
#net.ipv6.conf.all.accept_source_route = 0
#
# Log Martian Packets
#net.ipv4.conf.all.log_martians = 1
#
# The contents of /proc/<pid>/maps and smaps files are only visible to
# readers that are allowed to ptrace() the process
# kernel.maps_protect = 1
ls /etc/sysctl.d/
bindv6only.conf

Et dans bindv6only.conf :

# This sysctl sets the default value of the IPV6_V6ONLY socket option.
#
# When disabled, IPv6 sockets will also be able to send and receive IPv4
# traffic with addresses in the form ::ffff:192.0.2.1 and daemons listening
# on IPv6 sockets will also accept IPv4 connections.
#
# When IPV6_V6ONLY is enabled, daemons interested in both IPv4 and IPv6
# connections must open two listening sockets.
# This is the default behaviour of almost all modern operating systems.

net.ipv6.bindv6only = 1
#10

Il y a donc un fichier de configuration spécifique pour mettre bindv6only à 1. Par contre j’ai cherché dans le contenu des paquets de squeeze/testing sur le site de Debian de quel paquet venait ce fichier, sans succès. C’est peut-être un fichier créé lors de l’installation d’un paquet et géré en conffile. Je vais abuser encore un peu : pourrais-tu rapporter ce que raconte la commande suivante stp ?

#11

C’est pas grave : ça me permet de comprendre par la même occasion :wink:

dpkg -S /etc/sysctl.d/bindv6only.conf :

dpkg : /etc/sysctl.d/bindv6only.conf introuvable.
#12

Merci quand même. J’ai cherché autrement (par Google comme une brute) et j’ai fini par trouver. Ce fichier est créé par le script de post-installation du paquet netbase (/var/lib/dpkg/info/netbase.postinst), mais il n’est pas déclaré comme fichier de configuration (/var/lib/dpkg/info/netbase.conffiles), donc dpkg ne lui trouve pas de propriétaire (et logiquement “dpkg -L netbase” ne doit pas le lister non plus). C’est tout neuf d’après le changelog du paquet, ça date du 6/12/2009.

Et voilà, en aidant quelqu’un j’ai encore appris un truc !

#13

Comme on pouvait s’y attendre, il y a déjà un rapport de bug Debian pour lighttpd à ce sujet (#560837), et il y a d’autres applications et pas des moindres comme gdm ou kdm qui ont un problème avec ce nouveau réglage (cf. bug #560238).