Oggi sono finalmente riuscito a passare in ufficio per ritirare LaFonera+ inviata da Fon nel pacco per beta tester. Non mi dilungo nella descrizione, visto che ADM ne ha già scritto con dovizia di particolari.
Giusto due note veloci sulla connessione. Ho avuto difficoltà a connettermi con l’iBook, probabilmente a causa del fatto che le impostazioni fanno in qualche modo confusione tra reti WPA con lo stesso nome (ho altre due LaFonera). Apparentemente la connessione veniva stabilita, ma il client DHCP non riusciva a otterere un IP da LaFonera+, impedendo la navigazione e la registrazione.
Con Windows XP sono riuscito a connettermi, ho registrato il router e ho cambiato i due SSID, pubblico e privato. Con un SSID diverso, iBook non ha più avuto difficoltà a connettersi e a navigare. Non ho provato a conettermi alla porta LAN presente sul dispositivo, tramite la quale è possibile registrarsi e navigare. Nella peggiore delle ipotesi avrei potuto cambiare così i SSID.
Il led WiFi è verde se le connessioni sono solo alla rete privata, diventa giallo se c’è qualcuno connesso alla rete pubblica.
Per quanto riguarda la stabilità della connessione, nulla da segnalare; mi sembra ottima come le altre due LaFonera che utilizzo, ma d’altronde il chip è lo stesso.
Se avete in casa diversi computer dai quali ascoltate musica con iTunes, probabilmente usate già con soddisfazione la condivisione delle librerie, per accedere da diversi client allo stesso archivio musicale.
L’unico inconveniente deriva dal fatto di dover tenere acceso il computer con la libreria condivisa, ed iTunes aperto. Inoltre se avete già un server Linux acceso 24/7 non lo potete sfruttare, poiché iTunes non esiste in versione pinguinata.
Apple ha scelto come protocollo di condivisione una variante di HTTP, chiamata DAAP (Digital Audio Access Protocol). Sebbene non ne siano mai stati rilasciate le specifiche per uso aperto, esso è stato facilmente replicato tramite reverse engineering ed esistono un paio di server open source.
Ne sto provando uno, Firefly, ex mt-daapd. E’ multipiattaforma, sebbene le versioni per Win e OS/X siano ancora in beta, ed è semplicissimo da installare: su Ubuntu basta un apt-get install mt-daapd. Il server ascolta sulla porta standard 3689/TCP: è sufficiente puntare un browser all’indirizzo del server su questa porta per accedere all’interfaccia di configurazione, che è semplicissima.
In pratica basta dirgli in quale cartella sono contenuti i file che volete condividere (che avrete preventivamente copiato in una directory del server), e lanciare uno “Start Full Scan” dalla pagina principale.
Su tutti i client iTunes della rete apparirà la libreria condivisa che avete appena creato. Anche tutti i player in grado di utilizzare il protocollo DAAP avranno accesso alla musica. Adesso potete anche spegnere i computer che volete, tanto la libreria sarà sempre disponibile dal server.
Sarebbe bello poter sfuttare il meccanismo per accedere alla libreria da internet, purtroppo il meccanismo di discovery delle librerie condivise si appoggia al multicast, quindi funziona solo sulla subnet locale. Addirittura se avete un access point wireless che fa routing e non bridging, è impossibile accedere. (semplificando: i client devono avere un indirizzo IP simile a quello del server e devono risiedere sullo stesso segmento fisico della rete.)(*)
In questi giorni ho giocato ancora un po’ con OpenVPN; in particolare cercavo un modo veloce, efficiente e sicuro per connettermi alla rete di casa quando sono fuori.
Ingredienti:
Un server Debian di modestissime prestazioni che funge da gateway VPN (con poche modifiche a questa procedura va bene qualunque server).
Un client con qualunque sistema operativo(*).
Preparazione del server:
Verificare l’esistenza di /dev/net/tun, se non esistesse va creato con mkdir /dev/net && mknod /dev/net/tun c 10 200, caricato con modprobe tun, va impostato il suo caricamento all’avvio: echo "tun" >>/etc/modules, e va abilitato il forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
Installare OpenVPN sul server: apt-get update && apt-get install openvpn
Generare una chiave simmetrica con il comando: openvpn --genkey --secret nome_chiave.key
Creare il file di configurazione /etc/openvpn/server.conf con un contenuto simile a questo:
dev tap
proto tcp-server
lport 5000
ifconfig 10.0.0.1 255.255.255.0
secret /etc/openvpn/nome_chiave.key
verb 3
Ecco la spiega: dev tap: non toccare proto tcp-server: usiamo il TCP; OpenVPN va di default su UDP, che a volte è problematico nelle connessioni casalinghe, e non rutti i router sono in grado di gestirne il NATP lport 5000: in particolare usiamo la 5000/TCP (potete usare la porta che preferite) ifconfig 10.0.0.1 255.255.255.0: IP e subnet dell’adattatore virtuale: deve essere di una sottorete diversa dalla rete di casa e del client (inventatelo; non va impostato da nessuna altra parte). secret /etc/openvpn/nome_chiave.key: la chiave simmetrica verb 3: il livello di logging; 3 va bene quando funge tutto, potete alzare fino a 9 per avere più informazioni nel caso incontraste problemi.
A questo punto manca una cosa: se il vostro server è anche il default gateway della rete locale di casa, dovete creare le regole del firewall in modo da accettare le connessioni in ingresso: iptables -A INPUT -p tcp –dport 5000 -s 10.0.0.0/24 -m state –state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
Se invece vi affidate ad un firewall diverso, dovrete creare le regole su quest’ultimo ed inoltre dovrete creare una route statica che permetta al traffico in uscita dalla rete locale e destinato al tunnel VPN di essere instradato correttamente. Una cosa così: route add 10.0.0.2 255.255.255.0 192.168.1.2 dove 10.0.0.2 è l’IP che assegneremo all’interfaccia virtuale del client (vedi dopo), e 192.168.1.2 è l’IP (reale e privato) del server VPN.
Copiare sul client (con un mezzo sicuro!) la chiave generata sul server, e metterla nella cartella di configurazione di OpenVPN.
Creare il file di configurazione, la cui posizione dipende dal sistema operativo:
remote server.dnsalias.net
dev tap
proto tcp-client
rport 5000
ifconfig 10.0.0.2 255.255.255.0
route 192.168.1.0 255.255.255.0 10.0.0.1
secret nome_chiave.key
verb 3
Ecco la spiega: remote server.dnsalias.net: l’indirizzo del server; potete usare l’IP oppure il nome FQDN. Se non avete un IP statico potete utilizzare dynDNS, come in questo caso. dev tap: non toccare proto tcp-client: usiamo il TCP perché bla bla bla (vedi sopra) rport 5000: la porta su cui ascolta il server ifconfig 10.0.0.2 255.255.255.0: l’IP dell’adattatore virtuale; inventatelo, della stessa sottorete di quello del server, non va impostato da nessuna altra parte. route 192.168.1.0 255.255.255.0 10.0.0.1: la rotta statica che permette di raggiungere tutti gli host della rete remota secret nome_chiave.key: la chiave simmetrica verb 3: logging a livello 3 (vedi sopra).
Adesso sul server lanciamo: openvpn --config /etc/openvpn/server.conf e sul client il corrispondente: openvpn --config client.conf (o come avete chiamato il file).
Se tutto va a buon fine, dopo qualche istante vedrete apparire sul server: Peer Connection Initiated with xxx.yyy.zzz.kkk:nnn
Initialization Sequence Completed
e sul client: TCP connection established with zzz.ttt.vvv.rrr:5000
TCPv4_CLIENT link local: [undef]
TCPv4_CLIENT link remote: zzz.ttt.vvv.rrr:5000
Peer Connection Initiated with zzz.ttt.vvv.rrr:5000
TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
route ADD 192.168.1.0 MASK 255.255.255.0 10.0.0.1
Route addition via IPAPI succeeded
Initialization Sequence Completed
La connessione VPN tra il client e la rete remota è stabilita, avete accesso alla rete di casa come se foste fisicamente collegati ad essa.
(*)Il client per Mac OS/X è qui.
Ho trovato una buona guida per tutto il processo su Debianizzati.org. Tra l’altro viene anche spiegato come demonizzare e lanciare al boot il server OpenVPN; inoltre vengono descritti altri metodi di autenticazione oltre alla shared-key che usiamo qui.
Sono ormai quasi due giorni che Skype non funziona. La sua architettura è basata sul P2P, ma solo parzialmente. Pare che ci siano problemi al servizio directory (il Global Index), che è distribuito ma ha comunque bisogno dei server centrali per funzionare. A chi fosse interessato al funzionamento di Skype, questo è un post che ho scritto un paio d’anni fa.
Mi hanno appena consegnato un 