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

[wf]

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

https://whoer.net/fr/dns-leak-test

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)

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

Résolveur DNS - Paramètres avancés

Le reste est laissé par défaut

Système > Routage > Passerelles

J’ai testé Passerelle par défaut : en automatique cela ne change rien

Nat – Sortant

Pare-feu > Règles > LAN

OpenVPN – Client

Statut – Service

Merci d’avance pour votre future aide

Cordialement

[jdh]

@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 !

[couteauabeurre]

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

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

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)

[wf]

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.

[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)

[couteauabeurre]

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

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

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

[wf]

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