Questo tutorial ti mostrerà come configurare il tuo DNS su HTTPS (DoH) risolutore su Debian con DNSdist, così le tue query DNS possono essere crittografate e protette da occhi indiscreti.
Cos'è il DNS su HTTPS e perché è importante
Il DNS (Domain Name System) è responsabile della traduzione dei nomi di dominio in indirizzi IP. È stato progettato nel 1987 senza alcuna sicurezza o privacy in mente. Per impostazione predefinita, le query DNS non sono crittografate. Vengono inviati in chiaro sul filo e possono essere sfruttati da entità intermedie. Ad esempio, il Great Firewall (GFW ) della Cina utilizza una tecnica chiamata DNS cache poison censurare Internet cinese. (Usano anche altri metodi, che esulano dallo scopo di questo articolo.)
GFW controlla ogni query DNS inviata a un server DNS al di fuori della Cina. Poiché il protocollo DNS in testo normale si basa su UDP, che è un protocollo senza connessione, GFW può falsificare sia l'IP del client che l'IP del server. Quando GFW trova un nome di dominio nella sua lista di blocco, cambia la risposta DNS. Ad esempio, se un utente Internet cinese desidera visitare google.com, GFW restituisce un indirizzo IP situato in Cina anziché l'indirizzo IP reale di Google al risolutore DNS dell'utente. Quindi il risolutore DNS restituisce l'indirizzo IP falso al computer dell'utente, quindi l'utente non può visitare google.com.
HTTPS è il modo standard per crittografare le connessioni HTTP in testo normale. Con DNS su HTTPS (DoH), le tue query DNS verranno crittografate e nessuna terza parte potrà vedere la tua query DNS.
Perché eseguire il proprio risolutore DoH?
Esistono già alcuni resolver DNS pubblici come 1.1.1.1 e 9.9.9.9 che supportano DNS su HTTPS, quindi puoi usarli se non hai le competenze o il tempo per eseguirne uno. A partire dalla versione 61 di Firefox, puoi abilitare DNS su HTTPS nelle impostazioni del browser, il che rappresenta un grande progresso per la sicurezza e la privacy di Internet. Firefox utilizza i resolver Cloudflare (1.1.1.1) per impostazione predefinita. Tuttavia, alcune persone sostengono che ciò consente a Cloudflare di raccogliere informazioni sugli utenti di Firefox. Sembrano avere più fiducia nel loro ISP rispetto a Cloudflare. Penso che se sei paranoico sulla privacy, dovresti eseguire il tuo risolutore DoH, quindi né Cloudflare né il tuo ISP possono spiarti.
DoH vs DoT
C'è un altro protocollo che mira anche a crittografare le query DNS. Si chiama DNS su TLS (Punto). Quali sono i vantaggi dell'utilizzo di DNS su HTTPS?
Per le persone che vivono in paesi con una severa censura su Internet come la Cina, è più vantaggioso utilizzare DoH.
- DoT opera sulla porta TCP 853 , che può essere facilmente bloccato da un firewall nazionale.
- DoH opera sulla porta TCP 443 , che è la porta standard per i siti Web HTTPS, il che rende estremamente difficile bloccare DoH, perché se la porta TCP 443 è bloccata, verranno bloccati anche quasi tutti i siti Web HTTPS.
Il mio risolutore DoH è in esecuzione su un VPS (server privato virtuale) situato al di fuori della Cina e il Great Firewall cinese non può intercettare le mie query DNS. Posso persino nascondere l'indirizzo IP del mio resolver DoH dietro Cloudflare CDN (Content Delivery Network).
Un altro vantaggio di DoH è che consente alle applicazioni Web di accedere alle informazioni DNS tramite le API del browser esistenti, quindi non è necessario alcun risolutore di stub.
Supporto DoH nei principali resolver DNS
- LEGGERA supporterà DoH nella versione 9.17, che è ancora in fase di sviluppo. Debian 10 viene fornito con BIND 9.11.
- Nodo risolutore supporta DoH dalla versione 4.0.0. L'ultima versione corrente è 5.3.2. Ha un repository ufficiale per Debian, Debian, CentOS, Fedora.
- Non vincolato supporta DoH dalla versione 1.12.0.
- Ricorrente PowerDNS al momento non supporta DoH.
In realtà, preferisco eseguire il risolutore DoH con DNSDist , che ha aggiunto il supporto DoH nella versione 1.4. L'ultima versione corrente è 1.6. Ha un repository ufficiale per Debian, Raspbian, Debian e CentOS. DNSdist è un sistema di bilanciamento del carico DNS in grado di inoltrare query DNS a un risolutore DNS di back-end, quindi indipendentemente dal risolutore DNS in uso, puoi utilizzare DNSdist per eseguire il tuo server DoH. DNSdist è sviluppato dal team di PowerDNS.
Requisiti
Si presume che tu abbia un risolutore DNS in esecuzione sul tuo server Debian. Puoi usare qualsiasi risolutore DNS (BIND, Knot resolver, Unbound...) Io personalmente uso BIND.
- Configura il tuo risolutore DNS BIND9 su Debian 10 Buster
Una volta che il tuo risolutore DNS è attivo e funzionante, segui le istruzioni seguenti.
Fase 1:installa DNSdist sul server Debian
Si consiglia di installare DNSdist dal repository upstream, in modo da avere l'ultima versione stabile. Innanzitutto, devi creare un file di elenco di origine per 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
Successivamente, creiamo un file delle preferenze per DNSdist per bloccare il pacchetto, quindi non installeremo accidentalmente DNSdist da un altro repository.
sudo nano /etc/apt/preferences.d/dnsdist
Aggiungi le seguenti righe nel file.
Package: dnsdist* Pin: origin repo.powerdns.com Pin-Priority: 600
Salva e chiudi il file. Quindi esegui il comando seguente per importare la chiave pubblica PowerDNS, in modo che il gestore di pacchetti APT possa verificare l'interità dei pacchetti software scaricati da questo repository.
curl https://repo.powerdns.com/FD380FBB-pub.asc | sudo apt-key add -
Quindi, aggiorna l'elenco dei repository e installa DNSdist.
sudo apt update sudo apt install dnsdist
Per impostazione predefinita, DNSdist tenta di collegarsi alla porta 53. Poiché hai un resolver DNS esistente come BIND in ascolto sulla porta 53, dnsdist.service non si avvia.
Poiché stiamo solo implementando un resolver DoH e non ci interessa il bilanciamento del carico DNS, possiamo configurare DNSdist per l'ascolto su un'altra porta. Modifica il file di configurazione DNSdist.
sudo nano /etc/dnsdist/dnsdist.conf
Non ci sono contenuti in questo file. Per ora, aggiungi semplicemente la seguente riga a questo file, così DNSdist ascolterà sulla porta TCP e UDP 5353, invece della porta 53.
setLocal("127.0.0.1:5353") Salva e chiudi il file. Quindi riavvia DNSdist.
sudo systemctl restart dnsdist
Controlla il suo stato.
systemctl status dnsdist
Dovrebbe essere attivo (in esecuzione) .
Fase 2:Installa Let's Encrypt Client (Certbot) su Debian Server
DNS su HTTPS richiede l'installazione di un certificato TLS sul lato server. Otterremo e installeremo il certificato Let's Encrypt. Il vantaggio dell'utilizzo del certificato Let's Encrypt è che è gratuito, più facile da configurare e considerato affidabile dal software client.
Esegui i seguenti comandi per installare il client Let's Encrypt (certbot) dal repository Debian predefinito.
sudo apt install certbot
Per controllare il numero di versione, esegui
certbot --version
Esempio di output:
certbot 0.31.0
Fase 3:ottieni un certificato TLS affidabile da Let's Encrypt
Consiglio di utilizzare il standalone o webroot plug-in per ottenere il certificato TLS per dnsdist.
Plugin autonomo
Se non è presente alcun server Web in esecuzione sul tuo server Debian, puoi utilizzare il plug-in autonomo per ottenere il certificato TLS da Let's Encrypt. Crea un record DNS A per il sottodominio (doh.example.com), quindi esegui il comando seguente.
sudo certbot certonly --standalone --preferred-challenges http --agree-tos --email [email protected] -d doh.example.com
Dove:
certonly:Ottieni un certificato ma non installarlo.--standalone:usa il plugin standalone per ottenere un certificato--preferred-challenges http:esegui la verifica http-01 per convalidare il nostro dominio, che utilizzerà la porta 80.--agree-tos:Accetta i termini di servizio di Let's Encrypt.--email:l'indirizzo e-mail viene utilizzato per la registrazione e il recupero dell'account.-d:Specifica il tuo nome di dominio.
Utilizzo del plug-in webroot
Se il tuo server Debian ha un server web in ascolto sulle porte 80 e 443, allora è una buona idea usare il plugin webroot per ottenere un certificato perché il plugin webroot funziona praticamente con tutti i web server e non abbiamo bisogno di installare il certificato nel server web.
Innanzitutto, devi creare un host virtuale per doh.example.com.
Apache
Se stai usando Apache, allora
sudo nano /etc/apache2/sites-available/doh.example.com.conf
E incolla le seguenti righe nel file.
<VirtualHost *:80>
ServerName doh.example.com
DocumentRoot /var/www/dnsdist
</VirtualHost>
Salva e chiudi il file. Quindi crea la directory principale web.
sudo mkdir /var/www/dnsdist
Imposta www-data (utente Apache) come proprietario della radice web.
sudo chown www-data:www-data /var/www/dnsdist -R
Abilita questo host virtuale.
sudo a2ensite doh.example.com
Ricarica Apache per rendere effettive le modifiche.
sudo systemctl reload apache2
Una volta creato e abilitato l'host virtuale, esegui il comando seguente per ottenere il certificato Let's Encrypt utilizzando il plug-in webroot.
sudo certbot certonly --webroot --agree-tos --email [email protected] -d doh.example.com -w /var/www/dnsdist
Nginx
Se stai usando Nginx, allora
sudo nano /etc/nginx/conf.d/doh.example.com.conf
Incolla le seguenti righe nel file.
server {
listen 80;
server_name doh.example.com;
root /var/www/dnsdist/;
location ~ /.well-known/acme-challenge {
allow all;
}
} Salva e chiudi il file. Quindi crea la directory principale web.
sudo mkdir -p /var/www/dnsdist
Imposta www-data (utente Nginx) come proprietario della radice web.
sudo chown www-data:www-data /var/www/dnsdist -R
Ricarica Nginx per rendere effettive le modifiche.
sudo systemctl reload nginx
Una volta creato e abilitato l'host virtuale, esegui il comando seguente per ottenere il certificato Let's Encrypt utilizzando il plug-in webroot.
sudo certbot certonly --webroot --agree-tos --email [email protected] -d doh.example.com -w /var/www/dnsdist
Fase 4:abilita DoH in DNSdist
Modifica il file di configurazione DNSdist.
sudo nano /etc/dnsdist/dnsdist.conf
Aggiungi le seguenti righe nel file.
-- 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"})
Salva e chiudi il file. DNSdist viene eseguito come _dnsdist utente, quindi dobbiamo fornire il _dnsdist autorizzazione utente per leggere il certificato TLS con i seguenti comandi.
sudo apt install acl sudo setfacl -R -m u:_dnsdist:rx /etc/letsencrypt/
Quindi controlla la sintassi del file di configurazione.
sudo dnsdist --check-config
Se la sintassi è corretta, riavvia DNSdist.
sudo systemctl restart dnsdist
Si noti che se è presente un server Web in ascolto sulla porta TCP 443, DNSdist non si riavvierà. È possibile interrompere temporaneamente il server web. Spiegherò come fare in modo che il server Web e DNSdist utilizzino la porta TCP 443 contemporaneamente alla fine di questo articolo.
Passaggio 5:Configura DoH nel browser Web Firefox
Vai a Preferenze -> Generale e scorri verso il basso per configurare le Impostazioni di rete . Abilita DNS su HTTPS e imposta il tuo risolutore DoH.
Possiamo quindi mettere a punto le configurazioni DoH andando su about:config scheda in Firefox.
network.trr.mode
Per impostazione predefinita, la network. parametro in Firefox è impostato su 2 , il che significa che se la query DoH non riesce, Firefox passerà la query DNS al sistema host. Voglio usare sempre il risolutore DoH, quindi cambia il network.trr.mode a 3 quindi il risolutore host non verrà utilizzato. Questo ci consente di avere un modo semplice per verificare se il tuo resolver DoH funziona.
network.trr.allow-rfc1918
Questo è impostato su false per impostazione predefinita, il che significa che se la risposta DNS include indirizzi IP privati, verrà considerata una risposta errata che non verrà utilizzata. Se utilizzi la response policy zone in BIND, probabilmente hai alcuni nomi host che puntano a indirizzi IP privati, quindi imposta questo valore su true .
rete.
Firefox deve cercare l'indirizzo IP del resolver DoH per inviare query DNS. Puoi inserire l'indirizzo IP in questo campo per eliminare questa richiesta iniziale.
Test
Ora inserisci un nome di dominio come linuxbabe.com nella barra degli indirizzi di Firefox. Se la pagina Web viene caricata normalmente, è un buon segno che il tuo resolver DoH funziona. Quindi vai alla console del terminale del tuo server DNS e controlla i registri delle query DNS. Uso BIND, quindi inserisco il seguente comando per controllare il registro delle query DNS.
sudo journalctl -eu bind9
Come puoi vedere dal registro BIND di seguito, Firefox ha interrogato i seguenti domini.
- www.linuxbabe.com :il mio sito web
- fonts.gstatic.com :serve i caratteri Google sul mio sito web
- cdn.shareaholic.net :un widget di condivisione sul mio sito web
- newsletter.linuxbabe.com :la mia piattaforma di email marketing self-hosted.
- translate.google.com :il widget di Google Translate sul mio sito web
Il registro delle query sopra mi dice che il mio risolutore DNS su HTTPS funziona. Se interrompo il risolutore BIND (sudo systemctl stop named ), Firefox mi dice che non riesce a trovare quel sito. E quando avvio BIND, la pagina web si carica di nuovo.
Fase 6:Configura il client DoH su Debian Desktop
So che ci sono 3 client DNS open source su Linux che supportano DNS crittografato.
- Risolto dal sistema
- tozzo
- dnscrypt-proxy
Attualmente, dnscrypt-proxy (versione 2.x) è la migliore implementazione client DoH su Linux, quindi ti mostrerò come usarla. Esegui il comando seguente per installare dnscrypt-proxy sul desktop Debian.
sudo apt install dnscrypt-proxy
Si avvierà automaticamente, come puoi vedere con:
sudo systemctl status dnscrypt-proxy
Se non si avvia, puoi eseguire il comando seguente per avviarlo.
sudo systemctl enable dnscrypt-proxy --now
Controlla l'indirizzo di ascolto.
sudo ss -lnptu | grep dnscrypt-proxy
Sul mio computer, dnscrypt-proxy è in ascolto su 127.0.2.1:53 . C'è un altro servizio systemd (dnscrypt-proxy-resolvconf.service ) installato da dnscrypt-proxy,
systemctl status dnscrypt-proxy-resolvconf
Questo è un servizio che imposta 127.0.2.1 come risolutore sul tuo computer. Puoi controllare l'attuale risolutore DNS per il tuo computer con:
cat /etc/resolv.conf
Per impostazione predefinita, dnscrypt-proxy utilizza Clouldflare come risolutore DoH a monte. Per utilizzare il tuo risolutore DoH, modifica il file di configurazione.
sudo nano /etc/dnscrypt-proxy/dnscrypt-proxy.toml
Trova la riga seguente
server_names = ['cloudflare']
Cambialo nel nome host del tuo risolutore DoH. Si noti che la posizione dei parametri è importante. Non dovresti inserire i server_names parametro in altri punti di questo file.
server_names = ['doh.example.com']
Quindi commenta il [sources] sezione.
#[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 = ''
Dobbiamo aggiungere il nostro risolutore DoH come di seguito in fondo a questo file.
[static] [static.'doh.example.com'] stamp = 'sdns://AgUAAAAAAAAAAAAOZG5zLmdvb2dsZS5jb20NL2V4cGVyaW1lbnRhbA'
Il timbro contiene il nome host del risolutore DoH, l'indirizzo IP e il percorso della query. Per ottenere il tuo timbro, usa il calcolatore di timbri DNS online. Scegli DNS-over-HTTPS come protocollo e inserisci l'indirizzo IP, il nome host e il percorso della query. Se segui questo tutorial per configurare il tuo resolver DoH, il percorso dovrebbe essere impostato solo su / . Se non hai abilitato DNSSEC sul tuo resolver, deseleziona la casella di controllo DNSSEC.
Dopo aver aggiunto il timbro DNS, salva e chiudi il file. Quindi riavvia dnscrypt-proxy .
sudo systemctl restart dnscrypt-proxy
Controlla il suo stato. Assicurati che sia in esecuzione.
systemctl status dnscrypt-proxy
Ora puoi verificare se dnscrypt-proxy funziona.
Se non desideri pubblicare il tuo risolutore DNS su HTTPS nel mondo, puoi eliminare il record DNS A del nome host del tuo risolutore DoH, perché dnscrypt-proxy ha l'indirizzo IP nel timbro DNS.
Configura DoH su iOS
iOS supporta DNS su HTTPS da iOS 14. Tuttavia, non esiste una semplice opzione di configurazione su iOS per impostare il resolver DoH. Devi generare un .mobileconfig file e installalo su iOS. È un po' complicato generare un .mobileconfig iOS firmato file.
Se il tuo risolutore DoH non verrà utilizzato pubblicamente, puoi generare un semplice file non firmato. Usa un editor di testo per creare un file con .mobileconfig estensione. Copia e incolla il testo seguente. Sostituisci l'indirizzo IP e l'URL del server.
<?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>
Salva e chiudi il file. Quindi puoi inviare il file come allegato e-mail al tuo iOS. Apri l'e-mail su iOS e tocca l'allegato per scaricare il file di configurazione. Successivamente, vai su Settings di iOS -> Profile Downloaded . Ti verrà chiesto di installare il profilo.
Tocca il pulsante Installa e inserisci la tua password iOS per installarla. Tocca di nuovo il pulsante Installa.
Una volta installato, vai su Settings di iOS -> VPN & Network . Scorri verso il basso fino al pulsante per scegliere il risolutore DNS per il tuo sistema iOS. Nota che questo resolver DoH sovrascriverà il resolver DNS fornito da una VPN come ProtonVPN. Il tuo iOS utilizzerà sempre il tuo risolutore DoH.
Se mai vuoi rimuovere il .mobileconfig file da iOS, vai su Settings -> General -> Profile .
Fai in modo che DNSdist e il server web utilizzino la porta 443 contemporaneamente
Un risolutore DNS su HTTPS deve collegarsi alla porta 443. Se hai già Apache/Nginx in ascolto sulla porta 443, DNSdist non può collegarsi alla porta 443. Normalmente una porta può essere utilizzata solo da un processo. Tuttavia, possiamo utilizzare HAproxy (High Availability Proxy) e SNI (Server Name Indication) per fare in modo che DNSdist e Apache/Nginx utilizzino la porta 443 contemporaneamente.
Configurazione DNSdist
Modifica il file di configurazione DNSdist.
sudo nano /etc/dnsdist/dnsdist.conf
Modifica l'indirizzo di ascolto DoH in 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 }) Salva e chiudi il file. Quindi riavvia DNSdist.
sudo systemctl restart dnsdist
Configurazione Nginx
Se usi Nginx, modifica il file di blocco del server.
sudo nano /etc/nginx/conf.d/example.com.conf
Nel blocco del server SSL, trova la seguente direttiva.
listen 443 ssl;
Cambialo in
listen 127.0.0.2:443 ssl;
Questa volta lo facciamo ascoltare su 127.0.0.2:443 perché 127.0.0.1:443 è già preso da DNSdist. Salva e chiudi il file. Il file di configurazione principale di Nginx /etc/nginx/nginx.conf e il blocco server predefinito /etc/nginx/sites-enabled/default potrebbe includere un host virtuale predefinito in ascolto su 443, quindi potrebbe essere necessario modificare anche questo file.
Quindi riavvia Nginx.
sudo systemctl restart nginx
Configurazione di Apache
Se utilizzi il server Web Apache, modifica il file dell'host virtuale.
sudo nano /etc/apache2/sites-enabled/example.com.conf
Nell'host virtuale SSL, cambia
<VirtualHost *:443>
A
<VirtualHost 127.0.0.2:443>
Questa volta lo facciamo ascoltare su 127.0.0.2:443 perché 127.0.0.1:443 è già preso da DNSdist. Salva e chiudi il file. Quindi modifica il /etc/apache2/ports.conf file.
sudo nano /etc/apache2/ports.conf
Cambia
Listen 443
A
Listen 127.0.0.2:443
Salva e chiudi il file. Riavvia Apache.
sudo systemctl restart apache2
Configurazione HAProxy
Ora installa HAproxy.
sudo apt install haproxy
Avvia HAProxy
sudo systemctl start haproxy
Modifica file di configurazione.
sudo nano /etc/haproxy/haproxy.cfg
Se usi Nginx , copia e incolla le seguenti righe alla fine del file. Sostituisci 12.34.56.78 con l'indirizzo IP pubblico del tuo server. Sostituisci doh.example.com con il nome di dominio utilizzato da DNSdist e www.example.com con il nome di dominio utilizzato dal tuo server 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
Se usi Apache , copia e incolla le seguenti righe alla fine del file. Sostituisci 12.34.56.78 con l'indirizzo IP pubblico del tuo server. Sostituisci doh.example.com con il nome di dominio utilizzato da DNSdist e www.example.com con il nome di dominio utilizzato dal tuo server 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 Salva e chiudi il file. Quindi riavvia HAproxy.
sudo systemctl restart haproxy
Nella configurazione sopra, abbiamo utilizzato la funzione SNI (Server Name Indication) in TLS per differenziare il traffico VPN e il normale traffico HTTPS.
- Quando
doh.example.comè nel client TLS Hello, HAProxy reindirizza il traffico al backend DNSdist. - Quando
www.example.comè nel client TLS Hello, HAProxy reindirizza il traffico al backend apache/nginx. - Se il client non specifica il nome del server in TLS Client Hello, HAproxy utilizzerà il backend predefinito (DNSdist).
Puoi testare questa configurazione con openssl attrezzo. Innanzitutto, esegui il seguente comando più volte.
echo | openssl s_client -connect your-server-IP:443 | grep subject
Non abbiamo specificato il nome del server nel comando precedente, quindi HAproxy passerà sempre la richiesta al back-end predefinito (DNSdist) e il suo certificato verrà inviato al client. Quindi, esegui i seguenti due comandi.
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
Ora abbiamo specificato il nome del server nei comandi, quindi HAproxy passerà le richieste in base alle regole SNI che abbiamo definito.
Quando rinnovi il certificato Let's Encrypt per il tuo sito web, ti consigliamo di utilizzare il http-01 challenge invece di tls-alpn-01 sfida, perché HAproxy è in ascolto sulla porta 443 dell'indirizzo IP pubblico, quindi può interferire con il processo di rinnovo.
sudo certbot renew --preferred-challenges http-01