Soucis connexion debian

[Sirius794]

Bonjour,

Je viens vers, car le sèche complètement sur un soucis qui est apparu avant-hier, j'imagine suite à une mauvaise manipulation de ma part.
Je ne peux plus accéder aux différentes parties de mon server dédié sous debian 8.1 que par un ordinateur. Pour essayer d'expliquer plus clairement, je peux accéder au site web hébergé sur le server, au shoutcast (port 8000), au znc (port 13000) etc. via mon Imac. Par contre si j'y vais part mon téléphone ou tablettes connectés en wifi, ça ne fonctionne pas (Si je passe en 4g ça fonctionne).

Est-ce que quelqu'un aurait une idée svp ?
Je vous remercie par avance

[PascalHambourg]

Où ce serveur est-il situé, dans quel réseau ? Dans le même réseau local que les terminaux clients ou bien dans un réseau distant, chez un hébergeur ?
Que se passe-t-il exactement ? "Ça ne marche pas" ne contient aucune information utile.

[mattotop]

si j'y vais part mon téléphone ou tablettes connectés en wifi, ça ne fonctionne pas

Question stupide: si tu vas ailleurs sur le net avec un de tes dispositifs en wifi, ça fonctionne toujours ?

[Sirius794]

Bonsoir, pardon vraisemblablement je me suis mal exprimé. Je vais tâcher de faire mieux.

Le serveur est un serveur hébergé que je loue chez kimsufi sur lequel j'ai installé une debian.
Tous mes appareils fonctionnent normalement (que ce soit en wifi ou 4g).

Le soucis est que je ne peux accéder au <serveur>:port <port (80, 13000 ou 8000) que via mon Imac connecté au wifi (les autres appareils connectés en wifi finissent par avoir une erreur : ERR_CONNECTION_TIMED_OUT).

Donc pour exemple, je me connecte avec mon Imac sur http://<ip du server>, j'ai le site hébergé, si je le fais via ma tablette ou mon chromebook en wifi j'ai un timed out.

Si j'utilise ma connexion 4G, l'ensemble de mes appareils peuvent accéder au server.
Je précise que les autres utilisateurs n'ont pas de soucis, ils accèdent au site ou au shoutcast.
Je précise également que jusqu'avant ce week-end, tout fonctionnait normalement (depuis longtemps) et qu'il est probable que j'ai fait une bêtise ... mais laquelle :/

En espérant avoir été plus clair, merci d'avance de vos réponses

[mattotop]

Code : Tout sélectionner

tout fonctionnait normalement (depuis longtemps) et qu'il est probable que j'ai fait une bêtise

A quoi te rappelle tu d'avoir touché comme config, ou quelle manip a été faite les derniers temps avant que tu constates le problème.
As tu redémarré ton wifi ou ta connection Internet avant que ça se mette à planter ?

Et d'ailleurs, as tu essayé de redémarrer ta box/routeur, ton wifi depuis (à tous hasards) ?

Autre lieu ou chercher, as tu un fail2ban sur ton serveur (si c'est un plesk, c'est sans doute oui) ?
Utilises tu un vpn sur les dispositifs qui ne marchent pas ?

Si j'utilise ma connexion 4G, l'ensemble de mes appareils peuvent accéder au server.

Je continue dans les questions de contexte:
veux tu dire que tu as un routeur qui peut basculer d'adsl à 4G, ou bien veux tu dire que quand tu passes du wifi à la 4G sur tes téléphones, ça marche ?

[edit:
Encore une question subsidiaire, si tu as moyen de le voir, est ce que les resolveurs (dns) sur tes dispositifs qui ne marchent pas quand ils sont en wifi sont les mêmes que ceux qui se configurent sur ton imac, quand tu te connectes pareil au wifi ?
Et où se trouve tes résolveurs ? FAI, ou bien un dns à toi ?
]

[Sirius794]

Oui j'ai redémarré (plusieurs fois d'ailleurs) sans succès. fail2ban n'est pas installé non, ni VPN.

