[Résolu] Raspberry inaccessible depuis l'exterieur

Bonjour,
J’ai récemment configurer une Raspberry comme serveur web à l’aide d’apache2. J’y ai développé un site web. J’ai ouvert les ports 80 et 443, générer un certificat SSL, connecté un service de nom de domaine, etc… Cela dit, j’ai, à un moment, voulu m’inscrire sur Google pour y apparaitre. Et c’est là que je m’aperçois que google ne peut pas accéder a mon site. Je trouve cela intrigant, j’attends donc quelques et jours et réessais ; toujours rien, j’essais donc avec un VPN depuis mon téléphone et je m’aperçois que NON, ça ne fonctionne pas !
J’ai cherché un peu sur Internet et je n’ai rien trouvé de bien concret, sans compté que je peux y accéder depuis l’extérieur, avec ma 4G, cela fonctionne et des amis ont très bien put s’y connecter, je me demande donc ce qui fait que l’on ne peut pas se connecter dans certains cas.
Le service dnschecker.org m’indique que la résolution dns est bonne sur la quasi totalité des serveurs (sauf Monterrey)

Cela est assez problématique pour moi et je chercherais à résoudre cela assez rapidement car c’est contraignant de ne pas pouvoir apparaitre sur google.

Je vous remercie d’avance pour vos réponse et reste à votre disposition si vous avez des questions particulières sur ma configuration !

Si tu as un IP dynamique, il est normal que ce genre de cas ce produise. Un changement de IP sur un HOST (DNS) peut prendre 72 heures à affecter l’ensemble d’internet. Après, si le cache DNS à déjà un IP associé, mais qui serais mauvais, peut alors prendre du temps avant que le système actualise le cache.

Ce genre de problème arrive avec un DNS mal configuré et un TL mal configuré. Et la ont tombe sur la gestion d’une table de DNS pour un domaine, et en plus, ton DNS Dynamique, si tu en as un.

Après, certain système vont donner une erreur si le serveur ne répond pas dans un temps impartie. Google par exemple lui a une protection supplémentaire; il refuse en grande partie le IP provenant de connexion de particulier, pour éviter justement des cas de piratage et fraude. Car techniquement, ton fournisseur de service ne veux pas que tu puisse gérer des services Web dans un usage « commercial ». Certain ISP vont également filtrer, voir bloquer, les connexions aux ports 21 (FTP), 22 (SSH), 53 (DNS), 80 (HTTP), 443 (HTTPS), 6666-6670 (IRC), 7000 (IRC), 8000 (SHOUTCAST), …


Idéalement, configure le « domaine.com » sur un CNAME avec un TL de 3600s au lieu de la valeur par défaut, ce qui force le rafraichissement du cache plus rapide et informe aux serveurs de gestion des NS que ce host aura une variation d’IP rapide. Le CNAME est associé au DNS de chez vous, si tu utilise un service qui te le permet, ajustement également le TL de ce HOST à un délais plus court.

Après, assure toi que ton Firewall réponde correctement au port 53 et que tu as une table de DNS valide et en bonne forme. Activer le UDP peut également aider sur ces ports. Assure toi aussi que le NAT du routeur marche bien et qui peut répondre sur tout les ports, et que le Firewall soit en mesure de le gérer.

Ceci est purement de la configuration réseau/internet et exige une bonne expertise pour bien gérer le tout. J’évite pas mal de détails et d’informations pour pas alourdir la réponse. mais assure toi que ta table de DNS, les TL et l’ensemble des configurations soit fiable et bien configuré.

Hello,
En plus des bonnes réflexions postées par @levelKro ; juste une question :
Certificat autogénéré ?

Perso, j’ai des noms de domaine chez OVH qui pointent chez moi.
J’utilise YunoHost pour du Nextcloud, du Lychee, du site web (différents moteurs), … Mes domaines intégrés à Yunohost sont dotés (chacun) d’un certificat LetsEncrypt et tout est forcé en https.
Je crois que google ne veut plus voir de http (80) mais uniquement du https (443).
Peut-être une piste ?

++

Merci à vous pour vos réponses,
suite à ces dernières j’ai effectué quelques recherches sur ce que vous m’avez conseillé, le problème étant que j’utilise une majorité de logiciel gratuits, mon fournisseur de nom de domaine étant no-ip, il n’y a pas d’option pour le CNAME ou le TL. Je suis donc allé voir sur le web et j’ai trouvé Cloudflare qui a l’air de présenter des avantages quant à ces options, j’ai entamé la procédure pour connecter mon site et j’attends que tous soit validé. Du coté du pare-feu et du NAT pas de problème, tous est ouvert comme il faut, le UDP fonctionne aussi !
Je vais donc attendre que Cloudflare m’enregistre puis je reviendrais vers vous !!

Merci pour vos réponses en tout cas :slight_smile:

Bonjour à tous, après inscription sur cloudflare et ajout de mon site, il ne s’est rien passé, j’ai pourtant bien engagé la redirection de mon url vers le service cloudflare : quand je tape mon url, cela me fait une erreur 1001. J’ai donc attendu 4 jours (où il est censé en falloir 1 seul normalement) mais aucun résultat, avez une idée, une suggestion ou peut être une autre méthode avec un autre service ?

A bientôt !

Fait un Traceroute depuis chez vous.

Lance PowerShell (ou le prompt de commande Windows) et tappe;

tracert tonsite.com

Tu va voir quel communication qui effectue pour trouver la cible, et ou il plante. Désactive le Cloudfare sinon tu n’auras pas de bon résultat (ou utilise un DNS qui pointe pas sur cloudflare).

Exemple avec mon site;

tracert levelkro.net

Détermination de l’itinéraire vers levelkro.net [163.172.39.96]
avec un maximum de 30 sauts :

  1    <1 ms    <1 ms    <1 ms  SAGEMCOM [192.168.2.1]
  2    17 ms    16 ms    15 ms  10.11.17.121
  3     *        *        *     Délai d’attente de la demande dépassé.
  4    20 ms    20 ms    19 ms  10.115.51.201
  5     *        *        *     Délai d’attente de la demande dépassé.
  6    30 ms    30 ms    29 ms  64.230.36.68
  7     *        *        *     Délai d’attente de la demande dépassé.
  8    27 ms    27 ms    27 ms  64.230.78.183
  9     *        *        *     Délai d’attente de la demande dépassé.
 10   109 ms   108 ms   109 ms  ae2.3211.edge7.par1.neo.colt.net [171.75.9.205]
 11   109 ms   110 ms   111 ms  212.3.235.202
 12   123 ms   109 ms   112 ms  51.158.8.185
 13   110 ms   113 ms   109 ms  195.154.2.195
 14   110 ms   110 ms   109 ms  op-paris-01.levelkro.net [163.172.39.96]`

Itinéraire déterminé.

Plus de ~16 HOPS, tu as un mauvais réseau.

Voici un Trace Route généré pour une config similaire a toi, soit un pointage vers le IP de chez nous.

(En passant il est dynamique, alors ce IP n’est plus valide, je masque par sécurité)

tracert <masqué>.levelkro.net

Détermination de l’itinéraire vers <masqué>.levelkro.net [104.195.195.<masqué>]
avec un maximum de 30 sauts :

  1     1 ms     8 ms    <1 ms  192.168.2.1
  2    20 ms    16 ms    16 ms  10.11.17.121
  3     *        *        *     Délai d’attente de la demande dépassé.
  4    26 ms    29 ms    29 ms  64.230.36.70
  5    26 ms    25 ms    25 ms  142.124.127.248
  6    29 ms    33 ms    38 ms  142.124.127.206
  7    23 ms     *       23 ms  64.230.51.160
  8    23 ms    24 ms    24 ms  64.230.97.169
  9    29 ms    24 ms    37 ms  67.71.203.122
 10    24 ms    24 ms    24 ms  206-248-153-52.dsl.teksavvy.com [206.248.153.52]
 11    25 ms    24 ms    24 ms  ae0-0-bng02-tor1.teksavvy.com [206.248.153.39]
 12    49 ms    49 ms    53 ms  <masqué>.cpe.teksavvy.com [104.195.195.<masqué>]

Itinéraire déterminé.

Test effectué depuis mon lieu de travail

Alors, j’ai fais le tracert, et j’ai obtenu ceci (j’ai anonymisé les noms DNS et les IP) :

avec un maximum de 30 sauts :

  1     4 ms     3 ms     3 ms  [IP du routeur local]
  2    75 ms    62 ms    63 ms  [IP du routeur FAI]
  3     *        *        *     Délai d’attente de la demande dépassé.
  4    68 ms     *       34 ms  2001:860:b211:5100::14:4
  5    34 ms    40 ms    36 ms  2001:860:b211:5100::15:2
  6    52 ms     *       37 ms  2001:860:b211:5100::11:4
  7    44 ms    42 ms    37 ms  2001:860:bbe0:cb::1
  8    55 ms    40 ms    39 ms  2001:860:bbee:bf::1
  9     *        *        *     Délai d’attente de la demande dépassé.
 10     *        *        *     Délai d’attente de la demande dépassé.
 11     *        *        *     Délai d’attente de la demande dépassé.
 12     *        *        *     Délai d’attente de la demande dépassé.
 13     *        *        *     Délai d’attente de la demande dépassé.
 14     *        *        *     Délai d’attente de la demande dépassé.
 15    41 ms    67 ms    59 ms  2a02-8400-0000-0003-0000-0000-0000-6925.rev.sfr.net [2a02:8400:0:3::6925]
 16    63 ms    61 ms    77 ms  2a02-842a-03b6-a301-0000-0000-0000-0001.rev.sfr.net [2a02:842a:3b6:a301::1]
 17    72 ms    55 ms    72 ms  2a02-842a-03b6-a301-5e96-42ba-640b-67f1.rev.sfr.net [2a02:842a:3b6:a301:5e96:42ba:640b:67f1]

Itinéraire déterminé.

Sachant qu’il y a plus de 16 sauts, je peux considérer mon réseau comme mauvais, mais comment remédier a cela ? Existe t-il un moyen ?

AHHHHHHHHHHHHHH

La réponse est que tu travail en IPv6,. c’est pour ça que rien marche, faut uniquement utiliser du IPv4.

Internet n’est pas conçu pour le IPv6, il faut faire des translation supplémentaire et Cloudflare tout comme Google n’aime pas ça.

Passe tout en IPv4 UNIQUEMENT et tout va marcher.

Ah. Je suis désolé de ne pas l’avoir mentionné plus tôt… Le problème est que on réseau fonctionne de partout en ipv6 (je pense que j’ai une ip partagée), donc quand je paramètre mon DNS avec l’ipv4, ça ne fonctionne pas. (Il n’y a même pas de redirection de port en ipv4 sur ma BOX, uniquement en ipv6…) Je crois qu’il faut que je contact mon FAI pour qu’ils me basculent en ipv4 de partout… Ca va pas etre facile je crois… :frowning:
A moins qu’il existe une autre solution ? Je vais les appeler et je vous dirais après !

Merci pour votre aide en tout cas !

Du nouveau !!
J’ai donc appeler mon opérateur et expliquer ce que je souhait (mettre le rollback en full stack pour le terme technique). Ils ont fait redémarrer la Box, et hop ! Le menu NAT pour ipv4 est apparut !! J’ai fait ma configuration DNS avec le DynDNS et en une demi-seconde google a crawler mes pages sur mon site !!

Merci beaucoup pour votre aide :slight_smile: !!

Et ça confirme en effet que les IPv6 ne sont pas implanté pour la résolution de domaine en mode production.

La vie est plus simple en IPv4 :slight_smile:

Bonjour,
Bientôt il n’y aura plus assez d’adresse IPV4, déjà un ,ombre important d’adresse IPV4 sont partagées entre plusieurs utilisateurs.
J’ai testé mon site en IPV6 et le seul serveur qui ne répond pas est celuis de Monterey Mexico

La pénurie de IPv4 à commencé voila déjà longtemps. Pour certains appareils, le IPv6 peut marcher sans problème, comme les serveurs pour du travail sans accès publique.

Pour convertir une adresse IPv6 en format compatible en IPv4 pour certaines applications, comme les navigateur, il suffit de mettre le IPv6 entre des « [ » et « ] ».

Seulement, le système DNS et de domaine gère très mal le IPv6, Bind, par exemple, a pris du temps à inclure correctement le format AAAA. Plusieurs enregistreurs de nom de domaine ont également tardé à ajouter ce support, et encore aujourd’hui, c’est limité parfois.

La table de DNS doit être sur un serveur IPv4 idéalement, car les entrées NS (Name Server) ne sont compatible que IPv4 (au dernière nouvelle). Car le IPv6 implique la MaJ de plusieurs matériel du réseau Internet actuel. Certes, les ajout et actualisation sont en mesure de prendre en charge, mais il reste des réseau qui tarderons à être actualisé, alors le IPv6 tarde à devenir la norme.

Il y a aussi encore de vieux OS sur Internet, pour qui le IPv6 est totalement inconnu, alors le rend incompatible.

Les fonctions IPv6 sont parfois désactivé de certains système ou logiciel par défaut car si le système ne le prend pas en charge correctement (par exemple ton fournisseur de service internet), tu peux avoir des problèmes de connectivité.

Par exemple, mon FAI, ne me fournis aucune adresse IPv6, et sous certaines versions de Debian, tenter d’accéder à des serveur GitHub en IPv6 est impossible. Mais sous Windows, sa reste possible, mais limité (vu la « traduction » du IPv6 en IPv4).

La solution est de retirer les adresses IP unique, quand ce n’est pas requis, comme par exemple sur les téléphones mobiles, surtout dans des services économique. Des clients comme les particulier, qui n’ont pas un réel besoin d’adresse IPv4, peuvent être mis sur des réseau IPv4 pour l’accès avec une passerelle de traduction en IPv4 gérer par le fournisseur d’accès.


Mais quand ont gère un serveur, le IPv4 est le seul moyen fiable et stable de le faire actuellement, surtout sur les vieux protocoles comme le HTTP.

Hello,

Merci pour ton retour.

IPv4 et IPv6 ; vaste projet où il devient urgent de ne pas se presser :sweat_smile:
Ça me fait penser à kcal (ou Cal) qui reste la norme d’utilisation alors que la norme internationale est kilojoules (kJ) depuis plus de… 50 ans.
Bref…

Je passe ton sujet en [Résolu] :wink: