[gl-como] engarde

[Alessandro Rinaldi]

Ciao Diego, grazie mille anche a te per l'interessamento!

Personalmente in passato ho usato fastd, che fa le stesse cose, e il
> routing fra nodi non direttamente connessi e' automatico:
>
Bella storia! Non lo conoscevo, lo proverò sicuramente. L'unico "limite"
(che però in determinati casi d'uso può non esserlo) è che è una soluzione
Linux-only, mentre WIreGuard è cross-platform (è comodo collegarsi pure dal
cellulare).


> 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'.
>
Come termine di paragone ho solamente OpenVPN e PPTP (tramite pptpd). Non
ho fatto benchmark, ma ci sono dei miglioramenti prestazionali tangibili,
soprattutto per quanto riguarda la latenza.


> 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.
>
Vero, ma in verità ci sono anche implementazioni userspace di WireGuard
(vedi l'app per Android, non tocca il kernel e la usi anche senza root).

Anche qui mi sembra fastd :) (Ognuno hai suo protocolli preferiti :) )
>
Leggendo la doc mi sembrano molto simili, sì: mi riprometto di provarlo
asap.


> 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.
>
Beh, un esempio che nel mio caso d'uso è molto classico riguarda ShoutCast
e IceCast: i source creano una connessione TCP e, se quella va giù, la
riconnessione causa inevitabilmente un "buco" nel flusso d'audio, dato che
lato ascoltatore lo stream finisce e il client deve riconnettersi. Anche
VNC, ad esempio, va tramite TCP. Ma anche un classico download di un file
da browser.

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.
>
A me con OpenVPN (e ancor più con pptpd) capitava che in caso di
interruzione della connessione ero costretto a riavviare il servizio per
farlo riprendere. Mi ero ridotto a mettere dei check automatici che
pingassero l'endpoint e riavviassero la connessione. In questi casi, le
connessioni sottostanti solitamente si perdevano.


> A layer 2 saresti limitato alla rete locale. Altrimenti dovresti
> reinventare l'internet protocol, che c'e' gia' :)
>
A me è capitato spesso di fare VPN layer 2 con OpenVPN, in modo da poter
fare il bridge della scheda virtuale (tun0, tipicamente) con quella fisica.
Questo mi permetteva di avere due sedi remote collegate di fatto alla
stessa rete, con i client che prendevano gli indirizzi dal DHCP remoto come
se ci fosse un cavo Ethernet passante. Era questo che intendevo, poi non
son sicuro di essermi espresso al meglio :)


> In questo caso basterebbe avere la possibilita' di definire dei multicast.
>
Devi comunque gestire il caso in cui ti arrivano due pacchetti uguali però
,o sbaglio io?


> 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.
>
Niente di tutto ciò, perché WireGuard se riceve due pacchetti uguali il
secondo lo scarta senza nemmeno dare indietro una risposta di errore. Il
rischio di loop non c'è.
Se invece lo usi con altri software, probabilmente potrebbe essere utile,
così come potrebbe essere utile gestire internamente la deduplica ecc (vedi
sopra :D).
Ma proprio per il principio di non reinventarsi la ruota, ho preferito
lasciare questo sporco lavoro a WireGuard che già lo fa gran bene.


> 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'.
>
Concordo, soprattutto perché oramai come dicevo molti operatori 50GB di
traffico te li tiran dietro a meno di 10€ (è un periodo meraviglioso a
riguardo, grazie Iliad! :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.
>
Beh di tecniche ce ne sono molte, ma essendo purtroppo che non sono l'unico
a decidere spesso il requisito è di utilizzare ShoutCast, che fa tutto
tramite TCP.

Grazie ancora, a presto! :)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.linux.it/pipermail/gl-como/attachments/20190722/14654fbe/attachment.htm>