Nicosss

Je suis désolé, j’ai tout mis à la suite parce que je n’arrive pas à mettre le code dans des pays différents. Je te rappelle que je suis sûr un mobile et c’est vraiment galère.

[jf@localhost ~]$ dig @80.10.246.136 orange.fr

; <<>> DiG 9.18.15 <<>> @80.10.246.136 orange.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53439
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 75f23d13e334130a01000000648ec316a89e2e1e16f07e49 (good)
;; QUESTION SECTION:
;orange.fr.			IN	A

;; ANSWER SECTION:
orange.fr.		319	IN	A	193.252.148.192
orange.fr.		319	IN	A	193.252.133.20
orange.fr.		319	IN	A	193.252.117.145

;; Query time: 12 msec
;; SERVER: 80.10.246.136#53(80.10.246.136) (UDP)
;; WHEN: Sun Jun 18 10:40:52 CEST 2023
;; MSG SIZE  rcvd: 114
[jf@localhost ~]$ dig @81.253.149.6 orange.fr

; <<>> DiG 9.18.15 <<>> @81.253.149.6 orange.fr
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12990
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9d81807ff7f7e55c01000000648ec31d492a2b7bb3cf2e79 (good)
;; QUESTION SECTION:
;orange.fr.			IN	A

;; ANSWER SECTION:
orange.fr.		1032	IN	A	193.252.133.20
orange.fr.		1032	IN	A	193.252.117.145
orange.fr.		1032	IN	A	193.252.148.192

;; Query time: 15 msec
;; SERVER: 81.253.149.6#53(81.253.149.6) (UDP)
;; WHEN: Sun Jun 18 10:40:59 CEST 2023
;; MSG SIZE  rcvd: 114
[jf@localhost ~]$ cat /etc/resolv.conf
# 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 .
[jf@localhost ~]$ systemctl status systemd-resolved.service
● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Sun 2023-06-18 10:32:53 CEST; 9min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 975 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 18958)
     Memory: 8.4M
        CPU: 410ms
     CGroup: /system.slice/systemd-resolved.service
             └─975 /usr/lib/systemd/systemd-resolved

juin 18 10:34:25 localhost.localdomain systemd-resolved[975]: Using degraded feature set TCP instead of UDP for DNS ser>
juin 18 10:34:25 localhost.localdomain systemd-resolved[975]: Using degraded feature set UDP instead of TCP for DNS ser>
juin 18 10:34:32 localhost.localdomain systemd-resolved[975]: Using degraded feature set TCP instead of UDP for DNS ser>
juin 18 10:34:32 localhost.localdomain systemd-resolved[975]: Using degraded feature set UDP instead of TCP for DNS ser>
juin 18 10:34:45 localhost.localdomain systemd-resolved[975]: Using degraded feature set TCP instead of UDP for DNS ser>
juin 18 10:34:45 localhost.localdomain systemd-resolved[975]: Using degraded feature set UDP instead of TCP for DNS ser>
juin 18 10:35:00 localhost.localdomain systemd-resolved[975]: Using degraded feature set TCP instead of UDP for DNS ser>
juin 18 10:35:00 localhost.localdomain systemd-resolved[975]: Using degraded feature set UDP instead of TCP for DNS ser>
juin 18 10:39:57 localhost.localdomain systemd-resolved[975]: Using degraded feature set TCP instead of UDP for DNS ser>
juin 18 10:39:57 localhost.localdomain systemd-resolved[975]: Using degraded feature set UDP instead of TCP for DNS ser>

