[gl-como] engarde

[Alessandro Rinaldi]

Ciao Luca,
innanzitutto voglio ringraziarti per aver trovato il tempo di darmi una
risposta decisamente articolata. Rispondo inline:

Prima un disclaimer: _non_ conosco abbastanza WireGuard, ma me lo immagino
> che un generico VPN tool che incapsula i dati in UDP tra i due endpoint (un
> po’ stile OpenVPN quando è veicolato su UDP).
>
Sostanzialmente sì, però rispetto ad altre soluzioni ha dei vantaggi
tangibili.
- Non ha un'architettura fortemente client-server: i peer possono
comunicare fra loro direttamente, o routati attraverso un gateway, o alcuni
in un modo e alcuni in un altro. Su ogni peer puoi impostare come
raggiungere ognuno degli altri, cosa che rende comodo, ad esempio, creare
una rete locale in cui i client comunican direttamente fra loro
(velocemente) ma un peer esterno li raggiunge comunque tutti.
- Il driver di rete che si occupa di gestire il tutto è un modulo del
kernel e non gira nello userspace, le prestazioni ne giovano.
- La configurazione è molto, ma molto molto, più semplice e intuitiva di
qualunque altra soluzione analoga. I client si riconoscono in base a una
coppia di chiavi basate su curve ellittiche, corte e comode ma molto sicure.
- Non ha un forte concetto di stato: viene sì fatto un handshake per
stabilire delle chiavi di sessione, ma questo può essere ripetuto in ogni
momento senza invalidare ad esempio le connessioni TCP attive sul tunnel.
Ogni peer memorizza la coppia IP-porta da cui ha ricevuto l'ultimo
pacchetto da ogni altro peer, e usa l'informazione quando deve mandare
pacchetti. Questo fa sì che tu possa disconnetterti, riconnetterti,
cambiare connessione, ... senza che il tunnel ne risenta.

Potrei stare tutta sera a parlare di come mi sono innamorato di WireGuard,
ma penso di aver reso l'idea :D
Ha anche dei difetti, sicuramente: il principale secondo me è il fatto di
lavorare al layer 3, e quindi di non poter creare dei tunnel Ethernet e
creare una rete unificata con broadcasting sensato e tutto quanto. Certo,
puoi sempre farci girare sopra un OpenVPN in Layer 2, ma inizia a diventare
una gran brutta matrioska.



> Poi un altro disclaimer: _non_ parlo Golang quindi non ho nemmeno provato
> a sbirciare nei sorgenti
>
In realtà, anche io sono un neofita: ho iniziato a usarlo da un mesetto. In
realtà se leggi il codice ti assicuro che è molto lineare, e comunque ti
consiglio vivamente di approfondirlo: è duttile (quasi) come un linguaggio
interpretato, ma le prestazioni sono ben altre!



> Commenti vari:
> - il tool sembra molto molto interessante
>
Grazie! :)


> - mille bonus points per un progetto che fin dalla sua infanzia si propone
> completo di Makefile, di interfaccia web, di README, di Travis CI, di una
> licenza chiaramente indicata, eccetera. Bravi!
>
Deformazione da devops :D e onestamente poca voglia di stare a compilare la
webui scritta in Angular, fare il packaging per includerla negli eseguibili
Go, compilare i sorgenti Go per ogni architettura, ... ogni volta che
vogliam provare qualcosa di nuovo. Son cose che ti portan via poco tempo
inizialmente, e te ne salvano davvero tanto nel (non troppo) lungo periodo.


> - l’esempio nella tua mail mi ha inizialmente fatto pensare a più
> “connessioni” (stream, realmente) UDP su una singola SIM (da 50GB ;) e non
> capivo bene, mentre il README.md nel repo è molto più chiaro nel mostrare
> che lo use case sono uplink separati ed indipendenti
>
Hai ragionissima, mi sono espresso male a riguardo. Sì, sono uplink
indipendenti, altrimenti sì che sarebbe uno spreco di banda fine a se
stesso :D


> - prima o poi… e conoscendomi è forse più poi che prima :D… lo vorrò
> provare sul campo
>
Lo spero di cuore, fammi avere qualche impressione!