Concernant le moment où je m'en suis rendu compte, je cherchais pourquoi la connexion ssh mettait tant de temps à s'établir.

Voilà les dernières commandes (avant toutes les commandes que j'ai essayé pour corriger le problème) :
226 netstat -tanpu
227 /etc/init.d/networking restart
228 netstat -tanpu
229 echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
230 /proc/sys/net/ipv4/tcp_tw_reuse
231 netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n
232 cat /proc/sys/net/ipv4/tcp_fin_timeout
233 cat /proc/sys/net/ipv4/tcp_tw_recycle
234 echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout
235 echo 1 > /proc/sys/net/ipv4/tcp_tw_recycle
236 echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse
237 egrep 'net.ipv4.tcp_(tw_(reuse|recycle)|fin_timeout)' /etc/sysctl.conf
238 emacs /etc/sysctl.conf
239 sysctl -p

finalement j'ai changé dans le fichier sshd_config : UsePam en no et ajouté UseDNS en no. Ce qui a semble-t-il résolu le problème de lenteur.
J'ai rétabli les valeurs changées (tcp_fin_timeout, tcp_tw_recycle et tcp_tw_recycle) par la suite.
avant il n'y a rien d'intéressant, je n'avais pas touché au server depuis pas mal de temps.
J'ai regardé également du coté de ma box ... je ne vois pas le soucis non plus.
J'avoue bidouiller plus que connaitre sur ce coup ...

[mattotop]

OK, je pensais plutôt aux des manips du coté de ton réseau local, vu que ça touche un cas trés particulier de dispositifs connectés au wifi, même si c'est une intéraction qui peut venir de plus loin.
Là je ne vois vraiment pas où tes modifs auraient pu agir, là comme ça, ça me semble anodin. Tu as essayé, pour voir, en remettant le sshd_config à la version d'avant, pour voir si ça marche ?
As tu pu comparer les resolveurs de tes dispositifs et de ton imac en wifi ?
Et niveau ipv4/ipv6, qu'en est il de tes dispositifs et de ton serveur, les deux couches sont configurées partout, serveur compris ?

[Sirius794]

alors oui, j'ai essayé de remettre sshd_config dans l'état initial et de redémarrer le service ... sans succès. Au niveau local, rien n'a changé.

Code : Tout sélectionner

As tu pu comparer les resolveurs de tes dispositifs et de ton imac en wifi ?
Et niveau ipv4/ipv6, qu'en est il de tes dispositifs et de ton serveur, les deux couches sont configurées partout, serveur compris ?

là, je m'excuse mais je ne comprends pas ... ce sont des choses qui m'échappent un peu. Pourrais-tu me dire comment procéder stp

[mattotop]

Les résolveurs, ce sont les "serveurs dns" auquel tu t'adresses pour résoudre un nom en adresse ip, qui sont configurés dans /etc/resolv.conf (ou par resolvconf) d'un linux.
Quand tu te connectes au wifi, l'adresse de ces serveurs est a priori transmise par le dhcp du wifi et ton client linux va modifier son resolv.conf pour en informer le systéme.
Sur mac, je dirais au feeling que ça doit être assez proche avec un fichier resolv.conf, mais tu dois pouvoir trouver l'info de resolution de nom dans un truc graphique (j'en sais strictement rien, je ne connais mac que théoriquement, et trés mal).
Sur un téléphone, c'est un fonctionnement global identique (le dhcp peut dynamiquement transmettre une config), mais pas forcément en passant par un fichier resolv.conf.
Et pareil que sur mac, je ne sais pas ou trouver l'info sur la résolution des noms.
Pourquoi vérifier: parce que l'erreur de timeout et tout ce que tu décris ressemblent salement à un problème de résolution.
Je viens de penser à un truc tout con pour vérifier ça:
sur tes dispositifs, as tu essayé d’accéder à ton serveur par son ip ? Tu as dit que ça marchait en ip pour le mac, mais est ce que ça plante aussi sur tes dispositif qui plantent ?

