Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Problème fuite DNS sur VPN (2 Serveurs DNS)

    Scheduled Pinned Locked Moved Français
    7 Posts 3 Posters 1.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wf
      last edited by

      Bonjour,

      J’ai un problème de fuite sur ma configuration avec CyberghostVPN.

      Je suis sur pfSense 2.6 (IPv4 uniquement)

      Lorsque je faite test vérification IP et Fuite DNS

      https://whoer.net/fr
      Test IP.jpg

      https://whoer.net/fr/dns-leak-test
      Test Fuite DNS.jpg

      Je n’arrive pas à ce que pfSense me sélectionne uniquement le Serveur DNS voulue, uniquement USA pour le VPN (Qui ne devrait même pas être visible normalement)

      Lorsque je désactive OpenVPN et refait le teste, je le même problème il me trouve le DNS USA qui ne devrait plus être présent.

      Ma configuration :
      Système > Configuration générale (Paramètres de serveur DNS)
      01 - Paramètres du serveur DNS.jpg
      Normalement, ci-dessus quand l’interface cyberghost est en court il doit sélectionner les DNS de cette même interface, et inversement pour WAN ?

      J’ai essayé avec l’option :
      Cocher : Remplacer le serveur DNS + Pull DNS (Dans client OpenVPN) ce qui avait l’aire de fonctionner hier, aujourd’hui cela ne fonctionne plus.

      Résolveur DNS - Paramètres généraux
      02 - Resolveur DNS - Paramètres généraux.jpg

      Résolveur DNS - Paramètres avancés
      03 - Resolveur DNS - Paramètres avancés.jpg
      Le reste est laissé par défaut

      Système > Routage > Passerelles
      04 - Routage - Passerelles.jpg
      J’ai testé Passerelle par défaut : en automatique cela ne change rien

      Nat – Sortant
      05 - Nat - Sortant 01.jpg

      06 - Nat - Sortant 02.jpg

      Pare-feu > Règles > LAN
      07 - Pare-feu - Règles - LAN.jpg

      OpenVPN – Client
      08 - OpenVPN 01.jpg
      08 - OpenVPN 02.jpg
      08 - OpenVPN 03.jpg
      08 - OpenVPN 04.jpg

      Statut – Service
      Statut - Service.jpg

      Merci d’avance pour votre future aide

      Cordialement

      J 1 Reply Last reply Reply Quote 0
      • J
        jdh @wf
        last edited by

        @wf
        On ne peut pas dire que vous ne fournissez pas d'informations.

        Vous avec un WAN réel et un WAN 'vpn'.
        Au niveau de pfSense, vous indiquez 4 DNS : 2 destinés à WAN réel (et au pfSense) et 2 fournis par le VPN.
        Ces DNS sont à usage unique de pfSense, donc ceux du VPN sont inutiles !

        Je ne vois aucune information sur le dns que vous donnez à vos clients (par DHCP) !

        Quel que soit le serveur dns choisi, celui-ci peut établir votre navigation, donc ce test est nul et ne fourni aucune information utile !

        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

        1 Reply Last reply Reply Quote 0
        • C
          couteauabeurre
          last edited by

          Bonjour,

          Je tente une réponse suivant ma vision de ta conf, comme l'évoque "jdh" il est inutile de mettre les ip des serveur cyberghost ici
          fd8d5bb4-a654-4195-a6ff-24295b46c9c8-image.png

          inutile car au sein du service DNS resolver, il est bon de maitriser de a à z sa configuration au lieu de cases à cocher cela évite des comportements non désirés (mais bon chacun ses choix)

          Pour spécifier directement les IPs vers lesquelles il faut forwarder et l interface :

          Tout d'abord désactive l'interface de sortie WAN du DNS resolver et laisse seulement l'interface de sortie de ton VPN

          décocher
          496290eb-14b5-427f-9a3f-01a10796261c-image.png

          ensuite spécifie dans la section "custom options" (cf https://linux.die.net/man/5/unbound.conf)

          server:
              private-address: 192.168.2.0/24
                  
              log-queries: yes
              log-replies:yes
              log-tag-queryreply:yes
          
              forward-zone:
                  name: "."
                  forward-tls-upstream: yes
                  forward-addr: 10.101.0.243
                  forward-addr: 38.132.106.139
          
          

          plein de variante de conf existe, il faut se référer à la doc
          Ici je chiffre mes requetes dns, dans ta conf je ne pense pas avoir vu de chiffrement donc test sans chiffrement avant tout (je n'ai pas testé la conf que je t'ai fourni)

          attention à la remontée d'information de ton network local vers les dns de ton fournisseur dns (ce qui est strictement local ou pas)

          1 Reply Last reply Reply Quote 0
          • W
            wf
            last edited by

            Bonjour,

            Un grand merci à vous deux.

            @couteauabeurre
            Super ton explication, je vais regarder a cela d’ici, 1 semaine ou 2, car j’ai énormément de retard sur autre projet.

            Je vous tiens informer du suivi et des résultats.

            J 1 Reply Last reply Reply Quote 0
            • J
              jdh @wf
              last edited by jdh

              @wf

              Je reviens sur le test dit 'de fuite dns' :

              • le test indique 'les requêtes DNS ne sont pas protégées. Les propriétaires de serveurs DNS peuvent suivre chaque site web que vous visitez et plus encore'
              • la phrase 2 est tellement évidente ... que cela ne permet aucunement de dire la phrase 1 !
                Je dis que ce type de test est 'attrape-nigauds' ...

              En France, si vous utilisez comme dns, le dns de votre fournisseur de ligne Internet (Orange, Sfr, Bouygues, Free), celui ci peut tracer vos requêtes dns ... comme n'importe quel dns.
              Mais, en plus, ces serveurs dns, français, sont soumis à la règlementation française, et ne vous fourniront pas certaines définitions dns, par exemple de sites pornos ou de sites de téléchargement.
              Les 'petits' malins auront tôt fait de choisir d'autres serveurs dns comme 8.8.8.8 (google) ou 1.1.1.1 (cloudflare), lesquels serveurs dns ... ne se gênent pas du tout pour suivre votre navigation : pas si 'malin' que çà !
              D'autres 'petits' malins pensent utiliser un 'vpn' pour 'anonymiser' leur navigation : leur navigation se fait alors avec une ip qui dépend d'un choix = sortie par le Canada ou l'Ouzbekistan, et le lien avec votre réelle ip ne dépend que du fournisseur de vpn, lequel ne vous assure pas s'il stocke ou non le lien !

              Ayant subit une cyber-attaque, j'ai bien compris qu'identifier une ip française est parfaitement possible (= courant, usuel), cela vaut aussi pour les ip européennes, mais pas russes ou chinoises par exemple !

              Dans la pratique, si vous avez un serveur dns local, seul à faire les requêtes pour tout votre réseau local (ce qui est une bonne pratique), le test vous dira 'les requêtes DNS sont protégées' (ou non) alors qu'il vous faut bien résoudre le dns quelque part en définitive !

              je reviens sur les 'bonnes pratiques' : à mon humble avis (AMHA = IMHO), dans la mesure, du possible,

              • avoir une seule machine interne qui fournit DNS (et DHCP et NTP) au réseau interne, est une bonne chose
              • que ce soit la seule machine à faire les requêtes DNS (et NTP), est une (très) bonne chose
              • la maitrise des mécanismes de DNS, DNS public/privé (split-DNS), DNSSEC, DNS over HTTPS est une bonne chose
              • utiliser un serveur dns externe (=forwarder) est à recommander : les root-servers ne devraient pas être accédés par tout le monde !
              • probablement, le serveur dns externe doit être joint via DNSSEC ou DNS over HTTPS

              La question est alors : quel serveur dns public utiliser, et pour quelle sécurité ?

              Un exemple de lien intéressant : https://www.kaspersky.fr/blog/secure-dns-private-dns-benefits/20191/
              NB : Bind9 ne propose le Dns Over HTTP qu'à partir de 9.17.10 (en 2021) : je ne sais pas si cela a été retro-porté en 9.16 (Debian 11) alors que ça fonctionne en Debian 12 ! (mon cas perso en Debian 11)

              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

              1 Reply Last reply Reply Quote 1
              • C
                couteauabeurre
                last edited by couteauabeurre

                Pour illustrer ce que dit @jdh
                Voici une conf DNS pour le DNS Resolver

                59539f24-e1cf-40ab-ac26-20e09f0a9173-image.png

                Dans la partie Network Interfaces vous selectionnez les interfaces sur lesquel votre résolver va pouvoir répondre aux clients de vos différents LANs

                Dans la section Outgoing Network, l'interface utilisé pour forwarder les requetes vers votre fournisseur DNS

                865bbc11-1e9b-46f5-a80b-559765ac9bd0-image.png

                Ensuite le reste se passe dans la zone "Custom Options"
                (à copier coller)

                server:
                ## Section A adapter
                    local-zone:  "mon_domain.domainlocal." static
                    
                    private-address: 192.168.1.0/24
                    private-address: 192.168.2.0/24
                    private-address: 192.168.3.0/24
                
                    private-domain: "mon_domain.domainlocal"
                ## Fin section A adapter    
                
                    log-queries: yes
                    log-replies:yes
                    log-tag-queryreply:yes
                
                    # Optimisations
                    msg-cache-slabs: 4
                    rrset-cache-slabs: 4
                    infra-cache-slabs: 4
                    key-cache-slabs: 4
                
                    #Limit DNS Fraud and use DNSSEC
                    harden-glue: yes
                    harden-dnssec-stripped: yes
                    harden-large-queries: yes
                    harden-referral-path: yes
                    harden-short-bufsize: yes
                    harden-algo-downgrade: yes
                    harden-below-nxdomain: yes
                    use-caps-for-id: no
                    aggressive-nsec: yes
                    delay-close: 10000
                	
                    neg-cache-size: 4M
                    qname-minimisation: yes
                    val-clean-additional: yes
                    edns-buffer-size: 1472
                    prefetch: yes
                	
                    cache-min-ttl: 300
                    cache-max-ttl: 9200
                    prefetch-key: yes
                    serve-expired: yes
                    msg-cache-size: 128m
                    rrset-cache-size: 256m
                	
                    num-threads: 4
                    so-rcvbuf: 2m
                	
                    rrset-roundrobin: yes
                    val-clean-additional: yes
                
                    forward-zone:
                        name: "."
                        forward-tls-upstream: yes
                
                ###### Section Faites votre choix
                
                         ## Google
                         forward-addr: 8.8.8.8@853#dns.google
                         forward-addr: 8.8.4.4@853#dns.google
                         
                         ## Cloudflare
                         forward-addr: 1.1.1.1@853#cloudflare-dns.com
                         forward-addr: 1.0.0.1@853#cloudflare-dns.com
                    
                         ## Quad9  ( Slowest, only serve as backup when the faster are temporarily down. )
                         forward-addr: 9.9.9.9@853#dns.quad9.net
                         forward-addr: 9.9.9.10@853#dns.quad9.net
                
                         ## DNS0.eu (Respect RGPD)
                         forward-addr: 193.110.81.0#dns0.eu
                         forward-addr: 185.253.5.0#dns0.eu
                
                         ## DNS0.eu (Respect RGPD) ZERO (Secu renforcé)
                         forward-addr: 193.110.81.9#dns0.eu
                         forward-addr: 185.253.5.9#dns0.eu
                
                         ## DNS0.eu (Respect RGPD) KIDS (Aucun contenu adulte)
                         forward-addr: 193.110.81.1#dns0.eu
                         forward-addr: 185.253.5.1#dns0.eu
                
                ###### Fin Section Faites votre choix
                
                remote-control:
                    control-enable: no
                

                Et enfin, dans les règles vous autorisez les requêtes de vos clients vers l'interface d'écoute adéquate de votre serveur DNS sur les ports TCP/UDP 53 et 853

                Bon je ne suis pas expert, j'ai peut etre des loupés dans cette conf, mais elle est fonctionnelle en l'état

                Il y a d'autres fournisseurs payant tel que NextDNS qui peuvent aussi être pertinent à choisir

                1 Reply Last reply Reply Quote 0
                • W
                  wf
                  last edited by

                  Bonjour,

                  Je m’excuse pour ma réponse tardive, j’ai eu beaucoup d’imprévu.

                  1000 merci à vous deux.

                  @jdh
                  Je comprends un peu mieux avec ton explication, car pas toujours facile de trouver explication, je ne suis pas anglophone je ne comprends pas toujours très bien sur les documents de pfsense, donc j’ai du mal à trouver les bonnes infos et je regarde avec tutos que je trouve sur le net, ce qui n’ai peut-être pas toujours le mieux.

                  @couteauabeurre
                  Superbe ton explication, je n’aurai jamais trouvé ce que tu as expliqué, cela fonctionne parfaitement et en plus tu as résolue un autre problème, car je voulais passer avec cloudflare.

                  J’aimerais bien trouver livre pfsense en français apparemment il n’est toujours pas sorti.

                  Le problème est résolu, j’ai juste le LAN2 qui n’est pas accessible via LAN1 lorsque le VNP est activer, ce qui fonctionne sens le VPN. Je vais regarder comment régler cela.

                  Encore un très grand merci à vous pour votre aide 😉 👍

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.