WIFI - Pourquoi pas de Http ?

[coolmatt]

Bonjour,

J'ai un serveur Debian sur lequel je fais tourner mes scripts PHP et partage des fichiers.
Lorsque ma box perd la connexion internet je peux toujours, via WiFi, accéder à mes fichiers en SMB, au serveur en SSH... mais pas en Http à mes scripts. Le navigateur mouline et puis rien, pareil avec wget. Avec traceroute pas de problème tant que je n'indique pas tcp comme protocole.... donc c'est bien le protocole (http sur tcp) qui pose problème. Mais pourquoi ? Je précise que j'accède à mon serveur en adressage direct (192.168.x.x)...
Merci de m'éclairer.
-----

[pm42]

Est ce que par hasard tes scripts ne font pas un include de ressources qui sont sur Internet ? Librairies, images...

Donc en fait, tu accèderais bien à ton serveur Web mais lui essaierait d'accéder à Internet et se mettrait en attente.

Pour tester, tu pourrais essayer de mettre quelque part une page 100% statique en HTML pur sur ton serveur et de voir si tu y accèdes quand ta box est déconnectée du Net.

[coolmatt]

Pour tester, tu pourrais essayer de mettre quelque part une page 100% statique en HTML pur sur ton serveur et de voir si tu y accèdes quand ta box est déconnectée du Net.

Déjà testé, j'aurais du préciser qu'avec les ressources locales c'est pareil...

[Ikhar84]

Salut,

Pas de proxy ni de dns hors réseau local ?

[A voir en vidéo sur Futura]

[pm42]

Pas de proxy ni de dns hors réseau local ?

Ou un serveur Web qui fait du reverse DNS ?

[coolmatt]

Salut, Pas de proxy ni de dns hors réseau local ?

Pas de proxy et je tape directement sur la box (192.168.1.1)

Ou un serveur Web qui fait du reverse DNS ?

Oh non... c'est le serveur web intégré à PHP (php -S)

[LeMulet]

