[gl-como] engarde

[Diego Roversi]

On Fri, 19 Jul 2019 21:58:43 +0200
Alessandro Rinaldi <ale@alerinaldi.it> wrote:

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

Personalmente in passato ho usato fastd, che fa le stesse cose, e il routing fra nodi non direttamente connessi e' automatico:

https://projects.universe-factory.net/projects/fastd/wiki


> - Il driver di rete che si occupa di gestire il tutto è un modulo del
> kernel e non gira nello userspace, le prestazioni ne giovano.

Vero, ma solo se ti servono velocita' molto elevate. Tu hai fatto dei benchmark per confrontare le velocita' con altre soluzioni? Soprattutto perche' di solito e' l'algoritmo di crittografia che limita la velocita'.

In compenso averlo in userspace puo' avere vantaggi, puoi modificare il tuo router casalingo e aggiungere un semplice client, senza dover installare un kernel nuovo, che comunque potrebbe non funzionare.

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

Anche qui mi sembra fastd :) (Ognuno hai suo protocolli preferiti :) )


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

Ma a parte ssh, che comunque fare tunneling non e' il suo mestiere principale, quali altri tunnel usano tcp? Che io sappia e' da almeno 20 anni che si usano per lo piu' ipsec, ipip o udp per le vpn, e quindi non vedo niente di nuovo.

Inoltre le connessioni tcp non si invalidano neanche se il protocollo sotto e' stateful. Di solito si invalidano, o se sparisce l'interfaccia di rete o se scadono i timeout di ritrasmissione, che si solito sono di un paio di minuti.

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

A layer 2 saresti limitato alla rete locale. Altrimenti dovresti reinventare l'internet protocol, che c'e' gia' :)
 
> > - 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).

In questo caso basterebbe avere la possibilita' di definire dei multicast.

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

Assomiglia a quello che fanno gli switch ethernet (almeno quelli stupidi). Ma voi avete un protocollo tipo spanning tree, per evitare loop? Come l'hai spiegato fa un po' paura.

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

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

Beh gli sprechi sono accettabili se hai molte piu' risorse di quelle che ti servono. E quindi magari spendi risorse per te economiche, per avere piu' affidabilita'.

> 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

Per questo esistono le finestre di trasmissione :) A parte che se si tratta di flussi multimediali, di solito non vuoi ritrasmettere i dati. Di solito preferisci che rimanga il buco, piuttosto che aspettare 0.5 secondi. A meno di non avere un buffering elevato sul client. 

A questo punto magari vuoi usare trasmissioni con Forward Error Correction, oppure algoritmi che creano pacchetti extra, che possano funzionare come una sorta di raid5 sulla connessione. Per cui se perdi un pacchetto, i pacchetti extra aggiunti contengono abbastanza informazioni per ricostruire quello perso.

Ciao,
  Diego.

-- 
Diego Roversi <diegor@tiscali.it>