5 votes

Mac OS X Server ignore les connexions HTTP distantes, mais accepte les connexions locales.

Je n'arrive pas à faire en sorte que le serveur Web de Mac OS X Server accepte les connexions d'autres machines sur le même réseau local. Cette situation se produit sous OS X 10.8.2, sur un Mac mini livré à l'origine avec Lion Server.

I peut vous y connecter à partir du serveur lui-même, par exemple en allant sur http://localhost o http://hostname.example.com dans Safari.

Remarquez que la connexion via le nom de domaine de la boîte fonctionne. C'est parce que :

$ netstat -na | grep 80.*LISTEN
tcp46      0      0  *.80                   *.*                    LISTEN 

C'est à dire qu'Apache écoute sur toutes les interfaces, pas seulement lo .

Si je telnet server 80 à partir d'une machine cliente tout en faisant une capture de paquets des deux côtés, je ne vois que des répétitions de TCP SYN paquets. ( perspective de serveur , perspective du client )

La désactivation du pare-feu dans le volet des paramètres de sécurité et de confidentialité ne modifie pas le symptôme.

La configuration du pare-feu ça me semble inoffensif . (Déposé via pfctl -sa .)

Je suis certain que le problème n'est pas du côté du client. J'ai essayé d'y accéder depuis :

  • un iMac d'un mois sur GigE
  • un MacBook Pro de 2 ans d'âge en WiFi
  • un netbook de 5 ans faisant tourner Ubuntu 12.04 en GigE et WiFi

Ce serveur est sans tête, et je fais tout mon travail sur lui à partir de machines clientes sur le réseau local, via SSH et VNC. Cela signifie que si je ne parviens pas à me connecter à ce serveur sur le port TCP 80, je l'utilise avec succès sur les ports TCP 22 et 5900. C'est ce comportement qui m'a poussé à examiner la configuration du pare-feu.

Voici à quoi ressemble le réseau :

home office network

Il y a deux commutateurs réseau car ce réseau est réparti sur deux pièces, avec un commutateur dans chaque pièce et un seul câble entre les deux. J'ai exclu le commutateur géré comme source du problème avec le test WiFi. J'ai disculpé le commutateur muet en faisant passer temporairement un long câble du serveur au commutateur géré.

Le modem câble et le routeur WiFi (un AirPort Extreme) sont tous deux équipés de commutateurs à 4 ports, mais un seul port est utilisé sur chacun d'entre eux, de sorte qu'aucun trafic ne passe par eux s'il n'est pas absolument nécessaire. Les serveurs DHCP et DNS en cache sont désactivés sur les deux routeurs, puisque ces tâches sont effectuées (avec succès !) par le serveur en question. L'AirPort est en mode pont uniquement.

Et oui, j'ai redémarré le serveur. Et les clients. Et les routeurs. Et les commutateurs. :)

Je pense que le problème est dû à la mise à niveau de cette boîte à partir de Lion Server. Si c'est le cas, une réinstallation complète résoudra le problème, mais cela va à l'encontre de toute ma formation en gestion de serveurs Unix. Je veux réparer ce serveur sur place, si je le peux.

4voto

Gordon Davisson Points 30215

OS X possède en fait (au moins) 3 pare-feu. Puisque vous avez désactivé le pare-feu d'application (dans Préférences système -> Sécurité et confidentialité -> Pare-feu) et coché le filtre de paquets Berkeley ( pfctl -sa ), je suppose que c'est l'ancien ipfw qui fait le blocage. Vous pouvez vérifier avec sudo ipfw show -- Il s'agit de la liste des règles actives, avec le nombre de paquets et d'octets auxquels chacune d'entre elles s'est appliquée :

$ sudo ipfw show
01000 19228642 23229993542 allow ip from any to any via lo0
01010        0           0 deny ip from any to 127.0.0.0/8
[etc...]
65534    23505     3467352 deny ip from any to any
65535        0           0 allow ip from any to any

Si votre liste n'affiche que la règle #65535 (la règle d'autorisation à la fin), mon hypothèse est fausse et vous devez chercher ailleurs. S'il y a d'autres règles, vous avez probablement un programme de configuration de pare-feu tiers installé quelque part (je ne pense pas que le logiciel de configuration ipfw fourni par Apple soit encore disponible en 10.8) ; jetez un coup d'oeil dans /Library/StartupItems et /Library/LaunchDaemons pour des choses qui pourraient être pertinentes.

1voto

Abbafei Points 141

Ouvrez Console.app et vérifiez /var/log/appfirewall.log. Vous devez vérifier si la demande de connexion atteint le pare-feu des applications. Si elle y parvient ET qu'elle est autorisée, vérifiez ensuite /var/log/apache2/access_log et /var/log/apache2/error_log pour voir si la demande atteint Apache. Si la requête atteint Apache, le problème se situe probablement dans le(s) fichier(s) de configuration d'Apache. Si aucun des journaux ci-dessus ne montre quoi que ce soit, vérifiez le fichier system.log pour trouver des indices supplémentaires.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X