Certains navigateurs bloquent l’accès aux sites HTTP (et laissent le HTTPS ouvert, ce qui nécessité d'accéder quelque-part (à un serveur monté en local ou sur serveur distant (plus problématique si la liaison est coupée...)).
Mais vous me dites que ça fait pareil avec wget (hors navigateur donc si je ne m'abuse(à confirmer)), donc ça peut venir d'un autre problème.

Donc peut-être simplement un problème de paramétrage de votre firewall.
Si le port 80 est interdit pour "all", ça pourrait expliquer le symptôme.
Il faudrait autoriser le port 80 pour les adresses de connection commençant par 192.168.1.

[Ikhar84]

Ce qui me rend perplexe, moi, c'est plus le tracert que le wget. Avec l'IP en dur dans la commande et un dns en local, à moins que la box fasse du pur forward et ne résolve pas l'IP en tcp/http ?
Autre solution: les paquets arrivent bien au serveur mais c'est le chemin de retour que ne se résoud pas du faut d'un config dns pourrie dans /etc/resolve.conf ?

[coolmatt]

Ce qui me rend perplexe, moi, c'est plus le tracert que le wget. Avec l'IP en dur dans la commande et un dns en local, à moins que la box fasse du pur forward et ne résolve pas l'IP en tcp/http ?

Oui, mais pourquoi la résoudrait-elle quand la connexion internet marche ? Et puis résoudre quoi ? Adressage direct

Autre solution: les paquets arrivent bien au serveur mais c'est le chemin de retour que ne se résoud pas du faut d'un config dns pourrie dans /etc/resolve.conf ?

Mon fichier comporte uniquement :
nameserver 8.8.8.8
nameserver 8.8.4.4

Mais même si... le serveur n'a pas à résoudre quoi que ce soit, je lui donne exactement l'adresse ! et l'adresse de retour est aussi une adresse du réseau local...

[LeMulet]

Vous avez aussi le fichier iptables.sh
https://silentkernel.fr/configuratio...-autres-linux/
https://www.geek17.com/fr/content/de...ll-iptables-32

[Ikhar84]

Mais même si... le serveur n'a pas à résoudre quoi que ce soit, je lui donne exactement l'adresse ! et l'adresse de retour est aussi une adresse du réseau local...

Je sais bien, mais on essaies de trouver là où ça bloque...

À part des ports bloqué (parefeu), un problème sur le routage ou l'adressage, je ne vois pas.

Le parefeu: peu probable car cela bloquerais même quand la connection est up...
L'adressage: on utilise des IP en dur ici ...
Le routage: idem que pour le parefeu: en connexion up cela ne devrait pas fonctionner non plus...

Qu'est ce qui pourrait ne pas répondre en connection down et répondre correctement en up ?
Les dns ou les appels à des ressources distantes (comme le reverse dns dit par PM, par exemple ?).

Edit: et là on voit les dns de Google...

[eglyn18]

Quand cela ne fonctionne plus, si tu fais un netstat -atp, est-ce que tu as bien une ligne du style: "0.0.0.0:80 listen" et "0.0.0.0:443 listen" ?

[Fustigator]

Quand cela ne fonctionne plus, si tu fais un netstat -atp, est-ce que tu as bien une ligne du style: "0.0.0.0:80 listen" et "0.0.0.0:443 listen" ?

ce n'est visiblement pas un problème serveur, donc ce test ne semble pas vraiment pertinent.

[eglyn18]

ce n'est visiblement pas un problème serveur, donc ce test ne semble pas vraiment pertinent.

Ben, j'ai du mal comprendre son problème alors, il me semble qu'il y a un serveur en local ip 192.168.1.x auquel il n'arrive pas à accéder via une machine sur ce même réseau local qui est par exemple en 192.168.1.y.

Donc perso, je vérifierais les choses suivantes:
- écoute sur le serveur des ports 80 et 443 sur toutes les IP
- essayer un wget sur le serveur lui-même: wget http://127.0.0.1
- vérification que le serveur ping bien la passerelle (la box en l’occurrence), car il ne pourra pas router les paquets sinon.
- test sur plusieurs machines du réseau local d'accéder sur 192.168.1.x:80 (autre PC, téléphone, etc...)

Quel est le contenu du fichier /etc/network/interfaces ?

[Fustigator]

Ben, j'ai du mal comprendre son problème alors, il me semble qu'il y a un serveur en local ip 192.168.1.x auquel il n'arrive pas à accéder via une machine sur ce même réseau local qui est par exemple en 192.168.1.y.

Non
Le plus simple est peut être de lire avant de répondre, le problème est très clairement exprimé : en résumé, quand il perd la liaison internet, le routage Http (port 80) sur le brin wifi - et uniquement http - merde, alors que les deux sont normalement décorrélés. C'est selon toute vraisemblance un problème de routage / de box, pas un problème de serveur.

D'ailleurs, il n'a jamais dit que le serveur était inaccessible.

[eglyn18]

Non
Le plus simple est peut être de lire avant de répondre, le problème est très clairement exprimé : en résumé, quand il perd la liaison internet, le routage Http (port 80) sur le brin wifi - et uniquement http - merde, alors que les deux sont normalement décorrélés. C'est selon toute vraisemblance un problème de routage / de box, pas un problème de serveur.

D'ailleurs, il n'a jamais dit que le serveur était inaccessible.

Si je relis son premier post, il dit que lorsque la box perd internet (ce qui, on est d'accord n'a aucune incidence sur le réseau local), il n'accède plus en http à son serveur en local via son PC qui est en wifi sur cette même box.
Donc, le seul truc que je vois, c'est que "perdre internet" = box inaccessible = passerelle inaccessible.
Donc si son serveur web a besoin d'une passerelle pour router les paquets, ben le routage ne se fait pas, alors que cela fonctionne bien en SSH (pas de gateway necessaire).
C'est pour cela que je demandais la config réseau du serveur, pour voir quelle passerelle était spécifiée.

[Fustigator]

Si je relis son premier post, il dit que lorsque la box perd internet (ce qui, on est d'accord n'a aucune incidence sur le réseau local), il n'accède plus en http à son serveur en local via son PC qui est en wifi sur cette même box.
Donc, le seul truc que je vois, c'est que "perdre internet" = box inaccessible = passerelle inaccessible..

Non, les brins locaux n'ont a priori pas de raison d'être atteint par une perte du brin WAN.
D'ailleurs il n'a jamais dit que la box était inaccessible, d'autant qu''elle continue à fournir un Wifi "qui marche" puisqu'il arrive à accéder au serveur notamment via Samba.
Le problème ne concerne que le routage Http.