Configurer le résolveur DNS sur HTTPS (DoH) sur Debian avec DNSdist

Ce didacticiel vous montrera comment configurer votre propre DNS sur HTTPS (DoH)résolveur sur Debian avec DNSdist, afin que vos requêtes DNS puissent être cryptées et protégées des regards indiscrets.

Qu'est-ce que le DNS sur HTTPS et pourquoi c'est important

DNS (Domain Name System) est responsable de la traduction des noms de domaine en adresses IP. Il a été conçu en 1987 sans souci de sécurité ni de confidentialité. Par défaut, les requêtes DNS ne sont pas chiffrées. Ils sont envoyés en clair sur le fil et peuvent être exploités par des entités intermédiaires. Par exemple, le Grand Pare-feu (GFW ) de Chine utilise une technique appelée poison de cache DNS pour censurer l'Internet chinois. (Ils utilisent également d'autres méthodes, qui sortent du cadre de cet article.)

GFW vérifie chaque requête DNS envoyée à un serveur DNS en dehors de la Chine. Étant donné que le protocole DNS en texte brut est basé sur UDP, qui est un protocole sans connexion, GFW peut usurper à la fois l'IP du client et l'IP du serveur. Lorsque GFW trouve un nom de domaine sur sa liste de blocage, il modifie la réponse DNS. Par exemple, si un internaute chinois souhaite visiter google.com, GFW renvoie une adresse IP située en Chine au lieu de l'adresse IP réelle de Google, au résolveur DNS de l'utilisateur. Ensuite, le résolveur DNS renvoie la fausse adresse IP à l'ordinateur de l'utilisateur, de sorte que l'utilisateur ne peut pas visiter google.com.

HTTPS est le moyen standard de chiffrer les connexions HTTP en texte brut. Avec DNS over HTTPS (DoH), vos requêtes DNS seront cryptées et aucun tiers ne pourra voir votre requête DNS.

Pourquoi exécuter votre propre résolveur DoH ?

Il existe déjà des résolveurs DNS publics comme 1.1.1.1 et 9.9.9.9 qui prennent en charge DNS sur HTTPS, vous pouvez donc les utiliser si vous n'avez pas les compétences ou le temps d'exécuter les vôtres. À partir de la version 61 de Firefox, vous pouvez activer DNS sur HTTPS dans les paramètres du navigateur, ce qui constitue un grand progrès pour la sécurité et la confidentialité sur Internet. Firefox utilise les résolveurs Cloudflare (1.1.1.1) par défaut. Cependant, certaines personnes affirment que cela permet à Cloudflare de collecter des informations sur les utilisateurs de Firefox. Ils semblent avoir plus confiance en leur FAI qu'en Cloudflare. Je pense que si vous êtes paranoïaque à propos de la confidentialité, vous devriez exécuter votre propre résolveur DoH, afin que ni Cloudflare ni votre FAI ne puissent vous espionner.

DoH contre DoT

Il existe un autre protocole qui vise également à chiffrer les requêtes DNS. Cela s'appelle DNS sur TLS (Point). Quels sont les avantages d'utiliser DNS plutôt que HTTPS ?

Pour les personnes vivant dans des pays où la censure d'Internet est sévère, comme la Chine, il est plus avantageux d'utiliser DoH.

DoT fonctionne sur le port TCP 853 , qui peut être facilement bloqué par un pare-feu national.
DoH fonctionne sur le port TCP 443 , qui est le port standard pour les sites Web HTTPS, ce qui rend DoH très difficile à bloquer, car si le port TCP 443 est bloqué, alors presque tous les sites Web HTTPS seront également bloqués.

Mon résolveur DoH fonctionne sur un VPS (serveur privé virtuel) situé en dehors de la Chine et le Grand Pare-feu de Chine ne peut pas intercepter mes requêtes DNS. Je peux même cacher l'adresse IP de mon résolveur DoH derrière Cloudflare CDN (Content Delivery Network).

Un autre avantage de DoH est qu'il permet aux applications Web d'accéder aux informations DNS via les API de navigateur existantes, de sorte qu'aucun résolveur de stub n'est nécessaire.

Prise en charge du DoH dans les principaux résolveurs DNS

