Cloudflare offre anche altre modalità di risoluzione ancora più efficaci:

1. DNS over HTTPS (DoH)
2. DNS over TCP (DoT)
3. 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. https://datatracker.ietf.org/meeting/interim-2021-masque-03/materials/slides-interim-2021-masque-03-sessa-masque-interim-2021-04-h3-dgram-00). 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-resolved

Un veloce test su https://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      MXP

indice 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 connect

Per terminare:

warp-cli disconnect

Questo 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 Cloudflare 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 = 25

Dopo 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_1

Affinché la connessione alla vpn parta all'avvio di OSMC, è necessario disporre di un servizio che:

1. esegua common-vpnd per caricare il file di configurazione
2. 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.target

Script 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_1

Inifine 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.service

E 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 delle 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

Perché wireguard?

• È più semplice di OpenVPN.
• Fa parte del kernel dalla versione 5.6 in poi (ci sono anche versioni in userspaces). Vanno installati solo i software di gestione del tunnel
• Si basa su uno strato di crittografia all'avanguardia per quel che riguarda efficienza e robustezza
• Il suo codice, estremamente compatto, viene revisionato con molta più facilità.
• Non si basa su un modello client-server ma P2P
• Il traffico è UDP piuttosto che TCP (ci sono modi per fare un wrapping TCP delle connessioni UDP)

1. Perché wireguard?
2. Crittografia di Wireguard
3. Un po' di teoria
4. Installazione
   1. Generazione chiavi
5. Attivazione del nodo
   1. PC/Laptop
   2. Mobile
6. Debug
7. Topologie
8. Point-To-Site
   1. Primo scenario
      1. Configurazione wireguard Endpoint A
      2. Configurazione wireguard Host B
      3. Configurazione routing/filtering Host B
      4. Test
      5. Tips
   2. Secondo scenario
      1. Configurazione wireguard Endpoint A
      2. Configurazione wireguard Host B
      3. Configurazione routing/filtering Host B
      4. Test
      5. Tips
   3. Terzo scenario
      1. Configurazione routing/filtering Host B
      2. Configurazione gateway Sito B
      3. Test
      4. Tips
   4. Differenze fra i 3 approcci

Crittografia di Wireguard

Le primitive crittografiche di Wireguard si basano su:

• Curve25519, per autenticazione e key exchange (ECDH)
• ChaCha20 e Poly1305, per la cifratura simmetrica con autenticazione (AEAD)
• BLAKE2, come hash crittografico
• SipHash-2-4, come funzione di hash crittografico con chiave (tipo HMAC)
• HKDF, come funzione di derivazione della chiave basata su HMAC
• Noise Framework, è un protocollo crittografico. Stabilisce il modo con cui tutte queste operazioni crittografiche vengono fatte lavorare.

Un po' di teoria

Wireguard implementa una vpn L3 solo tunneling, incapsulando pacchetti IP all'interno di pacchetti UDP per il trasporto. Ciò implica che funzioni come dhcp, essendo L2, non possono trovare spazio all'interno di wireguard, ergo l'indirizzamento (ip, subnet, dns) deve essere fatto staticamente.

Avendo un'anima P2P, ogni nodo (peer) wireguard è sia client che server. Ciò permette di realizzare topologie anche piuttosto complesse con uno sforzo relativamente ridotto.

Un peer wireguard è composto da due tipi di sezioni:

• una sezione “interface”, relativa al peer stesso, contenente:
  • il proprio IP, nello spazio di indirizzamento privato usato dalla vpn.
  • una porta, su cui il peer può essere in ascolto per accettare richieste da altri nodi wireguard
  • la parte privata della chiave asimmetrica con cui decifra e autentica
• una o più sezioni “peer”, relative ai nodi a cui può connettersi, contenenti:
  • la parte pubblica della chiave asimmetrica del peer, con cui cifra e verifica
  • AllowedIPs, che descrive l'ip o le reti da ruotare nel tunnel, a cui è consentito il traffico in entrata e a cui è diretto il traffico in uscita
  • l'endpoint del peer, necessario solo se altri peer devono avviare connessioni verso di lui