> - lo avete già messo sotto torchio? se regge bene sotto carico pesante può
> essere un tool interessante anche in situazioni professionali… sto pensando
> in luogo dei classici IPSec o altri tipi di VPN varie anche in ambienti
> aziendali, in alcuni ambiti il trade-off di banda in favore di affidabilità
> può essere desiderabile
>
Allora, sotto torchio in merito alla continuità sì, è rimasto up&running
con traffico passante anche per giorni e non ha dato problemi. Per quanto
riguarda la banda passante, con l'hardware che ho non sono riuscito a
superare i 50Mbps (che comunque non è una brutta cifra). Non ho onestamente
fatto molte prove a riguardo, proprio perché il caso d'uso più previsto è
quello di avere non troppo traffico ma che sia affidabile. Però sicuramente
ho intenzione di fare altre prove a riguardo, e se trovo margine di
ottimizzazione tanto meglio.


> - per un attimo pensavo anche a potenziali applicazioni diverse da
> WireGuard (streaming multimediali? altri tool VPN?) ma suppongo che al
> momento dipendiate strettamente dalla deduplica implicita di wireguard alla
> ricezione dei diversi stream di pacchetti?
>
Sicuramente la deduplica implicita di Wireguard aiuta, ma non penso sarebbe
troppo complesso aggiungere un header nel pacchetto con un progressivo e
gestire la deduplica internamente (penso però che le prestazioni ne
soffrirebbero).
Quello che fa il software, al di là della specializzazione che gli abbiam
dato, non è altro che questo:
- il client prende i pacchetti UDP trasmessi al suo listen address e li
manda a un indirizzo di destinazione attraverso tutte le interfacce che ha.
Quando ne riceve uno in risposta su qualunque interfaccia, lo manda
indietro all'origine.
- il server prende tutti i pacchetti UDP che riceve e li manda pari pari al
servizio upstream. Quando riceve un pacchetto in risposta, lo rimanda a
tutti gli indirizzi che gli hanno trasmesso dati negli ultimi N (default
30) secondi.
Da qui, i casi d'uso sono i più disparati. In verità, però, passare
attraverso WireGuard permette comunque di avere tutti questi casi d'uso "a
costo zero": alla fine quello che hai è un IP da una parte e un IP
dall'altra, su cui puoi fare comunicazione di ogni tipo (TCP, UDP, quel che
ti pare). In questo modo puoi usare ogni tipo di software senza alcuna
modifica. Encryption del traffico inclusa nel prezzo :D
Dato che mi parli di streaming multimediale: il motivo per cui l'ho scritto
è proprio questo. Collaboro attivamente con una radio locale della
provincia di Bergamo, ed è abbastanza frequente l'esigenza di fare delle
dirette da posti impervi (non solo a livello di connettività :D) con
necessità di avere bassa latenza e alta stabilità. Il progetto è nato per
questo caso d'uso, poi l'abbiamo reso il più generico possibile. E' già
stato usato "in battaglia" e ti assicuro che fa la differenza!

Io penso che sia uno “spreco di banda terribile” così come RAID1 (ed i suoi
> parenti stretti) sia uno “spreco di storage terribile”. Se lavorate
> nell’ambiente IT saprete anche che i server moderni consentono di fare
> mirroring dei banchi DIMM… che spreco di memoria terribile :) però in certi
> casi queste cose si usano.
>
Concordo pienamente.


> Parentesi nostalgica: per certi versi mi ricorda quando durante gli anni
> dell’università, con un mio compagno di corso, scrivemmo un tool per
> trasmettere dati (file, tendenzialmente) via UDP da un ip all’altro usando
> solo traffico a senso unico (senza nessun dato di ritorno)… sprecavamo
> tempo (inserendo attese artificiose tra un pacchetto e l’altro) e banda
> (mandando copie multiple di ogni pacchetto) nella speranza che il ricevente
> ricevesse abbastanza pacchetti sani da ricostruire per intero il file
> originale senza mai poter indicare al mittente di fare eventuali
> ritrasmissioni. Testato con successo trasferendo file di diversi mega
> dall’Italia agli USA… e per quanto non mi senta vecchio, nel 2000~2002
> circa internet non era certo quella di oggi :-)
>
Meh, non sono l'unico malato :P mi fa piacere! Noi con la radio abbiamo
avuto impianti collegati con connessioni satellitari, quindi so cosa vuol
dire bestemmiare in attesa degli ACK :P
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/gl-como/attachments/20190719/93913784/attachment.htm>