Impossible d'acceder a JEEDOM depuis internet

[bartounet]

ca à été long, mais j'ai bien eu accès à un moment donné à la page d'acceuil



Puis plus rien.

on dirait que ca répond mais très lentement

[Bosquetia]

Les logs d'apache ne te disent pas grand chose mais pour les autres ils peuvent peut être parler non ?
Tu dis ne pas connaitre la partie admin mais tu ne partages aucune info.

La il y a eu connexion donc il y a bien un souci et sans partager d'infos techniques on ne va pas aller loin !!

[bartounet]

Je penche plus pour un problème TLS.

essaie en désactivant temporairement https via le port 80

[Wedge34]

@Bartounet : je vais tenter de desactiver le https, bonne idée !

@Bosquetia : comme je te l'ai dit plus haut, j'ai éliminé la partie reseau !! (moi aussi je sais mettre des points d'exclamation )
pour la partie systeme, je peux fournir tout les logs nécessaires a conditions qu'on me dise ou ils sont et quels sont les logs nécessaires.

Merci de ne pas être condescendant.

[Bosquetia]

Hello

Tu dis que tu es admin réseau certifié, tu es donc informaticien et tu ne sais pas chercher un minimum sur google pour savoir ou se trouvent les logs d'apache ?!

C'est toi qui est condescendant et étalant tes certifications et en ne faisant aucun effort pour chercher un minimum...
Allez bonne recherche.

[poluket]

un petit tcpdump sur le jeedom permettrait d'y voir un peu plus clair .... et les traces, pour un admin réseau, que du bonheur

[bartounet]

En tous cas j'ai déjà capturé les paquets depuis un client sur le net et son FQDN

Résultat, on a bien l'établissement de la connexion: ( SYN/SYN ACK/ ACK)

Par contre après retransmissions TCP jusqu’au time out
C'est applicatif mais ou ...

[Wedge34]

bon sinon j'ai desactivé la redirection https et j'ai exactement le même soucis en http
err_timed_out

j'en ai profiter pour mettre a jour certbot et regener mon certificat https (au cas ou), je continue mes recherches...

[poluket]

Si cela ne fonctionne pas non plus en http, c'est pas le certificat. Peux tu prendre une trace sur la box.

[Wedge34]

Bonjour
Je continue mes tests.
je pensais que le ssh marchait, mais en fait j'ai le même comportement.
Depuis l'exterieur ca ne fonctionne pas depuis l'interne toujours sans problème

par contre le telnet réponds bien partout (80,443,23)

un telnet monip 23 me réponds : SSH-2.0-OpenSSH_7.4p1 Raspbian-10+deb9u6

mais si je me connecte en SSH, rien ne se passe

[Wedge34]

pour le ssh encore plus bizarre
depuis mon mobile avec une app, je me connecte nickel en ssh (et pas en http/https)
depuis putty sur un pc rien du tout...
j'avoue que je suis perdu la

[bartounet]

Tu aura plus vite fait de réinstaller un raspian propre et redescendre une backup à mon avis

[Wedge34]

bon je viens de m'apercevoir d'un truc :

pi@JEEDOM:/etc/dhcp $ traceroute google.fr
traceroute to google.fr (216.58.201.227), 30 hops max, 60 byte packets
1 box (192.168.1.1) 0.671 ms 0.706 ms 0.655 ms
2 34mpl1-nro-1.nro.gaoland.net (109.24.76.14) 3.236 ms 3.190 ms 3.336 ms
3 69.119.24.109.rev.sfr.net (109.24.119.69) 3.285 ms 3.240 ms 3.386 ms
4 5.69.26.109.rev.sfr.net (109.26.69.5) 3.340 ms 9.69.26.109.rev.sfr.net (109.26.69.9) 3.660 ms 5.69.26.109.rev.sfr.net (109.26.69.5) 3.245 ms
5 182.128.136.77.rev.sfr.net (77.136.128.182) 3.968 ms 3.920 ms 4.026 ms
6 186.128.136.77.rev.sfr.net (77.136.128.186) 5.759 ms 4.222 ms 4.165 ms
7 241.10.136.77.rev.sfr.net (77.136.10.241) 15.451 ms 16.133 ms 16.023 ms
8 241.10.136.77.rev.sfr.net (77.136.10.241) 15.511 ms 15.593 ms 15.545 ms
9 72.14.218.124 (72.14.218.124) 15.075 ms 15.028 ms 14.978 ms
10 108.170.244.161 (108.170.244.161) 15.173 ms 15.129 ms 108.170.244.225 (108.170.244.225) 16.753 ms
11 216.239.48.143 (216.239.48.143) 16.473 ms 216.239.48.27 (216.239.48.27) 16.431 ms 216.239.48.143 (216.239.48.143) 16.612 ms
12 fra02s18-in-f3.1e100.net (216.58.201.227) 15.256 ms 16.036 ms 15.864 ms

pi@JEEDOM:/etc/dhcp $ ping 192.168.1.1
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.644 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.569 ms
^X64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.558 ms
^C
--- 192.168.1.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2061ms
rtt min/avg/max/mdev = 0.558/0.590/0.644/0.043 ms

pi@JEEDOM:/etc/dhcp $ ping 109.24.119.69
PING 109.24.119.69 (109.24.119.69) 56(84) bytes of data.
64 bytes from 109.24.119.69: icmp_seq=1 ttl=253 time=1.48 ms
64 bytes from 109.24.119.69: icmp_seq=1 ttl=253 time=2.42 ms (DUP!)
^C
--- 109.24.119.69 ping statistics ---
2 packets transmitted, 1 received, +1 duplicates, 50% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.489/1.959/2.429/0.470 ms


vers l'exterieur j'ai des paquets dupliqués, la BOX a été completement resetée, j'ai ouvert en parallele un incident chez SFR....

Qu'elle galere !

[Wedge34]

Bon j'ai vu sur les forum que les paquets dupliqués c'est une spécialité SFR...

par contre bizarre quand je redemarre le jeedom et que je fais mes test, a un moment l'interface web me renvoi bien des trucs du genre :
SQLSTATE[HY000] [2002] No such file or directory
depuis un navigateur...

et si je fais un netstat :
tcp 0 3003 JEEDOM:https *.*.*.*.:51797 ESTABLISHED

[Wedge34]

Tu aura plus vite fait de réinstaller un raspian propre et redescendre une backup à mon avis

je pense que ca va finir comme ca...

[Bosquetia]

Heureusement que ça ne pouvait pas être un souci réseau

[Wedge34]

Heureusement que ça ne pouvait pas être un souci réseau

j'aurais confirmation ce soir en reinstallant le raspberry, mais je ne le pense toujours pas.
y a une couille coté raspberry, mais je vois pas.
je vous tiendrais au courant

[Wedge34]

Bon suite et fin.
j'ai réinstallé sur un autre SSD pour eviter les problemes de disque corrompu ou autre.
en passant par la carte réseau du raspberry en local (pour faire l'installation) je me suis fait déco plusieurs fois, pourtant aucune erreur de paquet
des que je suis passé en wifi je n'ai plus eu les déco.
des la finalisation de l'installation, Jeedom était bien accessible depuis l'exterieur / interieur en http/https

du coup je suis perplexe... une carte réseau defectueuse ? mais sans perte de paquets ??? une conf pourrie ?

En toucas avec le backup jeedom, ca a été rapide, juste le temps de refaire le certificat avec renew auto, installer exim pour les mails et mettre en place le DMARC/DKIM et tout roule comme avant.



Merci a tous pour vos conseils et idées

[bartounet]

Tant mieux.
Tu sais quelquefois, passé 2 ou 3 jours de recherches, la réinstallation est plus productive

[Wedge34]

Tant mieux.
Tu sais quelquefois, passé 2 ou 3 jours de recherches, la réinstallation est plus productive

tu a 100% raison, surtout que ca m'a permis de faire une clean install et de bien faire les choses au propre sur la partie SSL et DKIM

Merci encore