LIEN prendra en charge DoH dans la version 9.17, qui est toujours en développement. Debian 10 est livré avec BIND 9.11.
Nœud résolveur prend en charge DoH depuis la version 4.0.0. La dernière version actuelle est la 5.3.2. Il a un dépôt officiel pour Debian, Debian, CentOS, Fedora.
Non consolidé prend en charge DoH depuis la version 1.12.0.
Récurseur PowerDNS ne prend pas en charge DoH pour le moment.

En fait, je préfère exécuter le résolveur DoH avec DNSdist , qui a ajouté la prise en charge de DoH dans la version 1.4. La dernière version actuelle est la 1.6. Il dispose d'un référentiel officiel pour Debian, Raspbian, Debian et CentOS. DNSdist est un équilibreur de charge DNS qui peut transférer les requêtes DNS vers un résolveur DNS principal. Ainsi, quel que soit le résolveur DNS que vous utilisez, vous pouvez utiliser DNSdist pour exécuter votre propre serveur DoH. DNSdist est développé par l'équipe PowerDNS.

Exigences

Il est supposé que vous avez un résolveur DNS en cours d'exécution sur votre serveur Debian. Vous pouvez utiliser n'importe quel résolveur DNS (BIND, Knot resolver, Unbound…) J'utilise personnellement BIND.

Configurez votre propre résolveur DNS BIND9 sur Debian 10 Buster

Une fois votre résolveur DNS opérationnel, suivez les instructions ci-dessous.

Étape 1 :Installer DNSdist sur le serveur Debian

Il est recommandé d'installer DNSdist à partir du référentiel en amont, ainsi vous aurez la dernière version stable. Tout d'abord, vous devez créer un fichier de liste source pour DNSdist.

Debian 10

echo "deb [arch=amd64] http://repo.powerdns.com/debian buster-dnsdist-16 main" | sudo tee /etc/apt/sources.list.d/pdns.list

Debian 9

echo "deb [arch=amd64] http://repo.powerdns.com/debian stretch-dnsdist-15 main" | sudo tee /etc/apt/sources.list.d/pdns.list

Ensuite, nous créons un fichier de préférences pour DNSdist afin d'épingler le package, afin d'éviter d'installer accidentellement DNSdist à partir d'un autre référentiel.

sudo nano /etc/apt/preferences.d/dnsdist

Ajoutez les lignes suivantes dans le fichier.

Package: dnsdist*
Pin: origin repo.powerdns.com
Pin-Priority: 600

Enregistrez et fermez le fichier. Exécutez ensuite la commande suivante pour importer la clé publique PowerDNS, afin que le gestionnaire de packages APT puisse vérifier l'interité des packages logiciels téléchargés à partir de ce référentiel.

curl https://repo.powerdns.com/FD380FBB-pub.asc | sudo apt-key add -

Ensuite, mettez à jour la liste des référentiels et installez DNSdist.

sudo apt update

sudo apt install dnsdist

Par défaut, DNSdist essaie de se lier au port 53. Parce que vous avez un résolveur DNS existant comme BIND qui écoute sur le port 53, le dnsdist.service ne parviendrait pas à démarrer.

Puisque nous déployons juste un résolveur DoH et que nous ne nous soucions pas de l'équilibrage de charge DNS, nous pouvons configurer DNSdist pour écouter sur un autre port. Modifiez le fichier de configuration DNSdist.

sudo nano /etc/dnsdist/dnsdist.conf

Il n'y a pas de contenu dans ce fichier. Pour l'instant, ajoutez simplement la ligne suivante dans ce fichier, afin que DNSdist écoute sur les ports TCP et UDP 5353, au lieu du port 53.

setLocal("127.0.0.1:5353")

Enregistrez et fermez le fichier. Redémarrez ensuite DNSdist.

sudo systemctl restart dnsdist

Vérifiez son statut.

systemctl status dnsdist

