<div dir="ltr"><div dir="ltr">Ciao Luca,</div><div>innanzitutto voglio ringraziarti per aver trovato il tempo di darmi una risposta decisamente articolata. Rispondo inline:<br></div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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).<br></blockquote><div>Sostanzialmente sì, però rispetto ad altre soluzioni ha dei vantaggi tangibili.</div><div>- 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.</div><div>- Il driver di rete che si occupa di gestire il tutto è un modulo del kernel e non gira nello userspace, le prestazioni ne giovano.</div><div>- 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.<br></div><div>- 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.<br></div></div><div class="gmail_quote"><br></div><div class="gmail_quote">Potrei stare tutta sera a parlare di come mi sono innamorato di WireGuard, ma penso di aver reso l'idea :D</div><div class="gmail_quote">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.<br></div><div class="gmail_quote"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Poi un altro disclaimer: _non_ parlo Golang quindi non ho nemmeno provato a sbirciare nei sorgenti<br></blockquote><div>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!</div><div><br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Commenti vari:<br>
- il tool sembra molto molto interessante<br></blockquote><div>Grazie! :)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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!<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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<br></blockquote><div>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<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- prima o poi… e conoscendomi è forse più poi che prima :D… lo vorrò provare sul campo<br></blockquote><div>Lo spero di cuore, fammi avere qualche impressione!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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<br></blockquote><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- 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?<br></blockquote><div>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).</div><div>Quello che fa il software, al di là della specializzazione che gli abbiam dato, non è altro che questo:</div><div>- 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.<br></div><div>- 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.</div><div>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</div><div>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!<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div>Concordo pienamente.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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 :-)<br></blockquote><div>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<br></div></div></div>