Apache et VMware Server sous Ubuntu 7.10

Bonjour,

J'ai créé 2 VM avec VMware : SRVLAN et SRVDMZ
SRVLAN a un serveur de dépôt Ubuntu
mon but : que SRVDMZ puisse mettre à jour sa distribution Linux avec le seveur de dépôt de SRVLAN

* un serveur VM SRVLAN avec 2 cartes ethernet :
- eth0 192.168.254.10 montée en NAT sur vmnet8
- eth1 192.168.2.1 sur vmnet2
- mise en place du routeur sur SRVLAN
- mise en place de la translation d'adresses (NAT)
- serveur de dépôts Ubuntu installé avec debmirror et rsync
- export du dépôt pour les VM clientes avec serveur Apache2 installé

* un serveur VM SRVDMZ avec 2 cartes ethernet
- eth0 monté en NAT sur vmnet8
- eth1 sur vmnet2 relié à SRVLAN par 192.168.2.1

* tests réalisés :
pings réussis de SRVDMZ vers SRVLAN :
- 192.168.2.2 ( IP de SRVDMZ lui-même )
- 192.168.2.1 ( sa gateway )
- 192.168.254.2 ( le DNS de SRVLAN )
- www.google.fr
par contre, la commande suivante de SRVDMZ vers SRVLAN :
- telnet 192.168.2.1 80
renvoie ce message :
- telnet : unable to connect to remote host : connection refused
et la connexion par le navigateur Firefox de SRVDMZ sur 192.168.2.1 est impossible alors que le ping est possible !

J'ai regardé énormément de documentations sur le net, pas moyen d'avancer...

Quelles commandes lancer pour diagnostiquer la source du problème ?

Merci d'avance pour votre réponse d'expert

Pour le moment, je vois 5 possibilités :

1. Pare-feu ou routeur bloquant les connexions vers 192.168.2.1
2. Apache n'est pas démarré :mrgreen:
3. Apache n'écoute pas sur le port 80
4. Apache écoute sur le port 80 mais pas sur l'interface 192.168.2.1
5. Une combinaison des précédents

Regarde la valeur de la directive Listen dans la conf d'Apache : s'il y a une adresse IP, vérifie qu'il s'agit bien de 192.168.2.1.

Merci pour cette réponse très rapide !

1. Pare-feu ou routeur bloquant les connexions vers 192.168.2.1
Je n'utilise que des VM créées avec VMware et Ubuntu 7.10, sans pare-feu à ma connaissance, mais comment le vérifier ?

J'ai transformé SRVLAN en routeur pour faire transiter les paquets arrivant de eth1 vers eth0 par cette commande insérée dans /etc/rc.local pour qu'elle soit active à chaque démarrage :
echo 1 >/proc/sys/net/ipv4/ip_forward

J'ai également mis en place la translation d'adresses (NAT) par cette commande insérée également dans /etc/rc.local :
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

La commande suivante indique que la règle est bien prise en compte
iptables -t nat -L

elle génère 3 lignes (policy ACCEPT)

2. Apache n'est pas démarré
si, bien sûr
3. Apache n'écoute pas sur le port 80
le fichier ports.conf est dans sa configuration de base avec Listen 80
4. Apache écoute sur le port 80 mais pas sur l'interface 192.168.2.1
J'ai indiqué l'ip 192.168.2.1 dans mon fichier vhost :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

NameVirtualHost 192.168.2.1 <VirtualHost 192.168.2.1> ServerName www.virtual.local ServerAlias virtual.local *.virtual.local ServerAdmin kortep@gmail.com DocumentRoot /var/www/core <Directory /var/www/core> Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all # This directive allows us to have apache2's default start page # in /apache2-default/, but still have / go to the right place RedirectMatch ^/$ /apache2-default/ </Directory> ErrorLog /var/log/apache2/error.virtual.local.log CustomLog /var/log/apache2/access.virtual.local.log combined </VirtualHost>

---

5. Une combinaison des précédents

Regarde la valeur de la directive Listen dans la conf d'Apache : s'il y a une adresse IP, vérifie qu'il s'agit bien de 192.168.2.1.

Voilà, j'espère avoir été assez précis

On est d'accord que tu as "Listen 80" et pas de "Listen <IP>:80" ? Dans ce cas, je ne vois qu'un pb de routage car tout semble OK. Sur SRVLAN, démarre Apache et fais un netstat -a | grep 80 (ou grep http) : tu obtiens quoi ?

Voilà le résultat obtenu :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

