Déjà, comme toujours, je tiens à vous remercier du boulot que vous abattez et pour le résultat que représente Yunohost !
C’est génial qu’un outil comme celui-ci existe et pour de nombreuses raisons !
Mon serveur YunoHost
Matériel: VPS acheté en ligne – fournisseur Milkywan Version de YunoHost: 4.3.6.2 (stable) J’ai accès à mon serveur : En SSH & Par la webadmin Êtes-vous dans un contexte particulier ou avez-vous effectué des modificiations particulières sur votre instance ? : non
Description du problème
Situation problématique
Depuis que j’ai ce VPS (quelques mois), et que j’ai ajouté mes domaines, tous les outils yunohost m’indiquent que mon IP est XXXXX, alors qu’en fait l’IP qui m’a été attribuée par mon hébergeur et celle que j’obtiens lorsque je fais un ping de mon nom de domaine est YYYYYY.
Sachant que l’adresse XXX n’est pas hasardeuse, c’est une adresse du datacenter chez qui je suis (un routeur, un hyperviseur, je ne sais pas)
En regardant un peu, j’ai retrouvé que c’est ip.yunohost.org qui identifie cette mauvaise adresse.
J’imagine que le hic se trouve dans la config de mon hébergeur qui a dû configurer son réseau d’une certaine manière et le soft qui tourne sur ip.ynh.org n’apprécie pas.
Conséquences
Tout Yunohost râle en disant que ma config DNS n’est pas bonne (et bah si), donc diagnostiques en vrac
Le renouvellement des certificats Let’s Encrypt est tout aussi cassé étant donné que “ma config DNS est mauvaise”
et maintenant ?
Est-ce qu’il est possible de bypasser légitimement le résultat de ip.yunohost.org ? J’imagine que non…
Est-ce que vous imaginez qu’il est possible de corriger le comportement de ip.yunohost.org ? J’aurai bien jeter un oeil au code, mais je n’ai identifié où le trouver.
Ma seule solution (temporaire j’espère) est-elle d’ignorer les diagnostiques puis de renouveller les certificats à la main ? Voire même de bidouiller les scripts ynh pour bypasser de manière bien sale ip.yunohost.org
Logs
Pas de logs à transmettre, les commandes se passent sans erreur
Je ne crois pas que vous puissiez reproduire facilement mon problème… Mais si jamais quelque chose est possible selon vous et qu’il manque des infos (nom de domaine par exemple) ou que vous aimeriez qu’on se synchronise pour regarder ensemble, n’hésitez pas à demander !
Mon avis: l’outil ip.yunohost.org a moins d’être piraté, ne peux pas se tromper sur l’ip publique qui te sers pour faire des requêtes vers internet.
Cependant, il est possible que tu as plusieurs IPs publiques.
Est-ce que avec ip a tu vois plusieurs ip publique ?
Je suis presque sûr qu’on ne gère pas bien ce cas.
Ce serais bien de nous dire si on parle en ipv6 ou en ipv4.
Avoir le premier numéro de chaque IP serait aussi un plus… (au cas où il s’agit d’ip locale en 192.168. ou 10. ou 172.)
Pour let’s encrypt si tu es sûr de ton coup, tu peux utiliser l’option --no-checks
On parle d’ipv4, au niveau ipv6, Yunohost ne râle pas et je crois que tout est bon
ip a me donne
en lo → la boucle locale 127 et en inet ma bonne IP qui commence en 45. mais pas la mauvaise adresse qui est en 80.
Pour inet6 pareil, j’ai ma bonne ipv6 et ma boucle locale
en eth0 → deux adresses (locales ?) que je ne connais pas en 10. et 2a0b ET une deuxième ipv6 en fe80
Et oui pour le no-checks c’est déjà ce que je fais en contournement, merci pour l’indication
A mon avis ça peut quand même être un problème si tes paquets sortent au nom de l’ip 80 mais que pour que les paquets entrent il faut s’adresser à l’ip 45…
Faudrait poser la question au support de ton VPS idéalement en expliquant que c’est un soucis pour toi que ce ne soit pas identique.
Autre exemple, le diag distant de yunohost refusera de diagnostiquer une ip sur demande d’une autre ip, seule l’ip d’origine peut se diagnostiquer (c’est peut être un peu plus complexe que ça, mais bon je doute qu’on supporte ton cas).
Enfin, il s’agit peut être d’une erreur de ton fournisseur, peut être que logiquement les ips sont censés être les mêmes ?
Personnellement je n’ai pas de problèmes en ipv4 mais ip6.yunohost.org me retourne l’ip de mon HOST qui héberge un container lxd avec une interface réseau de type macvlan.
cela cause des erreurs dans l’interface de diagnostique et je ne sais pas vraiment comment résoudre cela.
J’accède parfaitement a mon ynh depuis un navigateur avec l’[ipv6] du container et bien sur je ne peu pas y accéder avec l’ipv6 du host
resolu pour moi. sur mon containeur j’avais une interface ipv6 suplémentaire qui trainait. je l’ai supprimé,
root@home:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
6: eth0@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00::::ed brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet 192.168.XX.231/24 brd 192.168.0.255 scope global dynamic eth0
valid_lft 42530sec preferred_lft 42530sec
inet6 XX::::ed/64 scope global dynamic mngtmpaddr
valid_lft 86120sec preferred_lft 86120sec
inet6 fe80::::ed/64 scope link
valid_lft forever preferred_lft forever
7: eth1@if8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether ::::c2 brd ff:ff:ff:ff:ff:ff link-netnsid 0
inet6 fd42:::c2/64 scope global dynamic mngtmpaddr
valid_lft 3498sec preferred_lft 3498sec
inet6 fe80::::c2/64 scope link
valid_lft forever preferred_lft forever
root@home:~# ip link delete eth1
