Installazione di Cloudflare WARP su OSMC
È noto come l'uso dei resolver Cloudflare sia uno dei modi per anonimizzare il proprio IP all'ISP.
Cloudflare offre anche altre modalità di risoluzione ancora più efficaci:
- DNS over HTTPS (DoH)
- DNS over TCP (DoT)
- DNS over WARP (DoW)
I primi due sono relativi a richieste dns crittografate e incapsulate, in una richiesta https (porta 443) la prima, e in una connessione TLS (porta 853) la seconda.
La terza modalità è una richiesta dns in chiaro ma all'interno di un tunnel Wireguard o MASQUE (QUIC + HTTP/3 – rif. datatracker.ietf.org/meeting/i…). Molto interessante ed è quella che approfondirò in seguito.
Senza entrare nel merito, tutte le soluzioni anonimizzano le query dns. L'ultima, quella che mi ha stutzzicato, è in realtà un tunnel vpn che crittografa TUTTO il traffico, non solo le richieste DNS.
DoT è una cifratura TLS che lascia intatto il pacchetto UDP iniziale, è quindi più efficiente di DoH che converte una richieste DNS in una HTTP cifrata dal layer TLS.
DoT di solito viene fatta a livello di dispositivo, DoH per singole applicazioni.
DoT, basandosi su una porta specifica, 853, è facilmente identificabile (e bloccabile) come traffico DNS (benché cifrato), DoH è una richiesta HTTPS e si mescola col traffico che viaggia sulla porta 443 (difficilmente si invaliderà tutto quel tipo di traffico).
DoT, DoH, DoW, mitigano notevolmente il cache poisoning dei resolver perché rendono quasi impossibilie per un attaccante alterare una richiesta che viene protetta per l'intero percorso. Va detto che la soluzione ideale in questo contesto è la combinazione con DNSSEC, che fornisce autenticità e integrità alla riservatezza fornita da DoH/DoT.
Anche se l'obiettivo rimane l'approfondimento di CLoudflare WARP, vale la pena di spendere due parole anche sulle altre modalità di risoluzione, DoT/DoH
Configurare risoluzioni DNS DoH
Configurare DoH è molto semplice perché è qualcosa legato all'applicazione, il browser tipicamente. Se l'applicazione lo supporta, di solito è poco di più di un flag da abilitare.
Ad es. Firefox o Chrome permettono di attivare una sorte di “protezione avanzata del DNS” indicando semplicemente un resolver che la supporti (es. Cloudflare, NextDNS o Quad9).
Configurare risoluzioni DNS DoT
DoT, come detto, è una configurazione che avviene a livello di dispositivo, l'anonimizzazione delle query DNS si ottiene quindi per ogni applicazione. Sul come farlo, dipende dal dispositivo.
Ad es. su una linux box basta aggiungere due righe su systemd-resolved e riavviare il relativo servizio.
sudo vi /etc/systemd/resolved.conf
...
DNS=1.1.1.1
DNSOverTLS=yes
# dopo aver salvato il file
systemctl restart systemd-resolvedUn veloce test su 1.1.1.1/help (da qualunque browser) ci mostrerà qualcosa del tipo:
Connected to 1.1.1.1 Yes
Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) Yes
Using DNS over WARP No
AS Name Cloudflare, Inc.
AS Number 13335
Cloudflare Data Center MXPindice che DoT è attivo e funzionante. Lo stesso test poteva essere fatto anche per DoH.
Cloudflare WARP
E poi c'è DoW, che è qualcosa di ancora più estremo perché, all'occorrenza, anonimizza non solo le richieste DNS ma tutto il nostro traffico (e infatti diversi servizi di streaming non lo consentono).
Cloudflare Warp attiva diverse modalità di risoluzione dns fra cui DoH e DoT.
Dal momento che Cloudflare Warp agisce su tutta la connessione, è il modo più semplice per avere risoluzione dns di tipo DoH o DoT, su qualunque dispositivo su cui è presente Cloudflare Warp senza gli sbattimenti di systemd o altro.
Cloudflare Warp in modalità tunnel è un client che instaura un collegamento cifrato punto-punto (un tunnel) fra il nostro host e un endpoint Cloudflare. In questo modo ogni bit che esce dal nostro dispositivo viene cifrato prima della comunicazione, che diventa così totalmente schermata.
La vpn di Coudflare si basa su wireguard o su MASQUE. Nel primo caso è una normale vpn con un setup roadwarrior, il secondo caso offre in più la possibilità di associare al tunnel anche le modalità DoH/DoT per le richieste dns.
Anonimato sì/no?
Cloudflare WARP è uno strumento incentrato sulla sicurezza, progettato per crittografare il traffico internet e proteggere la privacy dagli ISP, piuttosto che per garantire l'anonimato completo o nascondere la posizione dell'utente.
Sostituisce l'IP dell'utente con un IP di Cloudflare che generalmente corrisponde alla sua reale area geografica, rendendolo inadatto a eludere le restrizioni basate sulla posizione.
Non è una VPN tradizionale. WARP non maschera la nostra posizione ai siti web, che spesso possono visualizzare la tua posizione approssimativa.
Per migliorare la privacy, si dovrebbe utilizzare il protocollo MASQUE, che offre anche una maggiore efficienza.
In sintesi, WARP fornisce un “tunnel sicuro” per proteggere la privacy dei dati da amministratori di rete indiscreti, protegge il traffico perché eccelle nella crittografia del traffico su reti non sicure (ad esempio, Wi-Fi pubbliche), ma non offre le funzionalità di anonimato dei tradizionali servizi VPN incentrati sulla privacy.
Fatta questa doverosa premessa, vediamo come può essere usato.
Configurare Cloudflare WARP
L'installazione del client è molto semplice. Per Gnu/Linux c'è la versione cli, per android un app, per altri sistemi, Win /MacOS, un installer. La parte applicativa prima di tutto registra il dispositivo sulla rete Cloudflare generando degli ID e una chiave di licenza. In un secondo momento si generano le chiavi di cifratura.
Per fissare le idee, una volta fatte le operazioni di inizializzazione, sulla linux box per tunnellizzare ogni nostra comunicazione con una risoluzione DoT, basta:
# facoltativo
warp-cli mode warp+dot
#connessione
warp-cli connectPer terminare:
warp-cli disconnectQuesto approccio torna molto comodo quando per es. vogliamo usare wifi pubbliche, in città o in aeroporto. A meno di non avere un'installazione personale di una nostra vpn, questa è una soluzione immediata. Certo, bisogna fidarsi di Clooudflare ma è certamente meglio che fidarsi delle wifi free.
E arriviamo al caso d'uso che volevo approfondire riguardante l'“anonimizzazione” di un mediacenter casalingo per il quale non vogliamo rendere noto il suo utilizzo.
L'esperienza che ho avuto al proposito è stata interessante, visto che uso da anni OSMC su una RasbPi 3 e ho deciso di metterla dietro Cloudflare.
OSMC insieme a LibreELEC sono ottime soluzioni di mediacenter per SBC. La prima più “general”, essendo una debian customizzata per ospitare un mediacenter, la seconda invece meno elastica ma più essenziale ed efficiente.
Nonostante la Raspberry Pi 3 sia dotata di un processore ARM64, la versione di OSMC che ho installato a suo tempo è a 32 bit e per quella non c'è disponibilità per il client cloudflare (solo ARM64).
Ho dovuto ricorrere ad un client “unofficial”, wgcf, che permette di registrare il dispositivo e di generare le chiavi ma solo per la modalità Wireguard, non MASQUE, quindi niente Warp+DoT/DoH (per inciso, wgcf rappresenta un'ottima alternativa anche per chi non vuole usare il client Cloudflare su Gnu/Linux).
A questo aggiungo che, sebbebe OSMC sia una Debian su cui posso installare e configurare tanta roba, l'installazione di Wireguard, e penso di qualunque cosa che vada a toccare lo stack di rete, diventa qualcosa di estremamente complicato da fare, dal momento che OSMC si rifiuta categoricamente di eseguire operazione che metterebbero a rischio il suo essere un mediacenter, fondamentalmente.
Tradotto in soldoni, il client wireguard si installa, sale su correttamente ma non c'è verso di far funzionare la risoluzione. L'unica via d'usicta è stata configurare Wireguard attraverso il gestore di rete di OSMC che è connman.
Una volta fatto questo, sono stati necessari solo un paio di piccoli accorgimenti per far si che, in seguito all'avvio del mediacenter, la configurazione vpn venisse caricata automaticamente da connman, contestualmente alla connessione vpn.
Configurazione wgcf
# Account cloudflare
curl -L https://github.com/ViRb3/wgcf/releases/latest/download/wgcf_2.2.30_linux_armv7 -o /usr/local/bin/wgcf
chmod u+x /usr/local/bin/wgcf
wgcf register
wgcf generate
# status & trace
wgcf status
curl https://www.cloudflare.com/cdn-cgi/trace Configurazione connman
Su OSMC connman ha i suoi file di configurazione in /var/lib/connman e /var/lib/connman-vpn
Nel file di configurazione, l'host va indicato con l'ip non con l'fqdn (engage.cloudflareclients.com)
# Configurazione wireguard cloudflare
# La configurazione della vpn deve essere un file .config sotto /var/lib/connman-vpn
vi /var/lib/connman-vpn/cloudflare_warp.config
[provider_*]
Type = WireGuard
Name = Cloudflare_WARP
Host = 162.159.192.1
AutoConnect = true
WireGuard.Address = 172.16.0.2/24
WireGuard.ListenPort = 51280
WireGuard.PrivateKey = <my_private_key>
WireGuard.PublicKey = <cloudlare_wg_public_key>
WireGuard.DNS = 1.1.1.1, 1.0.0.1
WireGuard.AllowedIPs = 0.0.0.0/0
WireGuard.EndpointPort = 2408
WireGuard.PersistentKeepalive = 25Dopo aver creato il file di configurazione, possiamo vedere il nuovo servizio pronto per essere richiamato da
comman-vpnd# elenco servizi attivi
connmanctl services
* AO <SSID> wifi_<id>_managed_psk
* R Cloudflare_WARP vpn_162_159_192_1Affinché la connessione alla vpn parta all'avvio di OSMC, è necessario disporre di un servizio che:
- esegua
common-vpndper caricare il file di configurazione - effettui la connessione vpn
# Creazione nuovo servizio in /lib/systemd/system/connman-vpn.service
[Unit]
Description=ConnMan VPN service
After=network-online.target
Wants=network-online.target
[Service]
Type=dbus
BusName=net.connman.vpn
ExecStart=/usr/sbin/connman-vpnd -n
ExecStop=/usr/local/bin/vpn-autoconnect.sh
StandardOutput=null
Restart=on-failure
[Install]
WantedBy=multi-user.targetScript richiamato dal servizio per la connessione alla vpn:
# connessione vpn
vi /usr/local/bin/vpn-autoconnect.sh
#!/bin/bash
# Attende che il demone VPN sia pronto
sleep 5
# Tenta la connessione (usa il nome esatto che vedi in connmanctl services)
connmanctl connect vpn_162_159_192_1Inifine si rende il file eseguibile e si avvia il servizio
chmod +x /usr/local/bin/vpn-autoconnect.sh
# avvio servizio
systemctl daemon-reload
systemctl enable connman-vpn.service
systemctl start connman-vpn.serviceE il gioco è fatto.
Da questo momento in poi, OSMC tunnellizza tutto il suo traffico verso Cloudflare.
Come detto, in questo modo ho “solo” la configurazione di un tunnel wireguard verso l'endpoint Cloudflare, non dispongo di altre funzionalità che warp-cli offre.
Tuttavia è un procedimento abbastanza trasparente che non prevede la convivenza con ulteriori servizi come nel caso di warp-cli e che può essere un'alternativa anonimizzante valida anche su una linux box normale.
#dns #doh #dot #warp #vpn #tunnel #cloudflare #wireguard #masque #osmc