root@srvlan:/etc/apache2/sites-enabled# netstat -a | grep 80 unix 2 [ ACC ] STREAM LISTENING 17196 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 2 [ ACC ] STREAM LISTENING 18007 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18880 unix 3 [ ] STREAM CONNECTE 18041 /tmp/.ICE-unix/5236 unix 3 [ ] STREAM CONNECTE 18039 unix 3 [ ] STREAM CONNECTE 18040 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 18038 unix 3 [ ] STREAM CONNECTE 18037 /tmp/orbit-petro/linc-157d-0-2f7fcd418d31c unix 3 [ ] STREAM CONNECTE 18036 unix 3 [ ] STREAM CONNECTE 18029 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 18028 unix 3 [ ] STREAM CONNECTE 18027 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18025 unix 3 [ ] STREAM CONNECTE 18017 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18016 unix 3 [ ] STREAM CONNECTE 18015 /tmp/orbit-petro/linc-14b4-0-705129c138156 unix 3 [ ] STREAM CONNECTE 18014 unix 3 [ ] STREAM CONNECTE 18012 /tmp/.ICE-unix/5236 unix 3 [ ] STREAM CONNECTE 18011 unix 3 [ ] STREAM CONNECTE 18010 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18009 unix 3 [ ] STREAM CONNECTE 18006 /tmp/orbit-petro/linc-149b-0-5c49f3ea695ed unix 3 [ ] STREAM CONNECTE 18005 unix 3 [ ] STREAM CONNECTE 17980 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 17380 /tmp/orbit-petro/linc-14e6-0-5b3b47897c278 unix 3 [ ] STREAM CONNECTE 17235 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 17204 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 17199 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 16880 /tmp/orbit-petro/linc-14da-0-40b99ad1ca26f unix 3 [ ] STREAM CONNECTE 16480 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTE 13809 unix 3 [ ] STREAM CONNECTE 13808 @/tmp/dbus-D490QC2NPh unix 3 [ ] STREAM CONNECTE 13807 unix 3 [ ] STREAM CONNECTE 13806 unix 3 [ ] STREAM CONNECTE 13805

---

que je suis incapable d'interpréter...

Arf, c'est pas tout à fait ce que je voulais. Essaie avec -an éventuellement. En fait, je cherche une sortie qui indique les ports qui sont en écoute (LISTENING).

J'obtiens la même chose, sauf la première ligne :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38

root@srvlan:/etc/apache2# netstat -an | grep 80 tcp 0 0 192.168.2.1:80 0.0.0.0:* LISTEN unix 2 [ ACC ] STREAM LISTENING 17196 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 2 [ ACC ] STREAM LISTENING 18007 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18880 unix 3 [ ] STREAM CONNECTE 18041 /tmp/.ICE-unix/5236 unix 3 [ ] STREAM CONNECTE 18039 unix 3 [ ] STREAM CONNECTE 18040 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 18038 unix 3 [ ] STREAM CONNECTE 18037 /tmp/orbit-petro/linc-157d-0-2f7fcd418d31c unix 3 [ ] STREAM CONNECTE 18036 unix 3 [ ] STREAM CONNECTE 18029 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 18028 unix 3 [ ] STREAM CONNECTE 18027 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18025 unix 3 [ ] STREAM CONNECTE 18017 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18016 unix 3 [ ] STREAM CONNECTE 18015 /tmp/orbit-petro/linc-14b4-0-705129c138156 unix 3 [ ] STREAM CONNECTE 18014 unix 3 [ ] STREAM CONNECTE 18012 /tmp/.ICE-unix/5236 unix 3 [ ] STREAM CONNECTE 18011 unix 3 [ ] STREAM CONNECTE 18010 /tmp/orbit-petro/linc-157f-0-eef66e67d48a unix 3 [ ] STREAM CONNECTE 18009 unix 3 [ ] STREAM CONNECTE 18006 /tmp/orbit-petro/linc-149b-0-5c49f3ea695ed unix 3 [ ] STREAM CONNECTE 18005 unix 3 [ ] STREAM CONNECTE 17980 /tmp/orbit-petro/linc-14aa-0-24e91bfc8ec17 unix 3 [ ] STREAM CONNECTE 17380 /tmp/orbit-petro/linc-14e6-0-5b3b47897c278 unix 3 [ ] STREAM CONNECTE 17235 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 17204 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 17199 /tmp/orbit-petro/linc-152f-0-99780f999eda unix 3 [ ] STREAM CONNECTE 16880 /tmp/orbit-petro/linc-14da-0-40b99ad1ca26f unix 3 [ ] STREAM CONNECTE 16480 /tmp/.X11-unix/X0 unix 3 [ ] STREAM CONNECTE 13809 unix 3 [ ] STREAM CONNECTE 13808 @/tmp/dbus-D490QC2NPh unix 3 [ ] STREAM CONNECTE 13807 unix 3 [ ] STREAM CONNECTE 13806 unix 3 [ ] STREAM CONNECTE 13805