Edit Nicosss : Mise en forme bloc code

    nouvo09

    J’ai remplacé la ligne des DNS par seulement 8.8.8.8

    Et…… bah ça marche pô.

      En tout cas je vous remercie beaucoup les gars pour votre aide et votre patience. Mais c’est un truc de fou et je sature un peu là. Je fais une pause. À plus tard.

        NeoType En résumé, ta Box fonctionne et tu as bien accès aux internets via celle-ci, les DNS Orange répondent aussi.

        Cependant la résolution DNS locale semble poser problème.
        Ton fichier /etc/resolv.conf contient bien les bonnes informations (c’est un lien symbolique pour information).

        Je suis plus intrigué par le service systemd-resolved.service qui semble patauger dans la semoule.
        Que retourne
        $ cat /etc/systemd/resolved.conf
        $ resolvectl status
        $ resolvectl query orange.fr
        $ journalctl -b -u systemd-resolved.service

        Après je suspecte grandement la connexion créée par ProtonVPN pour protéger des fuites via IPv6 de poser problème.
        Tu peux essayer de la couper pour voir
        $ nmcli connection down pvpn-ipv6leak-protection

          C’est très probable que proton ait flingué quelque chose.

          Comment as tu installé protonvpn et comment l’as tu désinstallé?

          $ dnf list installed | grep proton

          $ ls -ld /usr/lib/python3.*/site-packages/proton*

          sur le site de protonvpn il est recommandé de bien killer avant de désinstaller:

          $ nmcli connection show --active

          Après cette commande vérifie la présences de connexions pvpn-killswitch, pvpn-ipv6leak-protection et peut-être pvpn-routed-killswitch puis

          $ nmcli connection delete [les applis ci-dessus]

            $ cat /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=
#FallbackDNS=
#Domains=
#DNSSEC=no
#DNSOverTLS=no
#MulticastDNS=no
#LLMNR=resolve
#Cache=yes
#CacheFromLocalhost=no
#DNSStubListener=yes
#DNSStubListenerExtra=
#ReadEtcHosts=yes
#ResolveUnicastSingleLabel=no
            $ resolvectl status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
       DNS Servers: ::1

Link 2 (eno1)
    Current Scopes: LLMNR/IPv4
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported

Link 3 (wlp0s20f3)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported

Link 4 (ipv6leakintrf0)
    Current Scopes: DNS
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
Current DNS Server: ::1
       DNS Servers: ::1
        DNS Domain: ~.