Il doit être actif (en cours d'exécution) .

Étape 2 :Installez le client Let's Encrypt (Certbot) sur le serveur Debian

DNS sur HTTPS nécessite l'installation d'un certificat TLS côté serveur. Nous obtiendrons et installerons le certificat Let’s Encrypt. L'avantage d'utiliser le certificat Let's Encrypt est qu'il est gratuit, plus facile à configurer et approuvé par le logiciel client.

Exécutez les commandes suivantes pour installer le client Let's Encrypt (certbot) à partir du référentiel Debian par défaut.

sudo apt install certbot

Pour vérifier le numéro de version, exécutez

certbot --version

Exemple de sortie :

certbot 0.31.0

Étape 3 :Obtenir un certificat TLS de confiance auprès de Let's Encrypt

Je recommande d'utiliser le standalone ou webroot plugin pour obtenir le certificat TLS pour dnsdist.

Plug-in autonome

S'il n'y a pas de serveur Web en cours d'exécution sur votre serveur Debian, vous pouvez utiliser le plug-in autonome pour obtenir un certificat TLS auprès de Let's Encrypt. Créez un enregistrement DNS A pour le sous-domaine (doh.example.com), puis exécutez la commande suivante.

sudo certbot certonly --standalone --preferred-challenges http --agree-tos --email [email protected] -d doh.example.com

Où :

certonly :obtenez un certificat, mais ne l'installez pas.
--standalone :Utilisez le plugin autonome pour obtenir un certificat
--preferred-challenges http :Effectuez le défi http-01 pour valider notre domaine, qui utilisera le port 80.
--agree-tos :Acceptez les conditions d'utilisation de Let's Encrypt.
--email :L'adresse e-mail est utilisée pour l'enregistrement et la récupération du compte.
-d :Spécifiez votre nom de domaine.

Utilisation du plug-in Webroot

Si votre serveur Debian a un serveur Web qui écoute sur les ports 80 et 443, c'est une bonne idée d'utiliser le plugin webroot pour obtenir un certificat car le plugin webroot fonctionne avec à peu près tous les serveurs web et nous n'avons pas besoin d'installer le certificat dans le serveur Web.

Tout d'abord, vous devez créer un hôte virtuel pour doh.example.com.

Apache

Si vous utilisez Apache, alors

sudo nano /etc/apache2/sites-available/doh.example.com.conf

Et collez les lignes suivantes dans le fichier.

<VirtualHost *:80>        
        ServerName doh.example.com

        DocumentRoot /var/www/dnsdist
</VirtualHost>

Enregistrez et fermez le fichier. Créez ensuite le répertoire racine Web.

sudo mkdir /var/www/dnsdist

Définissez www-data (utilisateur Apache) comme propriétaire de la racine Web.

sudo chown www-data:www-data /var/www/dnsdist -R

Activez cet hôte virtuel.

sudo a2ensite doh.example.com

Rechargez Apache pour que les modifications prennent effet.

sudo systemctl reload apache2

Une fois l'hôte virtuel créé et activé, exécutez la commande suivante pour obtenir le certificat Let's Encrypt à l'aide du plug-in Webroot.

sudo certbot certonly --webroot --agree-tos --email [email protected] -d doh.example.com -w /var/www/dnsdist

Nginx

Si vous utilisez Nginx, alors

sudo nano /etc/nginx/conf.d/doh.example.com.conf

Collez les lignes suivantes dans le fichier.

server {
      listen 80;
      server_name doh.example.com;

      root /var/www/dnsdist/;

      location ~ /.well-known/acme-challenge {
         allow all;
      }
}

Enregistrez et fermez le fichier. Créez ensuite le répertoire racine Web.

sudo mkdir -p /var/www/dnsdist

Définissez www-data (utilisateur Nginx) comme propriétaire de la racine Web.

sudo chown www-data:www-data /var/www/dnsdist -R

Rechargez Nginx pour que les modifications prennent effet.

sudo systemctl reload nginx

Une fois l'hôte virtuel créé et activé, exécutez la commande suivante pour obtenir le certificat Let's Encrypt à l'aide du plug-in Webroot.

sudo certbot certonly --webroot --agree-tos --email [email protected] -d doh.example.com -w /var/www/dnsdist

Étape 4 :Activer DoH dans DNSdist

Modifiez le fichier de configuration DNSdist.

sudo nano /etc/dnsdist/dnsdist.conf

Ajoutez les lignes suivantes dans le fichier.

-- allow query from all IP addresses
addACL('0.0.0.0/0')

-- add a DoH resolver listening on port 443 of all interfaces
addDOHLocal("0.0.0.0:443", "/etc/letsencrypt/live/doh.example.com/fullchain.pem", "/etc/letsencrypt/live/doh.example.com/privkey.pem", { "/" }, { doTCP=true, reusePort=true, tcpFastOpenSize=0 })

-- downstream resolver
newServer({address="127.0.0.1:53",qps=5, name="resolver1"})

Enregistrez et fermez le fichier. DNSdist s'exécute en tant que _dnsdist utilisateur, nous devons donc donner le _dnsdist autorisation de l'utilisateur pour lire le certificat TLS avec les commandes suivantes.

sudo apt install acl

sudo setfacl -R -m u:_dnsdist:rx /etc/letsencrypt/

Vérifiez ensuite la syntaxe du fichier de configuration.

sudo dnsdist --check-config

Si la syntaxe est correcte, redémarrez DNSdist.

sudo systemctl restart dnsdist

Notez que si un serveur Web écoute sur le port TCP 443, DNSdist ne pourra pas redémarrer. Vous pouvez arrêter temporairement le serveur Web. J'expliquerai comment faire en sorte que le serveur Web et DNSdist utilisent le port TCP 443 en même temps à la fin de cet article.

Étape 5 :Configurer DoH dans le navigateur Web Firefox

Allez dans Préférences -> Général et faites défiler vers le bas pour configurer les Paramètres réseau . Activez DNS sur HTTPS et définissez votre propre résolveur DoH.

Nous pouvons ensuite affiner les configurations DoH en allant sur about:config onglet dans Firefox.

network.trr.mode

Par défaut, le network.trr.mode le paramètre dans Firefox est défini sur 2 , ce qui signifie que si la requête DoH échoue, Firefox transmettra la requête DNS au système hôte. Je veux toujours utiliser le résolveur DoH, alors changez le network.trr.mode à 3 ainsi le résolveur hôte ne sera pas utilisé. Cela nous permet d'avoir un moyen simple de tester si votre résolveur DoH fonctionne.

network.trr.allow-rfc1918

Ceci est défini sur false par défaut, ce qui signifie que si la réponse DNS inclut des adresses IP privées, elle sera considérée comme une mauvaise réponse qui ne sera pas utilisée. Si vous utilisez une zone de stratégie de réponse dans BIND, vous avez probablement des noms d'hôte pointant vers des adresses IP privées, puis définissez cette valeur sur true .

network.trr.bootstrapAddress

Firefox doit rechercher l'adresse IP du résolveur DoH afin d'envoyer des requêtes DNS. Vous pouvez mettre l'adresse IP dans ce champ pour éliminer cette requête initiale.

Test

Entrez maintenant un nom de domaine comme linuxbabe.com dans la barre d'adresse de Firefox. Si la page Web se charge normalement, c'est un bon signe que votre résolveur DoH fonctionne. Accédez ensuite à la console du terminal de votre serveur DNS et vérifiez les journaux de requêtes DNS. J'utilise BIND, donc j'entre la commande suivante pour vérifier le journal des requêtes DNS.

sudo journalctl -eu bind9

Comme vous pouvez le voir dans le journal BIND ci-dessous, Firefox a interrogé les domaines suivants.

www.linuxbabe.com :mon site Web
fonts.gstatic.com :Cela sert les polices Google sur mon site Web
cdn.shareaholic.net :un widget de partage sur mon site
newsletter.linuxbabe.com :ma plate-forme de marketing par e-mail auto-hébergée.
translate.google.com :le widget Google traduction sur mon site Web

Le journal des requêtes ci-dessus m'indique que mon résolveur DNS sur HTTPS fonctionne. Si j'arrête le résolveur BIND (sudo systemctl stop named ), Firefox me dit qu'il ne trouve pas ce site. Et lorsque je lance BIND, la page Web se charge à nouveau.

Étape 6 :Configurer le client DoH sur le bureau Debian

Je sais qu'il existe 3 clients DNS open source sous Linux qui prennent en charge le DNS chiffré.

résolu par systemd
tronqué
dnscrypt-proxy

Actuellement, dnscrypt-proxy (version 2.x) est la meilleure implémentation du client DoH sur Linux, je vais donc vous montrer comment l'utiliser. Exécutez la commande suivante pour installer dnscrypt-proxy sur votre bureau Debian.

sudo apt install dnscrypt-proxy

Il démarrera automatiquement, comme vous pouvez le voir avec :

sudo systemctl status dnscrypt-proxy

S'il n'a pas démarré, vous pouvez exécuter la commande suivante pour le démarrer.

sudo systemctl enable dnscrypt-proxy --now

Vérifiez l'adresse d'écoute.

sudo ss -lnptu | grep dnscrypt-proxy

Sur mon ordinateur, dnscrypt-proxy écoute sur 127.0.2.1:53 . Il existe un autre service systemd (dnscrypt-proxy-resolvconf.service ) installé par dnscrypt-proxy,

systemctl status dnscrypt-proxy-resolvconf

Ceci est un service qui définit 127.0.2.1 comme résolveur sur votre ordinateur. Vous pouvez vérifier le résolveur DNS actuel de votre ordinateur avec :

cat /etc/resolv.conf

Par défaut, dnscrypt-proxy utilise Clouldflare comme résolveur DoH en amont. Pour utiliser votre propre résolveur DoH, modifiez le fichier de configuration.

sudo nano /etc/dnscrypt-proxy/dnscrypt-proxy.toml

Trouvez la ligne suivante

server_names = ['cloudflare']

Remplacez-le par le nom d'hôte de votre résolveur DoH. Notez que l'emplacement des paramètres est important. Vous ne devez pas mettre les server_names paramètre à d'autres endroits dans ce fichier.

server_names = ['doh.example.com']

Puis commentez le [sources] rubrique.

#[sources]
#  [sources.'public-resolvers']
#  url = 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md'
#  cache_file = '/var/cache/dnscrypt-proxy/public-resolvers.md'
#  minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
#  refresh_delay = 72
#  prefix = ''

Nous devons ajouter notre propre résolveur DoH comme ci-dessous au bas de ce fichier.

[static]  
  [static.'doh.example.com']
  stamp = 'sdns://AgUAAAAAAAAAAAAOZG5zLmdvb2dsZS5jb20NL2V4cGVyaW1lbnRhbA'

Le tampon contient votre nom d'hôte de résolveur DoH, votre adresse IP et votre chemin de requête. Pour obtenir votre propre tampon, utilisez le calculateur de tampon DNS en ligne. Choisissez DNS-over-HTTPS comme protocole et entrez l'adresse IP, le nom d'hôte et le chemin de requête. Si vous suivez ce tutoriel pour configurer votre propre résolveur DoH, le chemin doit être défini uniquement sur / . Si vous n'avez pas activé DNSSEC sur votre résolveur, décochez la case DNSSEC.

Une fois que vous avez ajouté votre tampon DNS, enregistrez et fermez le fichier. Puis redémarrez dnscrypt-proxy .

sudo systemctl restart dnscrypt-proxy

Vérifiez son état. Assurez-vous qu'il est en cours d'exécution.

systemctl status dnscrypt-proxy

Vous pouvez maintenant tester si dnscrypt-proxy fonctionne.

Si vous ne souhaitez pas publier votre résolveur DNS sur HTTPS dans le monde, vous pouvez supprimer l'enregistrement DNS A du nom d'hôte de votre résolveur DoH, car dnscrypt-proxy a l'adresse IP dans le tampon DNS.

Configurer DoH sur iOS

iOS prend en charge DNS sur HTTPS depuis iOS 14. Cependant, il n'y a pas d'option de configuration simple sur iOS pour définir le résolveur DoH. Vous devez générer un .mobileconfig fichier et installez-le sur iOS. C'est un peu compliqué de générer un iOS .mobileconfig signé fichier.

Si votre résolveur DoH ne sera pas utilisé publiquement, vous pouvez générer un simple fichier non signé. Utilisez un éditeur de texte pour créer un fichier avec .mobileconfig extension. Copiez et collez le texte suivant. Remplacez l'adresse IP et l'URL du serveur.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>PayloadContent</key>
        <array>
                <dict>
                        <key>DNSSettings</key>
                        <dict>
                                <key>DNSProtocol</key>
                                <string>HTTPS</string>
                                <key>ServerAddresses</key>
                                <array>
                                        <string>12.34.56.78</string>
                                </array>
                                <key>ServerURL</key>
                                <string>https://doh.example.com/</string>
                        </dict>
                        <key>PayloadDescription</key>
                        <string>Configures device to use Encrypted DNS over HTTPS</string>
                        <key>PayloadDisplayName</key>
                        <string>My own DNS over HTTPS Resolver</string>
                        <key>PayloadIdentifier</key>
                        <string>com.apple.dnsSettings.managed.9d6e5fdf-e404-4f34-ae94-27ed2f636ac4</string>
                        <key>PayloadType</key>
                        <string>com.apple.dnsSettings.managed</string>
                        <key>PayloadUUID</key>
                        <string>35d5c8a0-afa6-4b36-a9fe-099a997b44ad</string>
                        <key>PayloadVersion</key>
                        <integer>1</integer>
                        <key>ProhibitDisablement</key>
                        <false/>
                </dict>
        </array>
        <key>PayloadDescription</key>
        <string>Adds self-hosted DoH resolver to Big Sur and iOS 14 based systems</string>
        <key>PayloadDisplayName</key>
        <string>My own DNS over HTTPS</string>
        <key>PayloadIdentifier</key>
        <string>com.example.doh</string>
        <key>PayloadRemovalDisallowed</key>
        <false/>
        <key>PayloadType</key>
        <string>Configuration</string>
        <key>PayloadUUID</key>
        <string>A4475135-633A-4F15-A79B-BE15093DC97A</string>
        <key>PayloadVersion</key>
        <integer>1</integer>
</dict>
</plist>

Enregistrez et fermez le fichier. Ensuite, vous pouvez envoyer le fichier en pièce jointe à votre iOS. Ouvrez l'e-mail sur iOS et appuyez sur la pièce jointe pour télécharger le fichier de configuration. Après cela, allez dans iOS Settings -> Profile Downloaded . Il vous invitera à installer le profil.

Appuyez sur le bouton Installer et entrez votre mot de passe iOS pour l'installer. Appuyez à nouveau sur le bouton Installer.

Une fois installé, accédez à iOS Settings -> VPN & Network . Faites défiler jusqu'au bouton pour choisir le résolveur DNS pour votre système iOS. Notez que ce résolveur DoH remplacera le résolveur DNS fourni par un VPN comme ProtonVPN. Votre iOS utilisera toujours votre résolveur DoH.

Si jamais vous souhaitez supprimer le .mobileconfig fichier depuis iOS, allez dans Settings -> General -> Profile .

Faites en sorte que DNSdist et le serveur Web utilisent le port 443 en même temps

Un résolveur DNS sur HTTPS doit se lier au port 443. Si Apache/Nginx écoute déjà sur le port 443, DNSdist ne peut pas se lier au port 443. Normalement, un port ne peut être utilisé que par un seul processus. Cependant, nous pouvons utiliser HAproxy (High Availability Proxy) et SNI (Server Name Indication) pour que DNSdist et Apache/Nginx utilisent le port 443 en même temps.

Configuration de la distribution DNS

Modifiez le fichier de configuration DNSdist.

sudo nano /etc/dnsdist/dnsdist.conf

Remplacez l'adresse d'écoute DoH par 127.0.0.1 .

addDOHLocal("127.0.0.1:443", "/etc/letsencrypt/live/doh.example.com/fullchain.pem", "/etc/letsencrypt/live/doh.example.com/privkey.pem", { "/" }, { doTCP=true, reusePort=true, tcpFastOpenSize=0 })

Enregistrez et fermez le fichier. Redémarrez ensuite DNSdist.

sudo systemctl restart dnsdist

Configuration Nginx

Si vous utilisez Nginx, modifiez le fichier de blocage du serveur.

sudo nano /etc/nginx/conf.d/example.com.conf

Dans le bloc du serveur SSL, recherchez la directive suivante.

listen 443 ssl;

Changez-le en

listen 127.0.0.2:443 ssl;

Cette fois on le fait écouter sur 127.0.0.2:443 car 127.0.0.1:443 est déjà pris par DNSdist. Enregistrez et fermez le fichier. Le fichier de configuration principal de Nginx /etc/nginx/nginx.conf et le bloc de serveur par défaut /etc/nginx/sites-enabled/default peut inclure un hôte virtuel par défaut écoutant sur 443, vous devrez donc peut-être également modifier ce fichier.

Redémarrez ensuite Nginx.

sudo systemctl restart nginx

Configuration Apache

Si vous utilisez le serveur Web Apache, modifiez votre fichier d'hôte virtuel.

sudo nano /etc/apache2/sites-enabled/example.com.conf

Dans l'hôte virtuel SSL, modifiez

<VirtualHost *:443>

<VirtualHost 127.0.0.2:443>

Cette fois on le fait écouter sur 127.0.0.2:443 car 127.0.0.1:443 est déjà pris par DNSdist. Enregistrez et fermez le fichier. Modifiez ensuite le /etc/apache2/ports.conf fichier.

sudo nano /etc/apache2/ports.conf

Modifier

Listen 443

Listen 127.0.0.2:443

Enregistrez et fermez le fichier. Redémarrez Apache.

sudo systemctl restart apache2

Configuration HAProxy

Installez maintenant HAproxy.

sudo apt install haproxy

Démarrer HAProxy

sudo systemctl start haproxy

Modifier le fichier de configuration.

sudo nano /etc/haproxy/haproxy.cfg

Si vous utilisez Nginx , copiez et collez les lignes suivantes à la fin du fichier. Remplacer 12.34.56.78 avec l'adresse IP publique de votre serveur. Remplacez doh.example.com avec le nom de domaine utilisé par DNSdist et www.example.com avec le nom de domaine utilisé par votre serveur Web.

frontend https
   bind 12.34.56.78:443
   mode tcp
   tcp-request inspect-delay 5s
   tcp-request content accept if { req_ssl_hello_type 1 }

   use_backend dnsdist if { req_ssl_sni -i doh.example.com }
   use_backend nginx if { req_ssl_sni -i www.example.com }
   use_backend nginx if { req_ssl_sni -i example.com }

   default_backend dnsdist

backend dnsdist
   mode tcp
   option ssl-hello-chk
   server dnsdist 127.0.0.1:443

backend nginx
   mode tcp
   option ssl-hello-chk
   server nginx 127.0.0.2:443 check

Si vous utilisez Apache , copiez et collez les lignes suivantes à la fin du fichier. Remplacer 12.34.56.78 avec l'adresse IP publique de votre serveur. Remplacez doh.example.com avec le nom de domaine utilisé par DNSdist et www.example.com avec le nom de domaine utilisé par votre serveur Web.

frontend https
   bind 12.34.56.78:443
   mode tcp
   tcp-request inspect-delay 5s
   tcp-request content accept if { req_ssl_hello_type 1 }

   use_backend dnsdist if { req_ssl_sni -i doh.example.com }
   use_backend apache if { req_ssl_sni -i www.example.com }
   use_backend apache if { req_ssl_sni -i example.com }

   default_backend dnsdist

backend dnsdist
   mode tcp
   option ssl-hello-chk
   server dnsdist 127.0.0.1:443

backend apache
    mode tcp
    option ssl-hello-chk
    server apache 127.0.0.2:443 check

Enregistrez et fermez le fichier. Puis redémarrez HAproxy.

sudo systemctl restart haproxy

Dans la configuration ci-dessus, nous avons utilisé la fonctionnalité SNI (Server Name Indication) dans TLS pour différencier le trafic VPN et le trafic HTTPS normal.

Quand doh.example.com se trouve dans le client TLS Bonjour, HAProxy redirige le trafic vers le backend DNSdist.
Quand www.example.com se trouve dans le client TLS Bonjour, HAProxy redirige le trafic vers le backend apache/nginx.
Si le client ne spécifie pas le nom du serveur dans TLS Client Hello, alors HAproxy utilisera le backend par défaut (DNSdist).

Vous pouvez tester cette configuration avec le openssl outil. Tout d'abord, exécutez la commande suivante plusieurs fois.

echo | openssl s_client -connect your-server-IP:443 | grep subject

Nous n'avons pas spécifié le nom du serveur dans la commande ci-dessus, donc HAproxy transmettra toujours la requête au backend par défaut (DNSdist) et son certificat sera envoyé au client. Ensuite, exécutez les deux commandes suivantes.

echo | openssl s_client -servername www.example.com -connect your-server-IP:443 | grep subject

echo | openssl s_client -servername doh.example.com -connect your-server-IP:443 | grep subject

Nous avons maintenant spécifié le nom du serveur dans les commandes, afin que HAproxy transmette les requêtes conformément aux règles SNI que nous avons définies.

Lors du renouvellement du certificat Let's Encrypt pour votre site Web, il est recommandé d'utiliser le http-01 challenge au lieu de tls-alpn-01 défi, car HAproxy écoute sur le port 443 de l'adresse IP publique, il peut donc interférer avec le processus de renouvellement.

sudo certbot renew --preferred-challenges http-01