---

Cette première ligne fait toute la différence : elle montre justement qu'il y a qqch qui écoute sur le port 80 sur l'interface 192.168.2.1, c'est exactement la confirmation que je cherchais. Conclusion : Apache et sa configuration n'est pas en cause a priori.

Les autres pistes à explorer :

• Routage : peu vraisemblable car on a une erreur "connection refused" et pas une "no route to host" mais à vérifier quand même.
• Pare-feu : désactive ipchain ou tous les autres pare-feu qui peut y avoir sur la route. Et pour répondre à ta question d'hier, je ne sais pas comment vérifier :aie: Tu peux essayer un telnet 192.168.2.1 80 depuis ton hôte et voir si ça passe : si ça passe pas avec la même erreur "connection refused" c'est qu'il y a un pare-feu qq part.

J'ai l'impression qu'il s'agit d'un problème de routage...

résultats de mes tests :

host vers SRVLAN

telnet 192.168.2.1 80
telnet: Unable to connect to remote host: Connection refused

A mon avis, ce n'est pas génant, car le problème se situe en amont

SRVLAN vers SRVDMZ

telnet 192.168.2.2 80
telnet: Unable to connect to remote host: Connection refused

SRVDMZ vers SRVLAN

telnet 192.168.2.1 80
telnet: Unable to connect to remote host: Connection refused

c'est ici que c'est problèmatique

Concernant le pare-feu, tu avais raison, il y a un pare-feu installé par défaut avec Ubuntu,
mais, normalement, il autorise tout :

root@srvlan:/home/petro# iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE 0 -- anywhere anywhere

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Que faire ?

- modifier les règles, mais comment ?

- le désactiver, mais comment ? ( la commande ipchain ne fonctionne pas )

Aucune idée. avec RedHat, y a une case à décocher dans un coin pour désactiver le service. Je ne pense pas que ce soit un pb de routage car le ping fonctionne et le message d'erreur n'est pas symptomatique d'un pb de routage.

J'ai installé l'outil FireStarter qui est une interface graphique qui permet de configurer facilement le pare-feu de manière graphique

Quand je désactive le pare-feu sur SRVLAN

sur SRVDMZ le ping 192.168.2.1 fonctionne
mais telnet 192.168.2.1 80 donne le même message :
telnet: Unable to connect to remote host: Connection refused

Sur SRVLAN, y a un serveur SSH ou telnet lancé ? Si oui, essaie de te connecter dessus pour voir si tu as toujours l'erreur "connection refused".

Heureusement que j'ai trouvé cette interface graphique 'FireStarter' pour changer rapidement les caractéristiques du pare-feu :D

En HTTP, HTTPS, Telnet, connection refused quelle que soit la source

Par contre, en SSH, je pense que la connexion a réussi quelle que soit la source : everyone, lan, ou l'IP de SRVDMZ : 192.168.2.2

j'essaie la connexion de SRVDMZ avec cette commande :

telnet 192.168.2.1 22 (car je n'en connais pas d'autres...)
j'obtiens ce message :

Trying 192.168.2.1 ...
Connected 192.168.2.1.
Escape character is '^]'
SSH-2.0-OpenSSH_4.6p1 Debian-5ubuntu0.2

J'espère que cela signifie que la connexion fonctionne :roll:

Oui, le fait d'avoir le petit message "Connected 192.168.2.1. Escape character is '^]'", ça veut dire que ça accroche. Au passage, la commande pour faire du ssh, c'est ssh (pour une fois qu'une commande Unix est explicite !) : ssh utilisateur@machine. Mais c'est pas la peine de faire le SSH, ça n'apportera pas grand chose au problème, ça accroche. On peut donc éliminer le routage. Ceci dit, je suis toujours convaincu qu'il s'agit d'un pb de pare-feu : SSH étant un protocole réputé sécurisé, il doit être autorisé contrairement à telnet et HTTP.

Là, malheureusement, je ne connais pas Ubuntu donc ça va être difficile de t'aider davantage. Cherche avec ton ami le moteur de recherche bien connu s'il y a un paramétrage de pare-feu par défaut qu'on ne voit pas :roll:

Un grand merci pour ton aide jusqu'à maintenant
Si je comprends bien ton dernier message, cela signifie que tu ne pourras plus m'aider :(
Ne pourrais-tu pas passer la main à un autre modérateur Apache ou Linux Ubuntu, je vois que vous êtes très nombreux

à l'avance, merci

Ca se passe pas vraiment comme ça, y a pas de passage de relai : contribue qui veut ;) Tu peux peut-être ouvrir une discussion dans le forum Linux pour demander s'il y a un pare-feu par défaut dans Ubuntu et comment faire pour le désactiver.

