[gl-como] engarde

Sab 27 Lug 2019 16:03:49 CEST

Davvero interessante... attualmente sto usando openvpn su un raspberry
pi b+ per mantenere una vpn con un server virtuale con ip pubblico (il
rasperry è collegato ad internet attraverso un router 4G via Iliad,
dunque non si può raggiungere direttamente dall'esterno).
Riesco a vedere decentemente le 4 videocamere di videosorveglianza
collegate al raspberry da remoto su android con root (tra l'altro
attraverso port forwarding SSH sulla VPN, matrioska style...), ma
effettivamente il demone OpenVPN a volte termina ed ho dovuto creare un
loop con controlli di connessione...
Fastd e WireGuard non li conoscevo: chissà se riesco a farli girare sul
frutto di bosco (che gira con kernel serie 3) e con quali possibili
miglioramenti!

Ho i compiti per le vacanze!

Saluti.

On 7/22/19 12:41 AM, Alessandro Rinaldi wrote:
> 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! :)
> 
> 

-- 

Valerio Talora

-------------- parte successiva --------------
Un allegato non testuale è stato rimosso....
Nome:        signature.asc
Tipo:        application/pgp-signature
Dimensione:  833 bytes
Descrizione: OpenPGP digital signature
URL:         <http://lists.linux.it/pipermail/gl-como/attachments/20190727/2b8a479e/attachment.sig>