Link 5 (virbr0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS
                    DNSSEC=no/unsupported
            $ resolvectl query orange.fr
orange.fr: resolve call failed: Lookup failed due to system error: Connection refused
            $ journalctl -b -u systemd-resolved.service
juin 19 01:28:33 localhost.localdomain systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
juin 19 01:28:33 localhost.localdomain systemd-resolved[987]: Positive Trust Anchors:
juin 19 01:28:33 localhost.localdomain systemd-resolved[987]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
juin 19 01:28:33 localhost.localdomain systemd-resolved[987]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa corp home internal intranet lan local private test
juin 19 01:28:34 localhost.localdomain systemd-resolved[987]: Defaulting to hostname 'fedora'.
juin 19 01:28:34 localhost.localdomain systemd[1]: Started systemd-resolved.service - Network Name Resolution.
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: ipv6leakintrf0: Bus client set search domain list to: ~.
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: ipv6leakintrf0: Bus client set default route setting: yes
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: ipv6leakintrf0: Bus client set DNS server list to: ::1
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server ::1.
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 01:28:35 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.
juin 19 01:28:38 localhost.localdomain systemd-resolved[987]: eno1: Bus client set default route setting: no
juin 19 01:28:38 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 01:28:38 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.
juin 19 01:28:38 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 01:28:38 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.

...

juin 19 01:54:28 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.
juin 19 02:27:54 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 02:27:54 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.
juin 19 02:55:40 localhost.localdomain systemd-resolved[987]: Clock change detected. Flushing caches.
juin 19 02:55:40 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 02:55:40 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.
juin 19 02:55:41 localhost.localdomain systemd-resolved[987]: Using degraded feature set TCP instead of UDP for DNS server ::1.
juin 19 02:55:41 localhost.localdomain systemd-resolved[987]: Using degraded feature set UDP instead of TCP for DNS server ::1.

...

            Tout ça dépasse largement mes compétences !
            Je ne sais pas vraiment ce que je fais à chaque fois que je lance une commande.

            Et finalement…

            nmcli connection down pvpn-ipv6leak-protection

            Verdict… tada !
            OK alors là on a progressé d’un pas de géant avec cette dernière commande.
            Ca me redonne accès à internet.

            Mais à chaque redémarrage, le problème se reproduit.

            Je passe maintenant à ce que propose xylphute. Mais j’y crois à fond maintenant ! ^^

              xylphute

              "C’est très probable que proton ait flingué quelque chose.
              Comment as tu installé protonvpn et comment l’as tu désinstallé?"

              –> Via la logithèque Gnome dans les deux cas.

              $ dnf list installed | grep -i proton
Repository vivaldi is listed more than once in the configuration
              $ ls -ld /usr/lib/python3.*/site-packages/[pP]roton*
ls: impossible d'accéder à '/usr/lib/python3.*/site-packages/[pP]roton*': Aucun fichier ou dossier de ce type

              –> A ce stade, j’ai redémarré la machine pour me replacer dans les conditions initiales d’internet inaccessible. (voir ma réponse précédente à Nicosss)

              $ nmcli connection show --active
NAME                      UUID                                  TYPE      DEVICE         
Connexion filaire 1       27b9beb7-d1fe-3a27-856f-7840e960e95a  ethernet  eno1           
pvpn-ipv6leak-protection  08984aef-1280-4cbe-a0e7-bbdae48797df  dummy     ipv6leakintrf0 
lo                        d067c3b7-5d4f-4d29-b3ef-bd5ff43b4adf  loopback  lo             
virbr0                    2c12183c-e73f-4b2d-b59c-e754fabd48c2  bridge    virbr0

              "Après cette commande vérifie la présences de connexions pvpn-killswitch, pvpn-ipv6leak-protection et peut-être pvpn-routed-killswitch puis

              $ nmcli connection delete [les applis ci-dessus]"

              $ nmcli connection delete pvpn-ipv6leak-protection
Connexion « pvpn-ipv6leak-protection » (08984aef-1280-4cbe-a0e7-bbdae48797df) supprimée.

              –> Je redémarre pour voir. Et le problème semble bel et bien résolu cette fois !

              Mon petit bilan perso de cette mauvaise aventure:

              1/ Déjà merci énormément pour votre aide et à Nicosss en particulier qui y a passé énormément de temps un dimanche matin.

              2/ J’ai réellement besoin d’un VPN et pas seulement via une extension de navigateur (style Browsec VPN ou Touch VPN).
              C’est un besoin ponctuel mais réel. Avec Proton VPN, j’ai pris ce que proposait la logithèque de Gnome/Fedora. Ca me semblait une bonne idée.

              3/ VINDICATORs proposait de regarder du côté de wireguard, je ne connais pas cette solution.

              4/ Pour éviter de nouveau d’être confronté à ce genre de soucis, j’envisage désormais de dédier une machine virtuelle à ça.
              Pb: que ce soit avec VirtualBox ou Machines, je n’ai jamais réussi à installer les addons sur une machine virtuelle sous Linux et configurer un partage de répertoire.
              Sous une machine virtuelle Windows, oui, mais pas Linux.
              Ce qui limite l’intérêt de la chose pour moi.

              5/ J’envisage donc depuis quelques temps déjà d’installer (à terme) une Debian sur un deuxième disque et Proxmox par dessus. (puisque il n’est malheureusement pas possible de le faire sous Fedora)
              Pour voir, si j’ arrive mieux à dépatouiller. Ce qui me promet encore bien des aventures à mon avis et beaucoup de temps passé mais bon. Qui ne tente rien n’a rien. (et n’apprend rien non plus)

              Pourquoi ne pas dédier une autre machine à Proxmox ? Parce que je n’en ai qu’une et je n’ai pas l’intention d’en acheter une deuxième pour le moment. D’où la solution bancale d’installer une Debian et Proxmox par dessus (à la façon d’un VirtualBox).

              –> N’hésitez pas à me donner vos avis persos sur tout ça, ça m’intéresse beaucoup.

                  https://fedoramagazine.org/?s=wireguard

                  Mais bon c’est du VPN à monter sur une machine chez soit…

                  wireguard est intégré au noyau, après il faut un peu manipuler à la main pour avoir qqchose de fonctionnel.

                  Les articles de fedoramag l’explique quand même très bien. Surtout celui avec NetworkManager (depuis que c’est intégré dans le noyau).

                    VINDICATORs
                    Intéressant mais si j’ai bien compris, il faut avoir la main sur les deux points de la connexion. Intéressant pour du tunnelling entre deux points d’une même structure au sein de l’internet par exemple mais ça ne me semble pas répondre vraiment à mon besoin.

                      NeoType Sur ce point on a contrôlé le contenu de la configuration du résolveur DNS local, qui est correcte.

                      Ensuite on a utilisé des commandes pour interroger directement le résolveur DNS local pour connaître son statut pour toutes les interfaces et réalisé une requête.

                      Ensuite on a consulté les logs depuis le démarrage concernant le service qui fait tourner le résolveur DNS local.
                      De là on voit que la fameuse connexion pvpn-ipv6leak-protection redirige toutes requêtes DNS locale vers ::1 (soit la machine locale).

                      Puis on a désactivé cette fameuse connexion pvpn-ipv6leak-protection, ce qui a permis de ne plus rediriger l’ensemble des requêtes DNS locales vers la machine locale mais vers les serveurs DNS renseignés.

                      NeoType Il faut sélectionner la meilleure réponse pour passer cette discussion en résolu.
                      Je t’invite à en ouvrir une autre si tu as d’autres questions afin de faciliter les recherches par la suite, même si tu fais référence à celle-ci au pire pour ne pas tout répéter.

                      NeoType
                      1/ Pas de souci, tu as aussi bien participé en nous expliquant ce que tu avais fait et en mettant tout ça en forme pour nous faire gagner du temps.

                      2/ Un VPN ce n’est pas la solution miracle. Il faut savoir ce que l’on veut en faire et pour quelles raisons. La solution ProtonVPN doit fonctionner mais peut-être qu’il y a eu une erreur de manipulation au passage.

                      3/ Wireguard est à la fois un outil et un protocole pour créer un VPN. Donc à toi de trouver une hébergement où tu veux te trouver une sortie par exemple.

                      4/ Peut-être un peu d’aide https://doc.fedora-fr.org/wiki/VirtualBox_:_installation,_configuration,_utilisation et pour Machines https://apps.gnome.org/fr/app/org.gnome.Boxes/ .

                      5/ Et pourquoi pas simplement virt-manager https://doc.fedora-fr.org/wiki/Virtualisation_:_KVM,_Qemu,_libvirt_en_images (plus très à jour) ou https://virt-manager.org/ ?

                      Voilà, n’hésite pas à ouvrir des discussions pour chaque sujet pour éviter de s’y perdre.

                            Bien sur. C’est aussi utilisé chez point cardinal vpn et d’autres.

                            Un chti kimsuffi et hop… voir un chti vps ici où là…

                            Et pourvles solutions de virtualisation y a tous ce qu’il faut sous fedora et autres sans cherchez très loin comme dit au dessus…

                            J’ai monté, par exemple, un ensemble de kvm/qemu sur trois machines physique distante( avec gestion des trois hyperviseurs avec 1 virt-manager) qui communique très bien ensemble. Faut juste faire mumuse avec les tables de routages côté réseau physique… et un clusters kubernetes dans des VM avec du ceph pour le stockage (je vous laisse chercher ce que c’est). Je prépare une chtite procédure sur le sujet pour celles et ceux que cela peut intéressée.

                            NeoType Je ne trouve pas comment on passe le sujet en [résolu] ?

                            Tu choisis parmid le fil la réponse qui te semble la meilleure, du moins celle qui a résolu le problème et ça marquera le sujet en résolu.

                            En tout cas bon retex pour tous, proton bon laisse des cochonneries derrière lui quand il est désinstallé. Mais ils en parle sur leur propre site. C’est dommage que ça ne soit pas automatisé.