Ubuntu-fr

VBPix84

Réécriture d'URL instable sur DNS perso

Bonjour à tous !

Je découvre Ubuntu et je fête ma semaine et demi sur Linux ! Je bloque sur un sujet qui commence a être important (outre des histoires de raccourcis sorties audio, ce n'est pas le sujet !) et malgré plusieurs lecture, je trouve des infos qui s'opposent... Donc je viens vers vous ! (Je vais décrire un peu tout et surement mettre trop d'infos inutiles et pas assez celles qui seraient utiles... mais vous m'en excuserez j'espère ! J'ai pas encore l'expertise pour savoir ce qui est - ou non - important )

Tout d'abord, mon installation

J'ai un serveur Debian avec des containers Docker dont AdGuard qui effectue une réécriture de DNS sur mon sous-domaine pour accéder aux autres services docker via ce sous domaine. Par exemple : nodered.<sous-domaine>.fr qui devient donc 192.168.1.3:1880, passant par traefik.

Le DNS est spécifié dans ma box free et cela fonctionne sans soucis pour tous mes devices (PC windows, téléphones iOS et Android) sauf mon PC flambant neuf sous Ubuntu. Sachant que ce PC est en dualboot avec windows et que, sur le boot windows, tout fonctionne bien, j'ai isolé ce qui semble être le soucis : La configuration Ubuntu ! (j'ai le problème sur Firefox et Chrome, donc ça semble ne pas être le navigateur).

Le soucis...

Les sites en réécriture d'url ne fonctionnent pas... et le seul moyen que cela fonctionne est de passer par un restart de system-resolved.service :

systemctl restart systemd-resolved.service

Ce qui me donne accès à la réécriture pendant environ 2 à 5 minutes, ensuite c'est repartie pour une erreur...

Ce que j'ai tenté... (Liste non exhaustive)

- Ajouter les DNS via l'interface Gnome : Paramètres > Wi-Fi > "Roue crantée" du wifi > IPv4 > "DNS". Pas d'effet, même après redémarage.
- Modifier le fichier "/etc/resolv.conf" que voici :

# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

Je ne dois pas l'éditer selon ce qu'il me demande.

J'ai aussi regardé le fichier /etc/systemd/resolved.conf :

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it under the
#  terms of the GNU Lesser General Public License as published by the Free
#  Software Foundation; either version 2.1 of the License, or (at your option)
#  any later version.
#
# Entries in this file show the compile time defaults. Local configuration
# should be created by either modifying this file, or by creating "drop-ins" in
# the resolved.conf.d/ subdirectory. The latter is generally recommended.
# Defaults can be restored by simply deleting this file and all drop-ins.
#
# Use 'systemd-analyze cat-config systemd/resolved.conf' to display the full config.
#
# See resolved.conf(5) for details.

[Resolve]
# Some examples of DNS servers which may be used for DNS= and FallbackDNS=:
# Cloudflare: 1.1.1.1#cloudflare-dns.com 1.0.0.1#cloudflare-dns.com 2606:4700:4700::1111#cloudflare-dns.com 2606:4700:4700::1001#cloudflare-dns.com
# Google:     8.8.8.8#dns.google 8.8.4.4#dns.google 2001:4860:4860::8888#dns.google 2001:4860:4860::8844#dns.google
# Quad9:      9.9.9.9#dns.quad9.net 149.112.112.112#dns.quad9.net 2620:fe::fe#dns.quad9.net 2620:fe::9#dns.quad9.net
#DNS=192.168.1.3 9.9.9.9
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=no
#Cache=no-negative
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no

Et donc la question !

Je me demandais donc s'il n'y avait pas un système qui réécrivait quelque chose et ne gardait pas en mémoire qu'il convient d'utiliser le serveur DNS que lui donne la connexion wifi ? (Qui peut d'ailleurs changé dans le cadre d'un PC portable...).

Merci par avance, je vous avoue que je nage un peu à ce sujet !

Vincent

Dernière modification par VBPix84 (Le 11/05/2023, à 16:32)

krodelabestiole

Re : Réécriture d'URL instable sur DNS perso

adguard ça a l'air d'être un genre de pi-hole...

a priori c'est au niveau du serveur dhcp qu'on indique le serveur dns à utiliser. // edit : ok, oui tu parles de ta box free, tu y as indiqué quoi exactement comme serveur dns ?

ça me paraît un peu tordu de mettre adguard derrière traefik, ou alors faut faire un entrypoint spécifique pour ce seul service de résolution DNS sur le port 53, c'est un peu absurde...
traefik c'est surtout utile pour tous les services web sur les ports 80 et 443 je dirais...

tu es sûr que ça marche en dehors de ton problème de 5 min ? (les requêtes passent bien par adguard ?)

Dernière modification par krodelabestiole (Le 11/05/2023, à 16:42)

---

nouveau forum ubuntu-fr on en parle là : refonte du site / nouveau design
profil - sujets récurrents - sources du site

VBPix84

Re : Réécriture d'URL instable sur DNS perso

Salut !

Ouep, AdGuard est un genre de Pi-Hole. Il est en direct sur le bon port via l'adresse IP (c'est l'adresse IP du serveur où est installé AdGuard qui est renseigné dans les DNS de la box.

Le passage par Traefik est utilisé pour accéder au services, notamment via le nom de domaine :

Sous-domaine > Box > DNS Adguard > Réécriture avec l'IP du serveur > Réception par Traefik > Redirection sur le bon service

Je suis sûr que le système fonctionne sur tous mes devices et sur linux pendant 2 à 5 min (parfois un peu plus) car j'ai bien accès via ne sous-domaine, puis plus rien. Typiquement j'ai relancé quand j'ai lancé le post, là j'ai un beau "Hum, nous ne parvenons pas à trouver ce site.". Si je restart systemd-resolved.service, ca revient...

Vincent