it-users November 2017

it-users@lists.fedoraproject.org

3 participants
2 discussions

WireGuard: Next Generation Kernel Network Tunnel
by Germano Massullo 21 Nov '17

21 Nov '17

Wireguard è un tunnel di rete di nuova generazione, ancora in fase di sviluppo, che mira a realizzare VPN: - ad altissime prestazioni [1]; - con una forte perfect forward secrecy [2] verificata formalmente [6]; - con protocollo stateless [3] [4]; - molto "silenziose" [5]; - di facile realizzazione; (note a fine messaggio) Il codice sta per essere inserito nel kernel Linux (meno di 4000 righe di codice), per il momento è disponibile attraverso modulo DKMS. Voglio mostrarvi due esempi di realizzazione di una rete in quanto sebbene la documentazione sia ben scritta, ho passato molto tempo per capire come procedere (vedere esempio 2). Ringrazio Jason A. Donenfeld e Francesco Bonanno per i suggerimenti. ======== | Esempio 1 | ======== Descrizione: esempio con due host con IP pubblico che vogliono instaurare un tunnel Su ogni host, dopo aver installato Wireguard # mkdir /etc/wireguard # cd /etc/wireguard # umask 077 si genera la chiave privata # wg genkey > privatekey si genera la chiave pubblica # wg pubkey < privatekey > publickey si crea il file di configurazione vuoto # touch wg0.conf dopodiché ad esempio, sull'host A il file wg0.conf viene modificato come segue [Interface] Address = 10.1.0.1/24 # scegliete un IP per l'host all'interno della rete VPN PrivateKey = # la prendete dal file privatekey ListenPort = 51820 [Peer] # è l'altro host con il quale volete comunicare PublicKey = # è la chiave pubblica generata sull'altro host Endpoint = indirizzo ip pubblico:51820 # è l'IP attraverso il quale è raggiungibile l'altro host AllowedIPs = 10.1.0.2/32 # è l'IP che l'host dovrà avere all'interno della VPN replicare la stessa cosa sull'altro host, con le dovute modifiche. Infine salvare i file, dopodiché # systemctl enable wg-quick(a)wg0.service # systemctl start wg-quick(a)wg0.service in tal maniera si crea automaticamente una interfaccia di rete "wg0" che ha le caratteristiche presenti nel file di configurazione. L'interfaccia è automaticamente collegata. ======== | Esempio 2 | ======== Descrizione: configurazione leggermente più complessa: - host A: dietro NAT, tipico computer casalingo; - host B: gateway/server centrale della VPN, ha una interfaccia di rete con IP pubblico ed un'altra con IP corrispondente alla sottorete 192.168.1.0/24 dove risiede anche l'host C; - host C: macchina virtuale che gira sull'host B si vuole che l'host A una volta collegato all'host B, possa comunicare anche con l'host C (e viceversa), e tutti gli altri eventuali host della VPN. Ecco i file di configurazione === Host A === # cat /etc/wireguard/wg0.conf [Interface] Address = 10.1.0.21/24 PrivateKey = *censurata* [Peer] PublicKey = *censurata* è la PublicKey dell'host B Endpoint = vpn.foo.xx:51820 # vpn.foo.xx è l'indirizzo pubblico dell'host B AllowedIPs = 10.1.0.0/24 === Host B (vpn.foo.xx) === # cat /etc/wireguard/wg0.conf [Interface] Address = 10.1.0.2/24 ListenPort = 51820 PrivateKey = *censurata* [Peer] PublicKey = *censurata* AllowedIPs = 10.1.0.21/32 [Peer] PublicKey = *censurata* AllowedIPs = 10.1.0.22/32 === Host C === # cat /etc/wireguard/wg0.conf [Interface] Address = 10.1.0.22/24 ListenPort = 51820 PrivateKey = *censurata* [Peer] PublicKey = *censurata* Endpoint = 192.168.1.1:51820 AllowedIPs = 10.1.0.0/24 Che cosa è cambiato? === Host A: === - non ha ListenPort in quanto in questo esempio si assume che per vari motivi non si abbia la possibilità di aprire porte sul NAT, quindi l'host A non è raggiungibile direttamente, ma deve instaurare lui la connessione. Pertanto ListenPort è inutile; - c'è un solo [Peer] i cui attributi sono quelli di host B. Basta un peer in quanto tutti gli altri host della VPN devono passare per forza tramite host B per raggiungere host A; - AllowedIPs indica che qualsiasi IP della sottorete 10.1.0.0/24 può comunicare con host A. === Host B: === i due peer hanno un IP con la dicitura /32 perché non devono poter cambiare IP a loro piacimento === Host C: === come host A, tuttavia ha il parametro ListenPort perché è nella stessa sottorete di host B, quindi conviene agevolare il più possibile le possibilità di comunicazione tra i due host. ======== | Note | ======== [1]: https://www.wireguard.com/performance/ [2]: 5 Protocol & Cryptography - https://www.wireguard.com/papers/wireguard.pdf [3]: https://www.wireguard.com/protocol/#connection-less-protocol [4]: 6 Timers & Stateless UX - https://www.wireguard.com/papers/wireguard.pdf [5]: 5.1 Silence is a Virtue - https://www.wireguard.com/papers/wireguard.pdf [6]: https://www.wireguard.com/papers/wireguard-formal-verification.pdf

2 3

Fedorator
by Alessio Ciregia 07 Nov '17

07 Nov '17

Ciao. Volevo sapere se esiste una politica di gestione del Fedorator. Mi spiego meglio. È possibile riceverlo in prestito, ovvero in gestione, per utilizzarlo e presentarlo ad un evento? Oppure è necessario l'accompagnamento di un ambassador? :-) Ciao. Alessio

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

it-users November 2017