Mais avant ça, 2 derniers tests :

1. Démarre le serveur telnet sur SRVLAN (pour savoir si c'est OK, fais un telnet localhost depuis SRVLAN) et essaie de t'y connecter depuis SRVDMZ.
2. Essaie de te connecter en SSH sur SRVLAN depuis SRVDMZ malgré ce que j'ai dit avant (rappel : la commande est tout simplement ssh utilisateur@machine). C'est comme un telnet mais en SSL.

Le but c'est de montrer que ce n'est pas un pb de routage (car le SSH passe), que certains services (SSH par exemple) passent mais pas d'autres, ce qui n'est pas logique dans l'absolu. Dans ce cas, tu pourras dire précisément que tu as des services réseau démarrés sur SRVLAN comme telnet qui sont accessibles localement mais pas à distance, mais que ssh passe.

Après de multiples essais, je pense avoir diagnostiqué le problème ;)

Je ne sais pas si tu connais vmware, mais le problème vient de la configuration de vmware server qui est beaucoup moins facile à partir d'une machine hôte Linux par rapport à un hôte Windows. Sous Windows, on a une console qui permet de configurer les différentes cartes VMnet, cet outil n'existe pas sous Linux ! On est obligé de lancer un script Perl 'vmware-config.pl' pour réaliser cette configuration.

Dans le manuel que je suis, ce problème est noté, et l'auteur avoue qu'il préfère un hôte Windows, même version 2000, pour configurer les VM...
Il indique bien que sur une VM connectée au net par la machine hôte, il faut que vmnet0 soit 'bridged' avec la carte eth0 de l'hôte et que vmnet8 soit en mode NAT. Il conseille de ne pas utiliser vmnet1, mais d'utiliser vmnet2 et suivants si l'on veut des interfaces supplémentaires en mode 'custom specific virtual network' et pas en mode 'host-only : a private network shared with the host'.

Je pense que le problème se situe ici. J'ai beau dans le script indiquer que je ne veux pas de ce mode 'host-only : a private network shared with the host', il me le met quand même, en background, à côté du mode NAT que je veux pour mon sous-réseau !

Maintenant en réponse à tes questions :

1 - sur SRVLAN, pare-feu arrêté,
ping localhost : ok
telnet localhost : unable to conncet to remote host
2 - toujours sur SRVLAN, pare-feu démarré avec telnet ouvert pour tout le monde
ping localhost : ok
telnet localhost : unable to conncet to remote host
par contre :
telnet 192.168.2.1 80 : ok
par firefox 192.168.2.1 : ok
3 - de SRVDMZ à SRVLAN avec pare-feu activé et services HTTP, telnet et SSH ouverts
ping 192.168.2.1 : ok
telnet 192.168.2.1 80 : non
telnet 192.168.2.1 23 : non
telnet 192.168.2.1 22 : ok
ssh user@192.168.2.1 : OK
OK, mais sur la machine hôte qui se nomme 'hp' et non pas sur la VM SRVLAN
le prompt retourné est user@hp~$

Donc, le problème me semble plus clair : 192.168.2.1 renvoie à la l'hôte (adresse IP de vmnet8 192.168.254.0)
et non pas à SRVLAN qui a l'adresse IP 192.168.2.1 par vmnet2

Je pense que cela est dû au mode 'host-only : a private network shared with the host', mais comment supprimer totalement ce mode ?
Car lorsqu'on choisit le mode NAT et que l'on répond 'no' à la question 'do you want to use host-only network',
il place quand même ce mode en 'background'...

J'espère que tu vas avoir une lumière ou une piste de recherche,

merci, d'avance

Pourquoi ne pas changer l'IP de SRVLAN en 192.168.2.3 par exemple pour éviter le .1 qui correspond à l'hôte ? Dans ce cas-là, je pense qu'un host-only devrait marcher. Qq'1 m'a dit y a pas longtemps qu'un NAT n'était pas fondamentalement différent d'un host-only, la différence étant qu'en NAT le réseau peut avoir plusieurs hôtes. Donc c'est pas impossible qu'en arrière-plan tourne le programme host-only dans une configuration NAT.