<div dir="ltr"><div>Ciao Diego, grazie mille anche a te per l'interessamento!</div><div><br></div><div><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">
Personalmente in passato ho usato fastd, che fa le stesse cose, e il routing fra nodi non direttamente connessi e' automatico:<br></blockquote><div>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).<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">
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'.<br></blockquote><div>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.<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">
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.<br></blockquote><div>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).<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">
Anche qui mi sembra fastd :) (Ognuno hai suo protocolli preferiti :) )<br></blockquote><div>Leggendo la doc mi sembrano molto simili, sì: mi riprometto di provarlo asap.<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">
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.<br></blockquote><div>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.<br></div><div></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">
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.<br></blockquote><div>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.<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">
A layer 2 saresti limitato alla rete locale. Altrimenti dovresti reinventare l'internet protocol, che c'e' gia' :)<br></blockquote><div>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 :)<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">
In questo caso basterebbe avere la possibilita' di definire dei multicast.<br></blockquote><div>Devi comunque gestire il caso in cui ti arrivano due pacchetti uguali però ,o sbaglio io?<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">
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.<br></blockquote><div>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'è.</div><div>Se invece lo usi con altri software, probabilmente potrebbe essere utile, così come potrebbe essere utile gestire internamente la deduplica ecc (vedi sopra :D). </div><div>Ma proprio per il principio di non reinventarsi la ruota, ho preferito lasciare questo sporco lavoro a WireGuard che già lo fa gran bene.<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">
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'.<br></blockquote><div>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) <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 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. <br>
<br>
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.<br></blockquote><div>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.</div><div><br></div><div>Grazie ancora, a presto! :)<br></div></div></div></div>