Pour l'ipv4/ipv6, c'est pareil, tu dois avoir un endroit qui te dit quelles adresses ip sont attribuées à ton dispositif, et si tu as les deux couches réseaux ipv4/ipv6, tu vois 2 adresses attribuées, une habituelle sur 4 octets (XXX.XXX.XXX.XXX) qui et ton ipv4, et une en ipv6 sur 64 octets (avec une notation différente qui contient des :).
Sur linux, tu peux voir tes adresses avec ip addr, et sur android, a priori, c'est dans les paramètres, "état du téléphone/état".
Les autres OS je ne sais pas.
Le fait d'avoir ou non une des deux couches fonctionnelle ou les deux peut provoquer des soucis similaires.

[Sirius794]

j'avoue ne pas bien comprendre. Concernant les adresses attribuées aux dispositifs ipv4/ipv6 je vois via l'intra de la box, pour l'Imac, ça donne ça :

Code : Tout sélectionner

192.168.1.12
IPv6 :2a01:cb19:27e:ec00:48aa:1b2a:21b9:ed3f

Du coté du mac, le fichier resolv.conf donne ça :

Code : Tout sélectionner

nameserver fe80::d284:b0ff:fe7a:91ae
nameserver 192.168.1.1

est-ce que ça vous aide ?

[mattotop]

Oui, c'est un bon début, j'ai besoin de la même chose sur un dispositif qui plante,.
Mais je n'ai pas besoin des valeurs, juste de savoir si il a une ipv4 et/ou ipv6, et si la configuration de ses nameservers est la même (notamment sur le nameserver ipv6)
Voilà, j'ai trouvé où c'est sur androïd avec cet article:
https://www.phonandroid.com/changer-ser ... phone.html
II faut lire l'article qui explique comment changer la config:
il ne faut pas aller jusqu'au bout, juste aller jusqu'à passer en réglage statique (voir l'article), regarder les valeurs d'adresse et de nameserveur, puis revenir en dhcp comme avant.

[Sirius794]

ça m'apprendra à lire trop vite, je suis allé jusqu'au bout de l'article et donc changer les dns sur les dispositifs qui posaient soucis ... sans comprendre très bien pourquoi, ça a résolu le soucis. Mais peut-être voulais-tu en venir ailleurs du coup ?

[mattotop]

Ben en fait, je voulais savoir ce qu'il y avait avant pour comprendre.
Et le fonctionnement normal de la connection à ton wifi n'est pas de fixer en dur les paramètres, c'est de fonctionner en dhcp, pour que ton point d'accés sache qu'il a attribué l'adresse à ta machine: sinon, il risque de redonner la même adresse à une autre machine et aucune des deux ne fonctionnera et tu te demanderas pourquoi.
Donc il faudrait revenir en dhcp, voir si ça marche.
Si ça ne marche pas, là tu indiques quels serveur il a remis par defaut, avec la même manip qu'avant sans aller jusqu'au bout.
Si tu as urgemment besoin que ça marche en attendant d'avoir remis au propre, tu peux repasser en statique, mais évite d'utiliser les serveurs de google qui t'espionnent, ceux en 8.8.X.X, et utilises plutot les adresses de la FDN qui sont fournies dans l'article (garantis respectueux de la vie privée).

[Sirius794]

Du coup, j'ai remis comme c'était avant les manips ... chose curieuse j'accède tout de même au site sur le server (avant la manip, j'avais vérifié je tombais sur le TIME_OUT). Alors peut-être que de remettre les dns en automatique a mis d'autres valeurs que celles qui y étaient ...
(non je n'avais pas mis google, j'avais mis les dns Cloudflare, je prends bonne note pour FDN)

[mattotop]

Si ça se trouve, la simple reconnexion au wifi aurait suffit.

[Sirius794]

Je l'ai fait plusieurs fois (en tout cas coté téléphone et tablette)? Je ne comprends pas forcément tout, mais au moins je situe vers où est le soucis. Merci à toi pour ton aide, c'est sympa d'avoir pris du temps pour ;)

[mattotop]

De nada.