I nodi si autenticano a vicenda scambiandosi e convalidando le chiavi pubbliche. Ogni chiave pubblica è associata all'IP di un peer.

Quando un peer deve inviare dei pacchetti, AllowedIPs si comporta come una tabella di instradamento. Il peer esamina l'IP di destinazione di quel pacchetto e lo cerca negli AllowedIPs dei suoi peer per capire a chi inviarlo. Se lo trova, ruota il pacchetto nel tunnel, altrimenti no.

Quando si ricevono pacchetti, AllowedIPs si comporta come una lista di controllo degli accessi. Il peer esamina l'IP di origine e se rientra nell'AllowedIPs di uno dei suoi peer, accetterà il pacchetto altrimenti lo scarterà.

Per esperienza personale, il 99% degli errori di configurazione su wireguard viene fatto proprio sul campo AllowedIPs perché non se ne comprende bene il funzionamento.

Uno degli errori più comuni è quello di definire dei peer in cui gli ip contenuti nei campi AllowedIPs si sovrappongono. In base al funzionamento di wireguard infatti, non posso avere chiavi pubbliche diverse per uno stesso ip perché il peer, pur essendo in grado di ricevere pacchetti, non riuscirebbe a inviarli, non sapendo come ruotarli dovendo scegliere fra più peer.

Installazione

Come già detto, wireguard è presente di base nel kernel linux. Bisogna installare solo gli strumenti di interfacciamento per la configurazione su ogni host.

Per sistemi debian-based:

apt install wireguard wireguard-tools

Generazione chiavi

Per semplicità, suppongo di generare tutte le chiavi che mi occorrono, del server (host B) e del client (Endpoint A) in questo caso. Oltre alle chiavi, userò anche una pre-shared key per il client. Non è obbligatorio ma mi costa zero e aumenta la resistenza post-quantistica.

#server
wg genkey > server_wg.key
wg pubkey < server_wg.key > server_wg.pub

#client
wg genkey > endpoint-a_wg.key
wg pubkey < endpoint-a_wg.key > endpoint-a_wg.pub

# Creazione psk
wg genpsk > endpoint-a.psk

Attivazione del nodo

Una volta che la configurazione del nodo è pronta, va attivato il servizio se ci troviamo su un pc. Altrimenti bisognerà importare la configurazione sul device.

PC/Laptop

Sia esso un client o un server, una volta configurato il peer, salva il file file sotto /etc/wireguard/ col nome dell'interfaccia virtuale che hai scelto, nel mio caso, wg0.conf

Attivazione/Disattivazione vpn on-demand:

wg-quick up wg0 #attiva la vpn
wg-quick down wg0 #disattiva la vpn

Attivazione/Disattivazione vpn come servizio:

systemctl enable wg-quick@wg0
systemctl start/stop wg-quick@wg0.service

Mobile

Se il provisioning delle configurazioni si fa attraverso un pc, per portare facilmente la configurazione su un device mobile, si può generare un qrcode del file (supponiamo sia mobile.conf) e importarlo.

# Installazione qrencode (debian-based)
apt install qrencode

#Crea il qr-code e dallo in pasto a al client
qrencode -t ansiutf8 < mobile.conf

Debug

Wireguard è un modulo del kernel e quindi la sua attività viene raccolta dai log del kernel (/var/log/kern.log o /var/log/messages).

Bisogna verificare che sul kernel si possa abilitare il dynamic_debug_control, controllando se è presente:

ls /sys/kernel/debug/dynamic_debug

Se lo è, si carica il modulo, si setta il dynamic debug e si potrà esaminare log del kernel ad es. con journalctl -fk

modprobe wireguard
echo module wireguard +p | sudo tee /sys/kernel/debug/dynamic_debug/control

Potresti dover installare resolvconf sul server.

Quando wireguard fa salire l'interfaccia, la registra su systemd-resolve attraverso resolvconf e se non è installato potrebbe verificarsi un malfunzionamento.

Topologie

Le principali topologie che possono essere realizzate con wireguard sono:

• point-to-point
• point-to-site
• site-to-site
• hub-and-spoke (a stella)

Il canale sicuro fra i nodi wireguard viene creato attraverso le primitive crittografiche di cui sopra, ogni peer viene identificato da una chiave asimmetrica.

Non è necessario approfondire la parte di crittografia per capire come configurare wireguard. Ci fidiamo che faccia un buon lavoro.

Ciò su cui invece vale la pena soffermarsi, è la parte di instradamento, essenziale per l'implementazione delle topologie di cui sopra.

Io mi soffermerò sulla topologia più comune, point-to-site, che permette di unire un endpoint che esegue wireguard, con un altro endpoint situato all'interno di una LAN in cui c'è un host wireguard.

Tanto per fissare le idee indicherò:

• col termine peer, uno dei punti logici di una vpn wireguard
• col termine endpoint, uno dei punti di arrivo della tratta interessata dal tunnel vpn
• col termine host wireguard, l'host che esegue wireguard.

Osservazioni banali: – In una topologia point-to-point, host wireguard ed endpoint coincidono su entrambi gli estremi della tratta. – In una topologia point-to-site, host wireguard ed endpoint coincidono solo sul “point” (l'altro endpoint è dietro ad un host wireguard). – In una topologia site-to-site, gli endpoint sono sempre dietro gli host wireguard.

Point-To-Site

Avrò un Sito A che comprende il solo endpoint dove non ho la possibilità di gestire routing e filtering e un Sito B dove, al contrario, potrò impostare le mie policy di instradamento e filtraggio e dove sarà presente l'host wireguard (indicato come Host B, di solito) che fungerà da server.

La configurazione di un peer si divide in 3 tronconi:

• il listener
• l'instradamento dei pacchetti fra gli host wireguard e gli endpoint
• gli altri peers della VPN Wireguard

Gli scenari che andremo a considerare riguarderanno la direzione delle comunicazioni e le strategie adottate per realizzarle:

• da Endpoint A a Endpoint B (punto-sito)
• da Endpoint B a Endpoint A (sito-punto)
• bidirezionale (punto-sito-punto)

Prendendo uno scenario reale come riferimento, suppongo che la parte “point” sia dietro un NAT che nasconde l'ip privato dell'endpoint e permette solo connessioni già stabilite. Nella parte “site”, la lan è protetta da un firewall-router-nat che espone il solo ip pubblico.

Nella configurazione di filtering/routing sul firewall (ufw nel mio caso) di Host B, ci sarà da tenere conto delle politiche di inoltro. Per semplificarci la vita si potrebbe abilitare qualunque inoltro di default ma sarebbe un po' pericoloso quindi, a meno di casi particolari, anche gli inoltri saranno filtrati.

Primo scenario

Nel primo scenario, considererò il caso punto-sito, in cui un endpoint (con wireguard) si collega, nella LAN attraverso un host wireguard, all'endpoint che eroga un servizio.

Point-To-Site

Obiettivo: L'endpoint del sito B (192.168.1.3) ha un servizio web https sulla porta 443, che non è raggiungibile dall'esterno. Possiamo usare wireguard per permettere all'Endpoint A di raggiungere il servizio sugli endpoint del sito B, per mezzo dell'host wireguard B. Affinché l'host B possa inoltrare i pacchetti dall'Endpoint A all'Endpoint B si ricorre al SNAT (MASQUERADING).

Point-To-Site: Masquerading

Configurazione wireguard Endpoint A

[Interface]
Address = 10.0.0.2/32
SaveConfig = true
PrivateKey = <Contenuto di endpoint-a_wg.key>

[Peer]
PublicKey = <Contenuto di server_wg.pub>
PresharedKey = <Contenuto di endpoint-a.psk>
Endpoint = 200.76.182.23:51820
AllowedIPs = 192.168.1.0/24

Dettagli:

• Interface.Address: IP dell'Endpoint A nella rete virtuale definita da wireguard
• Interface.SaveConfig: se è true, qualunque modifica fatta al file di configurazione prima dello spegnimento dell'interfaccia verrà ignorato.
• Interface.PrivateKey: la chiave privata dell'Endpoint A
• Peer.PublicKey: La chiave pubblica dell'host B wireguard
• Peer.PresharedKey: La preshared key dell'Endpoint A
• Peer.Endpoint: L'ip esposto dell'host B wireguard. Potrebbe trovarsi dietro un firewall/nat ma tanto sappiamo che sul sito B ho libertà d'azione
• Peer.AllowedIPs: Sono le reti che voglio ruotare nel tunnel. Possono essere singoli ip o subnet separati da “ , “. 0.0.0.0/0 equivale a ruotare tutto il traffico del peer nella VPN wireguard. Nel caso in esame, ruoto nel tunnel solo la lan del sito B. Il resto del traffico è al di fuori della VPN wireguard (split tunnel)

Configurazione wireguard Host B

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = <Contenuto di server_wg.key>

# endpoint A
[Peer]
PublicKey = <Contenuto di endpoint-a_wg.pub>
PresharedKey = <Contenuto di endpoint-a.psk>
AllowedIPs = 10.0.0.2/32

Dettagli:

• Interface.Address: ip dell'host B nella rete virtuale definita da wireguard
• Interface.SaveConfig: se è true, qualunque modifica fatta al file di configurazione prima dello spegnimento dell'interfaccia verrà ignorato.
• Interface.PrivateKey: la chiave privata dell'host B
• Peer.PublicKey: La chiave pubblica dell'Endpoint A
• Peer.PresharedKey: La preshared key dell'Endpoint A
• Peer.AllowedIPs: Dovendo contattare il singolo endpoint, AllowedIPs definito nel peer è l'ip del peer stesso all'interno della rete virtuale definita da wireguard.

Non poteva essere altrimenti. In una topologia point-to-site,

• da point verso site, AllowedIPs della sezione [Peer] del point indirizza una o più subnet.
• da site verso point, AllowedIPs della sezione [Peer] nell'host wireguard indirizza puntualmente l'Endpoint A.

Inoltre, sempre in una topologia point-to-site, è sempre il point ad iniziare la connessione per cui:

• nel point:
  • si deve specificare l'Endpoint (<fqdn_or_ip:port>) nella sezione [Peer] relativa al server wireguard.
  • non importa specificare la ListenPort nella sezione Interface che può essere scelta casualmente, perché l'Endpoint A non verrà mai contattato direttamente
• nel site:
  • non importa specificare l'Endpoint (<fqdn_or_ip:port>) nella sezione [Peer] relativa all'Endpoint A, perché non sarà mai in attesa di una connessione
  • si deve specificare la ListenPort nella sezione [Interface] perché le connessioni sono sempre iniziate dagli endpoint verso di lui

Configurazione routing/filtering Host B

Il resto della configurazione non riguarda più wireguard direttamente ma riguarda l'insieme di policy di routing e filtering da fare sull'host B per permettere ai pacchetti dell'Endpoint A di essere inoltrati all'Endpoint B attraverso l'host B.

Affinchè i pacchetti possano viaggiare dall'Endpoint A all'Endpoint B:

• i pacchetti arriveranno all'host B sull'interfaccia virtuale della VPN (wg0)
• poi verranno inoltrati dall'interfaccia virtuale della vpn (wg0) all'interfaccia reale di host B (eth0),
• prima di essere inviati a Endpoint B, una regola di post-routing riscriverà i pacchetti cambiandone l'ip sorgente in modo che risultino inviati da host B piuttosto che da Endpoint A, così da permettere ad Endpoint B di rispondere.

Quindi:

• va configurato un inoltro (eventualmente filtrato) dall'interfaccia virtuale wireguard (wg0) a quella reale dell'host B (eth0)
• deve essere configurato il SNAT affinché l'Endpoint B possa rispondere all'Endpoint A

# abilita il forward
sysctl -w net.ipv4.ip_forward=1
# inoltra tutto il traffico in arrivo da wg0 verso il solo Endpoint B
ufw route allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443;
# masquerading
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

N.B. potrei ancora raffinare queste regole ricorrendo alla tabella Mangle per marcare i pacchetti ai quali applicare il masquerading.

Questi comandi possono far parte della configurazione. Nella sezione [Interface] si possono usare i costrutti PreUp, PreDown, PostUp e PostDown per rendere dinamici alcuni passi di configurazione prima/dopo l'apertura/chiusura del tunnel. E così, la configurazione del server diventa:

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = <Contenuto di server_wg.key>

# IP forwarding
PreUp = sysctl -w net.ipv4.ip_forward=1
PreUp = ufw route allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp to 192.168.1.3 port 443

# IP masquerading
PreUp = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

# IP filtering
PreUp = ufw allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
PostDown = ufw delete allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;

# endpoint A
[Peer]
PublicKey = <Contenuto di endpoint.a_wg.pub>
PresharedKey = <Contenuto di endpoint-a.psk>
AllowedIPs = 10.0.0.2/32

Test

Da Endpoint A (192.168.10.10) possiamo raggiungere il servizio come se fossimo nella lan del sito B, quindi:

curl https://192.168.1.3

risponderà al browsing.

Tips

La combinazione AllowedIPs / routing è la chiave per gestire qualunque instradamento. Nell'esempio visto finora abbiamo fatto in modo che:

• l'Endpoint A ruotasse nella VPN wireguard solo la subnet relativa al sito B, 192.168.1.0/24, facendo split tunnel per il resto.
• l'host B avesse delle regole di inoltro per l'Endpoint B per i soli pacchetti destinati al servizio che eroga, https. Qualuque altro host del sito B non può essere raggiunto.

In questo modello, qualunque altro endpoint abilitato alla VPN wireguard potrebbe accedere al servizio dell'Endpoint B. Vale la pena dare un'occhiata ad un altro paio di combinazioni che si trovano agli opposti del nostro esempio. In un caso, ruoteremo tutto il traffico verso la vpn, in un altro consentiremo solo a determinati peer, non a tutti, di fruire di determinati servizi.

1. Inoltro di tutto il traffico nella vpn In questo modo, l'Endpoint A lavora come se facesse parte della lan del sito B. È una modalità totalmente anonimizzante. Da usare solo con dispositivi trusted perché un eventuale traffico malevolo verrebbe ruotato nel tunnel e risulterebbe proveniente dal sito B

Su Endpoint A:

...
AllowedIPs = 0.0.0.0/0
...

Su host B:

...
ufw route allow in on wg0 out on eth0;`
...

2. Indirizzamento puntuale su servizi specifici È il caso in cui alcuni peer debbano raggiungere solo determinati servizi e non altri. Supponiamo di avere altri due endpoint, Endpoint A₁ e Endpoint A₂.

Su Endpoint A₁ e A₂ (in realtà AllowedIPs potrebbe essere puntuale):

...
AllowedIPs = 192.168.1.0/24
...

...
PreUp = ufw route allow in on wg0 out on eth0 proto tcp from 10.0.0.3 to 192.168.1.4 port 3306
PreUp = ufw route allow in on wg0 out on eth0 proto tcp from 10.0.0.4 to 192.168.1.5 port 22
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp from 10.0.0.3 to 192.168.1.4 port 3306
PostDown = ufw route delete allow in on wg0 out on eth0 proto tcp from 10.0.0.4 to 192.168.1.5 port 22
...

Secondo scenario

Nel secondo scenario, ribalterò il punto di vista e prenderò in esame il caso in cui sia un host del sito B a contattare un endpoint esterno con wireguard (sito-punto). Non il classico scenario road-warrior in cui un endpoint deve raggiungere la rete aziendale o domestica, ma il suo opposto.

Site-To-Point

Obiettivo: L'host del sito A (192.168.10.10) ha un servizio web https sulla porta 1443, che non è raggiungibile dall'esterno ma vogliamo che lo sia dal sito B. Con wireguard, possiamo usare l'interfaccia virtuale per esporre il servizio su 10.0.0.2, verso gli endpoint del sito B, per mezzo dell'host wireguard B. Affinché l'host B possa inoltrare i pacchetti dall'Endpoint B all'Endpoint A si ricorre al DNAT (PORT FORWARDING).

Site-To-Point: Port-Forwarding

La configurazione di wireguard su host B rimane sostanzialmente identica rispetto a prima. A cambiare sarà soprattutto la parte di filtering e routing.

Configurazione wireguard Endpoint A

[Interface]
Address = 10.0.0.2/32
SaveConfig = true
PrivateKey = <Contenuto di endpoint-a_wg.key>

[Peer]
PublicKey = <Contenuto di server_wg.pub>
PresharedKey = <Contenuto di endpoint-a.psk>
Endpoint = 200.76.182.23:51820
AllowedIPs = 192.168.1.0/24
PersistentKeepalive = 25

Su Endpoint A c'è una piccola modifica.

Dettagli:

• PersistentKeepalive: Il NAT davanti all'Endpoint A potrebbe troncare la connessione dopo un po' visto che non è lui ad avviarla. Dal momento che è Endpoint A a dare servizio, si ricorre al keepalive per mantenere la connessione persistente.

Configurazione wireguard Host B

[Interface]
Address = 10.0.0.1/24
SaveConfig = true
ListenPort = 51820
PrivateKey = <Contenuto di server_wg.key>

# endpoint A
[Peer]
PublicKey = <Contenuto di endpoint-a_wg.pub>
PresharedKey = <Contenuto di endpoint-a.psk>
AllowedIPs = 10.0.0.2/32

La configurazione di Host B rimane sostanzialmente invariata.

Configurazione routing/filtering Host B

Affinchè i pacchetti possano viaggiare dall'Endpoint B all'Endpoint A:

• i pacchetti arriveranno sull'interfaccia reale di host B (eth0),
• una regola di pre-routing riscriverà i pacchetti cambiandone l'ip di destinazione con quello virtuale dell'Endpoint A
• poi verranno inoltrati dall'interfaccia reale di host B (eth0) all'interfaccia virtuale della VPN (wg0) che li recapiterà ad Endpoint A

Quindi

• va configurato un inoltro (eventualmente filtrato) dall'interfaccia reale dell'host B (eth0) a quella virtuale wireguard (wg0)
• deve essere configurato il DNAT affinché l'Endpoint B possa contattare l'Endpoint A.

...
# IP forwarding
# abilita il forward
PreUp = sysctl -w net.ipv4.ip_forward=1
# inoltra tutto il traffico in arrivo da eth0 verso l'Endpoint A
PreUp = ufw route allow in on eth0 out on wg0 proto tcp to 10.0.0.2 port 443
PostDown = ufw route delete allow in on eth0 out on wg0 proto tcp to 10.0.0.2 port 443

# IP port forwarding
# inoltro della porta 1443 dall'interfaccia lan verso la porta 443 dell'Endpoint A
PreUp = iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:1443
PostDown = iptables -t nat -D PREROUTING -i eth0 -p tcp --dport 443 -j DNAT --to-destination 10.0.0.2:1443

# IP filtering
PreUp = ufw allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
PostDown = ufw delete allow in on eth0 proto udp from 0.0.0.0/0 to 192.168.1.2 port 51820;
...

Test

Da Endpoint B (192.168.1.3) possiamo raggiungere il servizio sull'interfaccia virtuale dell'Endpoint A passando dalla porta dell'host B, quindi:

curl https://192.168.1.2

risponderà al browsing.

Tips

In questa rappresentazione, ogni host del sito B viene indirizzato solo verso la vpn wireguard. L'host B inoltra:

• la porta 443 di ogni host del sito B verso l'Endpoint A
• tutto il traffico della lan verso la vpn wireguard.

Se volessimo che solo determinati endpoint del sito B potessero inoltrare il loro traffico, si dovrebbero rendere le regole di inoltro più puntuali. Supponiamo che Endpoint A (10.0.0.2) esponga un servzio httpd sulla porta 10080 e vogliamo che solo gli host 192.168.1.9-192.168.1.14 del sito B lo possano raggiungere sulla canonica porta 80.

Port Forwarding di un solo endpoint

ufw route allow from 192.168.1.4 to 10.0.0.2 port 10080 proto tcp
iptables -t nat -A PREROUTING -s 192.168.1.4 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:10080

Port Forwarding di una subnet

ufw route allow from 192.168.1.8/29 to 10.0.0.2 port 10080 proto tcp
iptables -t nat -A PREROUTING -s 192.168.1.9-192.168.1.14 -p tcp --dport 80 -j DNAT --to-destination 10.0.0.2:10080

Terzo scenario

Il terzo scenario può essere considerato un'unione dei primi due.

Point-To-Site-To-Point

Obiettivo: L'host del sito A (192.168.10.10) espone un servizio di remote desktop (porta 3389), l'endpoint del sito B (192.168.1.3) espone un servizio web https sulla porta 443. Vogliamo che l'Endpoint A raggiunga il servizio web e che l'Endpoint B acceda al desktop remoto dell'Endpoint A.

Point-To-Site: Gateway

Se viene configurato il routing sul gateway per indirizzare wireguard, il traffico potrà essere bidirezionale. Non ci sarà bisogno di manipolare i pacchetti perché:

1. Da Endpoint A a Endpoint B, i pacchetti inoltrati da host B avranno come sorgente l'ip della rete wireguard di Endpoint A.
2. Attraverso il gateway, Endpoint B potrà rispondere/contattare direttamente l'indirizzo sorgente wireguard di Endpoint A.

La configurazione di wireguard su Endpoint A e Endpoint B è assimilabile allo scenario 2 con l'impostazione del PersistentKeepAlive su Endpoint A

Configurazione routing/filtering Host B

Al solito va configurato l'inoltro su Host B da Endpoint A a B e viceversa

...
PreUp = ufw route allow in on wg0 out on eth0 to 192.168.1.3 port 443 proto tcp
PostDown = ufw route delete allow in on wg0 out on eth0 to 192.168.1.3 port 443 proto tcp
PreUp = ufw route allow in on eth0 out on wg0 from 192.168.1.3 port 3389 proto tcp
PostDown = ufw route delete allow in on eth0 out on wg0 from 192.168.1.3 port 3389 proto tcp
...

Configurazione gateway host del Sito B

A parte attivare il solito inoltro su host B, bisognerà avere la possibilità di configurare il routing anche sul nostro router (192.168.1.1), in maniera che Endpoint B, che presumbilmente ha proprio 192.168.1.1 come gateway di default, indirizzando Endpoint A, venga rediretto verso Host B. Ad es.

ip route add 10.0.0.2/32 via 192.168.1.2 dev eth0

In alternativa, se non si ha la possibilità/voglia di configurare il router, bisognerà configurare Endpoint B con la rotta statica indicata prima.

Test

Da Endpoint A (192.168.10.10) possiamo raggiungere il servizio come se fossimo nella lan del sito B, quindi:

curl https://192.168.1.3

Da Endpoint B (192.168.1.3) raggiungiamo il desktop remoto dell'Endpoint A attraverso la sua interfaccia virtuale (10.0.0.2)

rdesktop 10.0.0.2

Tips

Si potrebbe pensare di aggregare le potenziali rotte statiche considerando l'intera subnet wireguard per avere un'unica rotta statica su tutti gli host del sito B configurando sul nostro router (oppure su tutti gli host del sito B):

ip route add 10.0.0.0/24 via 192.168.1.2 dev eth0

In questo modo, ogni host del sito B può indirizzare vicendevolmente il suo traffico verso endpoint esterni purché le regole wireguard lo consentano (AllowedIPs)

Differenze fra i 3 approcci

Primo scenario: l'Endpoint A contatta l'Endpoint B sul suo indirizzo reale ma l'Endpoint B non ha idea di chi siano gli endpoint, lato “punto”, che lo contattano (per effetto del masquerading, le connessioni agli Endpoint B partono da host B).

Secondo scenario: l'Endpoint B non può contattare direttamente gli endpoint lato “punto” ma contatterà l'host B e sarà il DNAT a veicolare i pacchetti agli endpoint lato “punto”.

Terzo scenario: potendo configurare il router (o gli host del sito B), è l'approccio più semplice e garantisce bidirezionalità senza manipolazione dei pacchetti.

Riferimenti:

• https://www.wireguard.com/

#vpn #openvpn #wireguard #CryptokeyRouting

Sono in “vacanza” ma, come tantissimi ormai, in caso di necessità uso una connessione vpn (cisco) per accedere alla rete aziendale.

E qui interviene il destino cinico e beffardo. Il router domestico che mi ospita, è un router telecom AGHP e, come sempre in questi casi, la prima cosa che faccio, pur avendo già provato la mattina da casa, è testare la vpn dal mio portatile.

E qui la prima sorpresa: connessione in corso… stonf! una, due, tre volte. Nulla.

Senza un vero motivo, cancello la configurazione e provo a rimetterla.

Ed è la prima scornata.

Non riesco più farlo. Il pulsante “Add” rimane inspiegabilmente, sempre, disattivato.

Ok, don’t panic. Riassumendo, il client vpn non sembra funzionare. In più non posso più configurarlo da Gnome.

Lo stesso, irrazionale, motivo che mi aveva portato a cancellare la configurazione, mi spinge a configurare un altro client: vpnc. Tanto peggio di così...

Funziona!

La situazione mi sta sfuggendo di mano ma, se non altro, ho un piano B.

Rimane il fatto che il client gnome-network-manager sembra avere un problema con la configurazione di una vpn cisco e siccome non mi piace avere qualcosa che zoppica così vistosamente, pur avendo un piano B, decido di andare un po’ in profondità (=lurkare su google).

Ed ecco che scopro l’arcano.

Si tratta di un bug su gnome che c’è da almeno un anno e che mi trascino, probabilmente, minimo da Fedora 36. Avendo già una configurazione, non me n’ero mai reso conto finché non mi sono “creata” la necessità.

I workaround suggeriti prevedono:

• l’uso di vpnc.
• l’uso di nm-connection-editor.

In questo 3d viene spiegato come il problema sia presente da tempo, segnalato già sui bug reports dei progetti:

• Gnome
• NetworkManager
• Ubuntu

e che è stato rilasciato un fix un mesetto fa.

Non che sia proprio immediato, il processo NON È intuitivo, bisogna seguire uno schema preciso altrimenti nemmeno qui il pulsante add sarà disponibile), il problema di fondo è che bisogna indicare esplicitamente l’interfaccia tunnel che verrà usata nella connessione vpn (es. tun0). Una volta risolto, c’è ancora un piccolo effetto collaterale: la configurazione comparirà su nm-connection-editor, si potrà selezionare dal menù di stato ma non sarà visibile nelle impostazioni di rete.

Guardando un po’ più a fondo scopro che la stessa cosa potevo ottenerla con gnome-network-manager. Basta che, prima di digitare anche un solo carattere (altrimenti non funziona), si indichi l’interfaccia tunnel da usare e SOLO DOPO si completa la configurazione.

In sostanza, dalla mancata connessione in vpn, scopro un difetto di cui ero all’oscuro e che ho tamponato con configurazioni ad-hoc su nm-connection-editor o su gnome-network-manager.

Rimane il mistero che l’unico client a funzionare sia vpnc, quando anche gnome-network-manager usa vpnc come backend e i log non mi dicono granché, solo un generico errore:

NetworkManager[1345]: manager: (tun1): new Tun device (/org/freedesktop/NetworkManager/Devices/43)
NetworkManager[127855]: /usr/sbin/vpnc: no response from target

Sempre per non tralasciare nulla, provo ad andare in tethering e, con nemmeno troppa sorpresa, stavolta gnome-network-manager funziona!

Riassumendo:

1. c’è un bug che impedisce la corretta configurazione di una vpn cisco da gnome-network-manager
2. da questo benedetto router telecom, il client vpnc funziona, gnome-network-manager (che usa vpnc come backend) no.
3. in tethering, funziona tutto come si deve.

#fedora37 #gnome #vpn #gnomenetworkmanager #nmconnectioneditor #vpnc