Come forse saperete avevo già fatto tempo fa una guida per creare la propria VPN su GNU/Linux.
Recentemente ho scritto un articolo per un giornalino redatto dal POuL (Politecnico Open unix Labs) in proposito. Dato che è passato parecchio tempo da quando ho iniziato a sperimentare le VPN e ora so molto di più, ho voluto riassumere il tutto in una breve guida, che introduce anche al concetto di cosa sia una VPN.

Introduzione

Un po’ per necessità, un po’ per interesse, ho scoperto e iniziato ad utilizzare OpenVPN. Inizialmente non avevo ben capito come funzionasse tutto e non riuscivo a trovare una guida semplice in italiano in rete per fare quello che avevo bisogno, quindi eccola qua! Nella scrittura della guida ho supposto che il lettore abbia un minimo di conoscenza della bash e dei comandi fondamentali per l’amministrazione di sistema GNU/Linux. Le righe precedute da “#” indicano dei comandi dati da terminale. Vi prego di notificarmi la presenza di eventuali errori presenti. Non mi assumo nessuna responsabilità sull’utilizzo proprio o improprio delle informazioni qui presentate.

VPN, Virtual Private Network, questa sconosciuta

Che cos’è una VPN? Iniziamo introducendo tramite un esempio il concetto di VPN (Virtual Private Network).
Supponiamo di avere un ufficio con dieci computer a Milano, un server a Roma e un portatile a Tokyo, tutti collegati ad Internet. I dieci computer di Milano sono dietro ad un router che ne isola l’accesso da parte dell’esterno, tramite un firewall e una NAT; mentre il server di Roma è direttamente accessibile da Internet (ha cioè quello che si definisce spesso un “IP pubblico”).
A questo punto noi siamo sul portatile a Tokyo e vogliamo accedere tramite SSH, FTP, SFTP o qualunque altro servizio a certi dati sui computer dell’ufficio di Milano che sono “dietro” al firewall+NAT. Per fare ciò (escludendo operazioni sul router dell’ufficio), la soluzione più comoda per vari motivi potrebbe essere una VPN. Tramite una VPN, infatti, possiamo fare in modo che, ovunque siamo, è come se fossimo collegati con un cavo al server di Roma. Per realizzare una VPN ci sono tanti programmi ed il più usato e probabilmente anche migliore tra tutti è OpenVPN.
In una struttura come quella descritta sopra il problema si potrebbe risolvere in questo modo: si installa sul server a Roma un servizio OpenVPN, che avrà una certa porta (TCP o UDP) aperta in ascolto per connessioni da Internet. Noi a Tokyo installeremo sul nostro portatile sempre OpenVPN e lo configureremo per collegarci e autenticarci sul server. A questo punto, sia sul server che sul portatile, OpenVPN crea delle interfacce di rete virtuali (di tipo TUN o TAP, poi parleremo delle differenze), che possiamo pensare come delle interfacce virtuali che simulano la presenza di un cavo da Tokyo al server di Roma, che collega direttamente i due computer.
Ma allora a questo punto possiamo fare lo stesso su ciascuno dei computer dell’ufficio di Milano, e avremo una rete VPN al completo: 11 client e 1 server centrale. Potrebbero esserci soluzioni più furbe come installare OpenVPN solo sul router dell’ufficio di milano e poi aggiungere regole di route particolari sul server, ma qui analizzeremo solo un caso molto semplice.
Poiché la VPN emula l’esistenza di un “cavo”, possiamo utilizzare qualunque indirizzo e protocollo su queste interfacce. Tipicamente (per scarsità di indirizzi pubblici), all’interno della VPN utilizzeremo IPv4 privati.
Potremmo stabilire che ad esempio il server abbia un indirizzo virtuale 10.0.0.1 all’interno della VPN e che il client di Tokyo sia 10.0.0.2, mentre i computer di Milano siano da 10.0.0.3 a 10.0.0.12 . Una volta configurato tutto quindi, anche se siamo a Tokyo, possiamo agilmente accedere a uno dei computer dell’ufficio utilizzandone l’indirizzo privato della VPN. Qualcuno potrebbe chiedersi se ne valga davvero la pena: non era meglio solo esporre su internet i computer dell’ufficio? Lasciando perdere il fatto che sarebbero stati più sprotetti dall’esterno, bisogna tenere conto che OpenVPN non solo crea una rete virtuale, ma ci permette di far viaggiare sopra i dati cifrati. Per questo motivo possiamo stare molto tranquilli quando siamo dentro la nostra VPN.
Ad esempio: anche se siamo a Tokyo e copiamo documenti segreti nell’ufficio di Milano, i dati trasmessi non transiteranno “in chiaro” su Internet, ma verranno cifrati da Tokyo a Roma (fino al server) e poi anche da Roma fino a Milano (al computer interessato). Dunque i dati resteranno cifrati per tutta la durata del loro trasporto e sarà quindi un po’ come ad essere dietro la protezione del router nell’ufficio. Il giorno che volessimo aprire un altro ufficio a Tokyo sappiamo che grazie a OpenVPN, collegando tutti i computer di Tokyo al server di Roma, sarà come avere i due uffici collegati direttamente insieme in una LAN (Local Area Network).
Un altro utilizzo molto interessante della VPN è per redirigere tutto il traffico in uscita dal proprio computer. Facciamo un esempio: sempre parlando del caso di prima, potremmo essere interessati a far viaggiare non solo certe informazioni cifrate, ma bensì tutto il nostro traffico di Internet cifrato mentre siamo a Tokyo. Ovviamente non dobbiamo pensarlo cifrato “per sempre”, resta cifrato dal portatile fino a Roma, poi dal server di Roma in poi i dati escono da lì su Internet in chiaro. Potremmo non fidarci della connessione che stiamo usando a Tokyo perché potrebbe esserci qualcuno che sta “intercettando” i nostri dati che passano in chiaro sulla rete, questo potrebbe essere un buon motivo per fare quanto detto sopra.
Altra possibilità per volere ciò è che chi gestisce la connessione che stiamo usando a Tokyo abbia bloccato diverse porte in uscita e non ci permetta di utilizzare alcuni programmi (ad esempio le porte di IMAP o POP3 per la posta). Oppure ancora per qualche strano motivo vogliamo fare in modo di figurare come se ci stessimo collegando dall’Italia e non dal Giappone; per esempio per vedere alcuni video sul siti italiani, che sono visibili solo quando ci colleghiamo da un indirizzo IPv4 italiano. Dopo questa lunga introduzione sul perché vogliamo una VPN, vediamo come configurarla.

La configurazione

Per prima cosa assicuriamoci di avere installato OpenVPN sul nostro server e su tutti i client che vi si dovranno collegare. Esiste un pacchetto su praticamente tutte le distribuzioni GNU/Linux. Sul server assicuriamoci inoltre di avere installato anche OpenSSL, che ci servirà per i certificati di accesso.

Sicurezza e cifratura dei dati

OpenVPN permette di cifrare i dati trasmessi e l’autenticazione in tanti modi, quello che illustreremo qua è tra i più sicuri e controllabili. Tale metodo di cifratura e autenticazione si basa sull’utilizzo di una chiave pubblica (o certificato) e privata per ogni macchina collegata alla rete, insieme a un certificato di “autorità” (tra poco capirete di cosa si tratta).
L’idea di base è questa: il server centrale detiene una CA (Certificate Autority) che “firma” tutte le chiavi private dei vari computer, per garantire che sono autorizzate ad accedere alla rete. Il processo normalmente si divide in questo modo:

  • Il server genera una chiave per la sua CA e la “autofirma”
  • Ogni client della VPN genera una chiave privata.
  • Dalla chiave privata ogni client genera una richiesta di certificato.
  • Il client spedisce la richiesta di certificato al server.
  • Il server riceve la richiesta di certificato e la “firma”, generando un certificato per il client che ne aveva fatto richiesta.
  • Il server rimanda la richiesta di certificato al client.

Per riassumere ciascun client della rete dovrà essere in possesso della propria chiave privata, certificato firmato dalla CA e certificato della CA (quest’ultimo deve essere trasferito oltre alle altre operazioni dal server a ciascun client). In via teorica, se qualcuno vi “ruba” questi tre files potrebbe essere in grado di collegarsi alla vostra VPN. Se siete così paranoici (o forse la vostra paranoia è giustificata) sarebbe meglio impostare una password alla chiave privata, vedremo poi come farlo.
Questo processo deve essere eseguto in realtà anche dal server per generare una chiave privata e certificato per se stesso. Infatti anche il server avrà una sua chiave privata e certificato. Per la creazione di tutte le chiavi per un server ed un client si richiede normalmente l’esecuzione di 10 comandi di OpenSSL poco banali (escludendo poi i comandi per trasferire i file generati da una macchina all’altra). Per semplificare le cose esiste “easy-rsa”, un insieme di script che automatizza e semplifica in modo guidato la creazione di tutte le chiavi necessarie. Molti diffidano dall’uso di easy-rsa, poichè potrebbe comportare dei problemi di sicurezza. Infatti easy-rsa, per semplificare tutto il processo crea in un solo luogo tutte le chiavi pubbliche, private e CA per poi essere trasferite ai relativi host. Se qualcuno dovesse riuscire a intercettare le nostre comunicazioni mentre inviamo a ciascun client la sua chiave privata e pubblica potrebbe riuscire a collegarsi alla nostra rete. Se invece osserviamo il procedimento eseguito sopra, anche se i trasferimenti dei vari files avvengono in chiaro e sono intercettati, un eventuale attacante non potrà farsene nulla.
Infatti se osserviamo i punti del procedimento prima esposto passano in chiaro sulla rete solo: la richiesta di certificato, il certificato del client e il certificato della CA. Un attaccante con questi dati non potrebbe utilizzarli, poichè gli manca la chiave privata del client, che neanche il server conosce. Se utilizziamo invece easy-rsa dobbiamo inviare al client anche la sua chiave privata, quindi se la connessione viene compromessa un attaccante potrebbe collegarsi alla nostra rete. Per ovviare questo problema consiglio di eseguire tutti i trasferimenti dei certificati e chiavi usando una sessione SSH “trusted” (a cui ci siamo già collegati in passato e che quindi ci fornisce un “canale” di comunicazione cifrato affidabile).

Generazione delle chiavi

Dato che abbiamo deciso di usare easy-rsa, creiamo tutte le chiavi sul server. Spostiamoci sul server, assicuriamoci di essere root e per prima cosa copiamo gli script di easy-rsa (solitamente vengono automaticamente installati con il pacchetto di OpenVPN) dentro la cartella che utilizzeremo per OpenVPN:
mkdir /etc/openvpn/easy-rsa/
cp -r /usr/share/doc/openvpn/examples/easy-rsa/2.0/ /etc/openvpn/easy-rsa/

Spostiamoci dunque nella cartella che abbiamo copiato e apriamo il file vars, che contiene delle variabili che saranno utilizzate per generare il certificato:
cd /etc/openvpn/easy-rsa/2.0/
nano -w vars

Nel file vedremo tutta una serie di variabili che saranno utilizzate per generare i vari certificati, tra queste ci sono variabili che impostano il nome dell’azienda, della città e altri dettagli che verranno messi di default sui certificati (per evitare di farvi compilare quei campi per ciascun certificato). Non sono campi necessari, se volete potete mettere NA nel caso non vogliate assegnare un valore.
Le due righe che vedrete:
CA_EXPIRE=3650
KEY_EXPIRE=3650

Indicano che i certificati e la CA generati avranno una durata massima di 3650 giorni, cioè di 10 anni. Questo significa che dopo 10 anni dalla generazione del certificato essi scadranno e non saranno più utilizzabili e dovranno essere ricreati. Se lo ritenete necessario potete modificare questi valori a vostro piacere, ricordate però di non far scadere mai la CA prima delle chiave, come numero di giorni.
La riga:
export KEY_SIZE=2048
Specifica la lunghezza dei certificati in bit. Il valore 2048 è solitamente più che appropiato, se siete paranoici in ambito di sicurezza potete però aumentarlo, anche a 4096 per esempio, questo richiederà però un po’ più tempo in seguito per il calcolo del DH e per l’autenticazione ogni volta.
Salviamo il file, chiudiamo nano e procediamo quindi a caricare tutte queste variabili definite e ripuliamo la directory dove metteremo le chiavi ( keys/ ):
source  ./vars
./clean-all

Passiamo ora a creare per prima cosa la CA e ad autofirmarla:
./build-ca
Compilate i campi necessari (in teoria dovrebbero essere tutti pre-compilati grazie al file vars compilato prima). Non riempite il campo che chiede per una password, vedremo dopo come proteggere le altre chiavi con password.
Proseguiamo ora creando una chiave privata e certificato (firmato dalla CA) per il server, come parametro del comando c’è il nome dei file che verranno generati generato:
./build-key-server VPN_Server
Quando viene chiesto se firmare il certificato rispondete ovviamente di sì.
A questo punto dobbiamo fare i certificati dei vari client che si dovranno collegare alla VPN. Possiamo scegliere se generare dei certificati protetti da password (va inserita ogni volta per poterli usare) o senza password. Solitamente la scelta dipende da quanto vi fidate dello “storage” dove terrete il certificato. Se il certificato non è protetto da password basta che ve lo copino (insieme alla CA etc..) per poter accedere alla vpn. Se è protetto da password invece serve una informazione in più per poterlo usare.
Nel caso decidiamo di generarlo senza password lanciamo:
./build-key client1
Con il parametro cambiato per ciascun client.
Se invece vogliamo un certificato protetto da password:
./build-key-pass client1
e poi inseriamo la password quando ci verrà richiesta (non quella nella compilazione dati del certificato!)
Attenzione! Assicuratevi di impostare un “Common name” diverso per ciascuno dei client, o avrete dei problemi!
Forse vi starete chiedendo perchè vengono utilizzati comandi diversi per generare alla fine sempre certificati e chiavi. Il fatto è che i certificati e chiavi del server saranno marcate in modo particolare come “certificati server”, di modo che quando i client si colleghereanno al server scambiandoci dati sapranno di comunicare con un certificato di tipo giusto.
Sarà necessario inoltre lanciare il seguente comando per generare il file per i parametri di scambio delle chiavi “Diffie-Hellman” necessario sul server che deve gestire le connessioni cifrate. Spiegare quello che fa è un po’ complicato, vi basti sapere che in questa parte devono essere calcolati dei numeri primi abbastanza grandi che serviranno come parametri per le connessioni cifrate. Il comando potrebbe impiegarci diversi minuti.
./build-dh
Un altro utile accorgimento di sicurezza è aggiungere un’altra chiave, questa volta statica (un po’ come una password ma in un file e molto lunga), da 1024 bit. Questa chiave viene utilizzata nella primissima fase di connessione con il server. È utile per prevenire attacchi “denial of service” sulla porta del server, ed autorizzare a passare al secondo passo di autenticazione solo a chi si presenta con questa chiave prima. La creeremo direttamente nella cartella dove già sono pronte tutte le altre chiavi e certificati.
cd keys/
openvpn -genkey -secret ta.key

Ora abbiamo tutte le chiavi e certificati che ci servono pronti in /etc/openvpn/easy-rsa/keys/.
A questo punto potete tenere lì tutto e per evitare confusioni è meglio creare una cartella /etc/openvpn/keys/ dove copiare le cose che servono solo al server.
mkdir -m 0700 /etc/openvpn/keys
cp dh2048.pem ta.key VPN_Server.crt VPN_Server.key ca.crt /etc/openvpn/keys/

Ovviamente i parametri di cp dipendono dai nomi che avete dato ai file del server. Se è andato tutto a buon fine ora avrete le chiavi e certificati del server in una cartella con accesso garantito in lettura, scrittura ed esecuzione solo a root.
Assicuratevi che anche la cartella delle chiavi in easy-rsa sia nella stessa condizione:
chmod -R 700 /etc/openvpn/easy-rsa/2.0/keys/
È meglio che sul server teniate tutti i certificati di tutti i client, perché il giorno che doveste decidere di revocare uno di questi certificati potrete farlo solo se ne siete in possesso. Vedremo tra poco come procedere eventualmente per la revoca.

Se non l’avete ancora fatto, questo è il momento per copiare tutte le chiavi e certificati ai vari client. Copiate i file utilizzando una connessione protetta (ad esempio tramite una sessione SSH “trusted”)! Per riassumere i file da copiare verso ogni client sono:

  • ca.crt
  • client1.crt
  • client1.key
  • ta.key

La configurazione del server OpenVPN

Avete spostato le varie chiavi sul server e copiate sui client, ora è il momento di preparare il file configurazione del server. Create un nuovo file /etc/openvpn/server.conf e iniziate a riempirlo seguendo la struttura di questo esempio:
######################################
port 1194
proto udp
dev tun
ca /etc/openvpn/keys/ca.crt
cert /etc/openvpn/keys/VPN_Server.crt
key /etc/openvpn/keys/VPN_Server.key
dh /etc/openvpn/keys/dh2048.pem
tls-auth /etc/openvpn/keys/ta.key 0
server 10.0.0.0 255.255.255.0
max-clients 10
ifconfig-pool-persist /etc/openvpn/ipp.txt
comp-lzo
keepalive 10 60
client-to-client
log-append /var/log/openvpn.log
status /var/log/openvpn-status.log
verb 4
######################################

Passeremo ora a commentare ogni riga sul suo significato, per chiarezza:

  • “port” specifica quale porta utilizzare, il conseguente parametro “proto” specifica se deve essere una connessione UDP o TCP. Giusto a scopo informativo vi ricordo che TCP è leggermente più lento di UDP poichè utilizza dei sistemi di verifica che ciascun pacchetto sia arrivato correttemente a destinazione, mentre UDP si limita a inviare il più velocemente possibile. Solitamente si consiglia sempre di usare UDP, salvo controindicazioni (che in realtà qualche volta ci sono), poichè il controllo di arrivo del pacchetto viene comunque fatto a livello software da TUN/TAP.
  • “dev TUN” specifica a OpenVPN di utilizzare una interfaccia virtuale di tipo TUNnel (virtualizza il passaggio di pacchetti IP), un’altra possibilità è di mettere TAP, che invece virtualizza tutto il protocollo Ethernet. Di solito si consiglia TUN poiché limita il numero di informazioni trasmesse, simulando un protocollo più ridotto. In alcuni casi, come ad esempio quando si vogliono mettere in bridge alcune interfacce di rete, è necessaria per forza TAP.
  • Le tre righe che cominciano con “ca”, “cert”, “key”, “dh” e “tls-auth” specificano il percorso dei relativi certificati e chiavi del server.
  • La riga “server 10.0.0.0 255.255.255.0 ” stabilisce quale rete e maschera di rete usare. In questo caso si specifica che sarà possibile usare tutti gli indirizzi tra 10.0.0.1 e 10.0.0.254. Solitamente il server si assegna in automatico il primo indirizzo libero. Eventualmente lanciate ifconfig in seguito per verificare quale indirizzio abbia preso.
  • “ max-clients 10” permette di impostare un numero massimo di client collegabili, è possibile ometterlo se non volete imporre limiti.
  • “ifconfig-pool-persist /etc/openvpn/ipp.txt” utilizza un file nella cartella di OpenVPN per memorizzare tutte le ultime assegnazioni di indirizzi e dare ai client sempre gli stessi ip (l’identificazione viene fatta in base all’hostname).
  • “comp-lzo” abilita la compressione dei dati trasmessi mediante algoritmo LZO.
  • “keepalive 10 60” invia dei messaggi di keepalive (una sorta di ping a basso livello) ogni 10 secondi ai client, se non rispondono entro 60 secondi vengono scollegati dal server.
  • “client-to-client” stabilisce che i client che si collegano alla VPN possono anche comunicare tra di loro. Senza questa opzione i client possono comunicare solo con il server ma non con gli altri collegati.
  • “log-append /var/log/openvpn.log” scrive tutti i log di OpenVPN in uno specifico file.
  • “status /var/log/openvpn-status.log” specifica quale file utilizzare per memorizzare eventuali informazioni di stato dei client collegati.
  • Infine “verb 4” è il livello di verbose standard per la stampa dei log. Solitamente per controllare eventuali problemi lo si alza fino a 7, in casi estremi fino a 9.

In teoria possiamo già provare se funziona tutto. Magari meglio commentare la riga che inizia con “log-append” per i test, così potremo vedere direttamente gli eventuali problemi senza stare ad aprire il file di log. Ricordate sempre di lanciare da root.
openvpn --config /etc/openvpn/server.conf --verb 4
Una curiosità che potrebbe interessarvi: in realtà è possibile dare tutti i parametri a openvpn, come dati nel file di configurazione, come parametri da terminale, semplicemente aggiungendo “–” davanti a ciascuno.
Se è tutto in ordine potete chiudere e rilanciare come demone (il seguente comando è valido sui sistemi debian-like):
/etc/init.d/openvpn restart
Ovviamente essendo un demone che rileva in automatico il file server.conf , ad ogni avvio la VPN partirà in automatico. Assicuratevi se sia questo ciò che volete.

La configurazione del client OpenVPN

Saltiamo ora alla configurazione del generico client. Supponiamo di aver già spostato le chiavi necessarie dal server e andiamo a creare /etc/OpenVPN/client.conf :
#################################################
client
dev tun
proto udp
remote SERVER_HOSTNAME 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client1.crt
key /etc/openvpn/client1.key
tls-auth /etc/openvpn/ta.key 1
keepalive 8 40
comp-lzo
verb 4
ns-cert-type server
#################################################

Molte opzioni si rispecchiano simili a quelle del server, vediamo le differenze:

  • “client” specifica che siamo su un client e che vogliamo accettare eventuali opzioni che ci invia il server tramite “push” e che vogliamo utilizzare autenticazione basata su TLS.
  • “dev tun” e “proto tcp” devono ovviamente rispecchiare quello che abbiamo messo sul server.
  • “remote SERVER_HOSTNAME 1194” specifica l’hostname o indirizzo IP del server a cui collegarsi e la porta.
  • “resolv-retry infinite” significa che se fallisce la risoluzione dell’hostname del server per qualche motivo, OpenVPN continua a tentare all’infinito di risolverlo. Può sembrare stupido ma vedremo poi che invece per vari motivi può tornare molto comodo.
  • “nobind” è una opzione che specifica al client di utilizzare in ascolto una porta qualunque. È un dettaglio molto specifico, possiamo tranquillamente ignorarlo o anche omettere di scriverlo nel file.
  • “persist-tun” indica a OpenVPN di non distruggere l’interfaccia virtuale quando deve riavviarsi (nonostante il nome ingannevole, questa opzione è valida sia per interfacce TUN che per interfacce TAP), mentre “persist-key” indica di non ricaricare le chiavi quando riavvia la connessione a causa di keepalive.
  • “tls-auth” ha questa volta parametro 1 e non 0 dopo il path del file, poiché viene usato dal lato client.
  • “keepalive 8 40” come sul server, invia un messaggio di ping ogni 8 secondi quando non c’è attività sull’interfaccia. Se il server non risponde entro 40 secondi viene riavviato OpenVPN.
  • “ns-cert-type server” serve a verificare che il server remoto utilizzi effettivamente un certificato marcato come “server”. Questo serve a prevenire attacchi man-in-the-middle in cui un attaccante potrebbe fingersi server usando un certificato client valido.

Ora, come per il server possiamo avviare il servizio o tutto manualmente:
openvpn --config /etc/openvpn/client.conf
Per testing si possono mandare un po’ di ping al server (che non deve essere impostato per bloccarli ovviamente…)
ping 10.0.0.1
A questo punto la vostra rete dovrebbe essere pronta, se volete lanciate direttamente il demone:
/etc/init.d/openvpn restart

Uscire su internet tramite il server della VPN

Per prima cosa andiamo sul server (da root) e abilitiamo il forwarding dei pacchetti e il mascheramento dell’indirizzo in NAT (masquerade):
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE
iptables -P FORWARD DROP
iptables -A FORWARD -s 10.0.0.0/24 -i tun0 -j ACCEPT
iptables -A FORWARD -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Con la prima riga abilitiamo la funzione di forwarding dei pacchetti IP all’interno del nostro server, quindi con la seconda riga creiamo il NAT e con le righe seguenti abilitiamo la possibilità di forwarding solo per i pacchetti che ci interessano: permetteiamo a pacchetti che arrivano dalla VPN di essere forwardati ovunque, mentre permettiamo a pacchetti provenienti da ovunque di essere diretti verso la VPN solo se fanno parte di connessioni già stabilite.

Poi spostiamoci sul client e cambiamo la sua configurazione.
Dobbiamo aggiungere la riga
redirect-gateway
che sostanzialmente dice al client di fare questo: crea una regola di routing statica di modo da restare collegato al server della VPN mediante il gateway default attuale, poi cancella il routing del gateway default e aggiungi un nuovo gateway di default.
Se stiamo usando TUN allora OpenVPN riesce a trovare da solo quale gateway di default impostare (in realtà passa tramite l’indirizzo point-to-point), se usiamo TAP invece dovremo specificare ad esempio di usare 10.0.0.1 come gateway con il parametro:
route-gateway 10.0.0.1
In realtà è spesso consigliabile sostituire il comando “redirect-gateway” con “redirect-gateway def1”,che non cancella la regola di default esistente ma ne aggiunge due nuove (una da 0.0.0.0 a 127.255.255.255 e un’altra da 128.0.0.0 a 255.255.255.255). Questo risolve alcuni problemi per le connessioni già stabilite o quando su alcune reti cambia in continuazione il gateway.

In ogni caso, dobbiamo prestare attenzione ai DNS. Se il nostro computer già utilizza dei DNS pubblici (ex: 8.8.8.8) non dobbiamo preoccuparci, mentre se ad esempio usiamo come server DNS il router interno alla nostra rete (192.168.0.1 o roba del nostro ISP), una volta cambiate le regole di routing non riusciremo più a raggiungerlo.
Uno dei tanti modi per risolvere questo problema è creare due script che cambiano i server DNS nel momento in cui avviamo la VPN. Per evitare conflitti e per comodità installiamo il programma “resolvconf” sulla nostra distribuzione e creiamo ad esempio il file /usr/bin/dnsvpnsu con questo contenuto:
#!/bin/bash
echo "nameserver 208.67.222.222" | resolvconf -a tun0

Che una volta eseguito aggiungerà come server DNS primario OpenDNS. Un altro dei server DNS mondiali più famosi, di Google, è 8.8.8.8
Creiamo poi un altro file /usr/bin/dnsvpngiu 
#!/bin/bash
resolvconf -d tun0

Che cancellerà il server DNS aggiunto dalla vpn quando la scolleghiamo.
Diamo quindi i permessi di esecuzione a questi due script:
chmod +x /usr/bin/dnsvpnsu
chmod +x /usr/bin/dnsvpngiu

E a questo punto torniamo nel nostro file di configurazione del client della vpn e aggiungiamo alla fine i comandi per lanciare questi due script rispettivamente all’avvio e all’arresto della vpn:
script-security 2
up /usr/bin/dnsvpnsu
down /usr/bin/dnsvpngiu

La prima riga è legata ad una serie di politiche di sicurezza di openvpn, se vogliamo eseguire degli script all’avvio o all’arresto dobbiamo impostare il livello di sicurezza script a 2.

Rendere le regole di iptables persistenti

Abbiamo visto che per uscire su Internet tramite la VPN abbiamo abilitato la funzionalità di forwarding e impostato alcune regole iptables. Al riavvio del sistema entrambe le cose verranno “resettate”, quindi come rendere il tutto persistente? Una soluzione stupida e semplice è utilizzare /etc/rc.local e iptables-save.

Per prima cosa salviamo la nostra attuale configurazione di regole per iptables con il comando iptables-save in un file.
iptables-save > /root/firewall_rules
In questo modo iptables effettua un dump della configurazione attuale nel file di testo /root/firewall_rules, e sarà sufficiente invocare il comando iptables-restore per reimpostare le stesse regole. Come farlo all’avvio?

Aprite il file /etc/rc.local e inserite le due righe seguenti alla fine (o prima di un eventuale riga “exit 0” già presente):
echo 1 > /proc/sys/net/ipv4/ip_forward

iptables-restore < /root/firewall_rules
Con la prima riga riabilitiamo la funzionalità di routing/forwarding dei pacchetti all’interno del kernel Linux, la seconda riga invece apre il file che abbiamo salvato prima e riapplica le regole iptables che abbiamo salvato. Questo sarà fatto ad ogni avvio del sistema come ultimo passo prima del login.

 

Kung-fu degli IP e delle porte di rete

Può capitare che siamo su un client della VPN che ha bisogno di esporre su internet un servizio, come un server web o qualcosa d’altro, però si trova dietro la NAT che abbiamo creato prima. Un’ interessante modifica alla VPN potrebbe essere quella di aggiungere sul server VPN una regola che rediriga il traffico in ingresso da una certa porta TCP/UDP ad un’altra porta TCP/UDP di un client della VPN. Per fare ciò ci basta aggiungere sul server qualcosa del tipo:
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 6001 -j DNAT --to-destination 10.0.0.2:22
iptables -A FORWARD -o tun0 -d 10.0.0.22 -p tcp --dport 22 -j ACCEPT

Che redirige il traffico in ingresso sulla porta TCP 6001 del server alla porta 22 dell’host 10.0.0.2 della VPN. Il secondo comando iptables serve invece per abilitare il forward dei pacchetti verso quella porta dell’host interno alla vpn. Su alcuni server può capitare anche di avere più indirizzi IP, perché ad esempio lo stesso server ha diverse interfacce di rete, ciascuna con un proprio IP pubblico. Potrebbe essere molto utile che un certo client della rete VPN utilizzi uno degli IP pubblici del server per se stesso, di modo da avere un IP pubblico ovunque si trovi e risultare praticamente come se fosse senza NAT.

Per fare questo dovremo aggiungere tre regole di iptables sul server:
iptables -t nat -A PREROUTING -d 123.45.6.7/32 -i eth0 -j DNAT --to-destination 10.0.0.2
iptables -t nat -A POSTROUTING -s 10.0.0.2/32 -o eth0 -j SNAT --to-source 123.45.6.7
iptables -A FORWARD -o tun0 -d 10.0.0.2 -j ACCEPT

Dove 123.45.6.7 è l’indirizzo IP che vogliamo reindirizzare e 10.0.0.2 è l’host della VPN a cui reindirizzarlo. È sottointeso che l’host della VPN su cui facciamo questa operazione deve per forza uscire su internet tramite il server della VPN.

 

Utilizzare OpenVPN dietro proxy

Può essere che qualche client della rete si trovi per qualche motivo dietro a un proxy, come accade spesso in molte aziende. Per collegarci basterà specificare due opzioni aggiuntive nel file di configurazione del client:
http-proxy PROXY_HOSTNAME 8080
http-proxy-retry

La revoca dei certificati

La vostra configurazione funziona perfettamente, però avete appena scoperto che un certificato ha la sicurezza compromessa (è stato rubato, è stato perso). Non volete assolutamente che nessuno in possesso di quel certificato riesca a fare nulla, quindi decidete di revocarlo. Ovviamente avete ancora il certificato nella vostra cartella di easy-rsa sul server, quindi entrateci:
cd /etc/openvpn/easy-rsa/2.0/
source  ./vars
./revoke-full client1

Usciranno una serie di messaggi, alla fine vedrete “error 23”, significa che la revoca è state effettuata con successo. Vedrete un nuovo file keys/crl.pem che contiene l’elenco dei certificati revocati.
Ora dovrete copiare il file nella cartella principale del server:
cp keys/crl.pem /etc/openvpn/crl.pem
E quindi dovrete aggiungere una riga nel file di configurazione del server, se non l’avevate già messa:
crl-verify /etc/openvpn/crl.pem
Se avevate già aggiunto questa riga in precedenza e volete comunque “rinfrescare” la configurazione del server, per avvertirlo di non accettare le connessioni da quel client, potete lanciare (sui sistemi debian-like):
/etc/init.d/openvpn reload
Questo comando rinfresca la configurazione, nessuno dei client si accorgerà di nulla, tranne il client revocato ovviamente.

Un modo un po’ più sicuro di generare certificati

Come già detto prima, non è proprio la cosa migliore in fatto di sicurezza quella di generare chiavi pubbliche e private insieme, perchè se nel loro transito dal server a uno dei client venissero entrambe intercettate da un attaccante, questo potrebbe sfruttarle a suo favore per collegarsi alla rete. Tutto questo ipotizzando che siano chiavi non protette da password, ma anche se lo fossero potrebbe restare un po’ di margine per tentare degli attacchi a forza bruta e la cosa non ci piace. Questo è il motivo per cui se si procede il quel modo bisogna essere assolutamente certi di trasferire le chiavi su un canale sicuro.
Vediamo allora ora come riuscire a spostare comunque in modo sicuro le chiavi pur usando easy-rsa.
Ci spostiamo su uno dei client e generiamo la sua chiave privata nella cartella di openvpn:
openssl genrsa -out client1.key 1024
Se vogliamo utilizzare chiavi di dimensioni diverse basta cambiare ovviamente l’ultimo parametro. A questo punto generiamo la “richiesta di certificato” che invieremo al server tranquillamente anche se su un canale non sicuro.
openssl req -new -key client1.key -out client1.csr
A questo punto copiamo in qualche modo il file generato client1.csr nella cartella keys/ di easy-rsa sul server e spostiamoci nella cartella principale di easy-rsa, dove ci basterà lanciare:
./sign-req client1
E dopo una conferma il server utilizzerà la CA per creare un certificato valido a partire dalla nostra richiesta. Probabilmente uscirà un errore di chmod a fine operazione perché non è presente la chiave privata (e non vogliamo che ci sia!), ma possiamo ignorarlo tranquillamente.
A questo punto andiamo nella cartella keys/ di easy-rsa, recuperiamo il certificato generato che si chiamerà ovviamente client1.crt e spostiamolo sul nostro client. A questo punto il nostro client avrà sia chiave pubblica che privata e anche se ci fosse stato un eventuale attaccante a intercettare il traffico, non potrà farsene nulla dei dati ricavati, poichè gli manca la chiave privata, che non conosce.

Annunci

Ri-salve a tutti!

Da quando sono tornato e ho ripreso l’università ho continuato a caricare sul mio canale di YouTube altri video che avevo fatto a Tokyo che vi lascio qui di seguito!

Vicino alla stazione di Harajuku:

La vista di Tokyo dal Tokyo Metropolitan Government Office:

Una ambulanza giapponese ad Akihabara:

Uno dei giri attorno alla stazione di Kichijoji:

Un tour dentro il superstore Yodobashi Akiba:

La zona dei negozi di computer ad Akihabara:

Il video fatto la sera in cui sono rimasto in internet-cafe:

Un video la Domenica mattina attraversando lo Shibuya Crossing:

Il casino dentro un’ala della stazione di Shinjuku, mentre andavo a Sengawa:

Uno dei giri attorno alla Nakano Brodway cercando “Mandarake”

Una parte del video fatto in battello sul fiume Sumida verso Odaiba:

Un’altra passeggiata ad Akihabara:

Un video fatto in treno mentre ero sulla Yamanote Line:

Alcune macchine “moddate” viste una sera ad Akihabara:


Siamo alla fine ormai..

Giovedì 28 e Venerdì 29 non ho fatto molte cose in particolare. Giovedì mi sono limitato nel pomeriggio a comprare un paio di souvenir mancanti e Venerdì praticamente lo stesso, in aggiunta la sera sono andato a bere con alcuni taiwanesi e l’italiano che partivano Sabato mattina.

Sabato, cioè oggi, è il mio ultimo giorno di vacanza a Tokyo. Domani ho il volo al mattino. Essendo l’ultimo giorno qua ho deciso dopo lunghe riflessioni (5 minuti a pensare dove potevo andare) di passare tutta la giornata ad Akihabara.

Mi sono svegliato abbastanza tardi e ho passato quasi tutta la mattinata a fare la valigia. Ovviamente avendo comprato decine di magliette inizia a straboccare e sicuramente dovrò pagare qualcosa di più per l’imbarco in aereo.
Arrivato ad Akihabara mi sono gustato un bel tempura per pranzo  e poi sono andato a fare un giro. Probabilmente ci si inizia a chiedere che giri devo ancora fare se ci sono andato quasi tutti i giorni per un mese ad Akihabara.
Beh la risposta semplice e banale è che ad Akihabara ci sono un sacco di cose che non stancano mai un otaku, c’è sempre qualcosa da vedere. In aggiunta a questo bisogna ricordare che sabato pomeriggio è un momento abbastanza speciale per essere ad Akihabara, nel senso che ci sono tantissime persone ovunque che si spostano, negozi che vendono e maid con volantini.

Inizialmente ho deciso di avventurarmi in un edificio con una scala a chiocciala all’aperto sulla strada principale. Al secondo piano c’è un negozietto nascosto che vende foto di idol giapponesi e proseguendo sopra si arriva chissà dove. Io sono salito e ho fatto un paio di foto dall’alto, dato che era una posizione ottima.
Qualche altra foto più tardi ho visto una coda immensa fuori da Animate e anche fuori da un altro negozio vicino alla stazione e mi sono avvicinato per fare foto della coda e cercare di capire che succedeva.
Sulla strada principale è poi comparsa una ragazza in cosplay di Nami (One Piece) che dava dei volantini di un posto non meglio precisato. Dal volantino non sono riuscito a capire molto ma penso che fosse tipo un bar dove si veniva serviti da persone in cosplay di One Piece.

Come potevo lasciare il Giappone, e Akihabara in particolare, senza passare un’ultima volta in un maid cafè? Sono stato quindi ancora da Maidreamin 3 e anche un altro maid cafè che si chiama “Popopure” (vicino alla strada principale). Entrando in quest’ultimo ho visto un cosplay di Final Fantasy VII (Cloud). Era abbastanza comico vedere il tizio in cosplay perfetto che veniva servito dalle maid mentre leggeva il retro della confezione di Final Fantasy per psp.. Tutti nel locale lo stavano guardando ovviamente e, quando mi sono alzato per andarmene, non ho potuto non fargli una foto (anche se magari le maid si sono incazzate che non si possono fare foto dentro al locale).

Ovviamente vi lascio immaginare cosa sia successo se già tutti lo stavano guardando quando io gli ho chiesto di fargli una foto..
Altra cosa caratteristica che ho notato in questo maid cafè: c’era un tv enorme dove andava senza audio una sorta di programma tv o qualcosa del genere e si vedeva un tizio italiano che qua è abbastanza famoso: Girolamo Panzetta. Nel video lo si vedeva arrivare nella stazione di Akihabara e poi fino a dentro il maid cafè dove veniva servito.. Pare che faccia molta audience qua lui..

Uscito dal secondo maid cafè sono andato a fare un giro e ho scoperto poi che sotto Donkijote lì vicino c’è una mappa al muro con tutti i maid cafè e le pubblicità.. Per sfizio ho fatto una foto a tutto.

Poco dopo sono andato a fare un video nella zona di informatica di Akihabara e poi da Yodobashi Akiba. Da Yodobashi Akiba ho comprato un libretto (in inglese stavolta!) che si chiama “Otaku Encyclopedia”, che avevo già sentito in giro e appena l’ho visto l’ho preso. Dopo che l’avrò letto magari scriverò due righe in proposito..

Questa sera finisco di preparare la valigia e domani si parte.. 10 ore di volo fino a Copenhagen, 4 ore di attesa e poi 2 ore fino a Linate.. speriamo di arrivare tutto intero!

Di seguito dei video che ho caricato recentemente su youtube:


Martedì e Mercoledì sono stato ad Hakone.
Hakone è una città della prefettura di Kanagawa famosa come meta turistica per le vedute del monte Fuji (che però in questo periodo è praticamente impossibile vedere..).
Martedì abbiamo fatto il solito giro con la funicolare per andare a vedere la zona dove c’è l’attività vulcanica, poi giro in barca sul lago vicino (già fatta l’anno scorso) e poi visita a un “museo” sulla riva del lago. In serata siamo andati a dormire in un hotel di Hakone in stanze tradizionali e siamo andati anche all’Onsen dopo cena. Probabilmente la cosa più interessante di tutto il viaggio è stata proprio quella di  provare a dormire in una “camera da letto” in stile tradizionale.
Io ero in camera con l’altro italiano e tre taiwanesi. In hotel giravano tutti in yukata e abbiamo fatto una cena in stile tradizionale, con tanto di karaoke finale..

Dopo cena ho provato ad andare all’Onsen, cioè le “terme” all’interno dell’hotel. Esperienza da provare sicuramente anche se è dura resistere più di 5-10 minuti dentro l’acqua super bollente e il caldo fuori. Una volta usciti però ci si sente bene. In tarda serata ci siamo trovati tutti assieme a giocare a carte e a bere qualcosa. Una bella serata!

Mercoledì mattina siamo stati in due “musei” all’aperto di Hakone: in uno c’era roba di picasso e arte moderna, l’altro invece era un giardino botanico. Appena ritornato qua sono andato a comprare un paio di souvenir e dopo mangiato sono tornato subito in camera.

Alcune foto (anche della camera da letto) le trovate nella galleria su picasa.

A breve altri video su youtube fatti i giorni passati.


La fine del viaggio continua ad avvicinarsi inesorabilmente e la voglia di tornare a casa è totalmente assente..

Domenica 24 sono stato ad Harajuku dove ho incontrato per caso un ragazzo americano che è nella mia classe nella scuola di giapponese. Abbiamo fatto un giro in un negozio che vendeva kimono e altre cose tradizionali e poi mi ha portato in uno dei famosi Yaku yen shoppu (negozio tutto a 100¥). Non è che ci sia un gran che, più che altro può essere interessante per comprare robe tipo bacchette, scatolette o accessori per la casa se si viene a stare qua per un bel po’ di tempo..
Nel pomeriggio sono passato nel negozio della Square Enix a Shinjuku. Non sono mai andato pazzo per Final Fantasy.. Lo ammetto: non ne ho mai finito nessuno ma è sulla mia lista delle cose da fare! Nel negozio si trovano accessori tipo gioielli, cd delle colonne sonore, un paio di magliette, posters e altre cose simili.
In serata ho mangiato in un sushi bar lungo la Nakano Brodway. Inizialmente pensavo fosse “Kappa sushi”, poi in realtà penso che fosse un altro molto simile. All’interno c’era il classico rullo con tantissimi tipi prelibati di sushi e una particolarità (per la quale appunto penso che fosse kappa sushi): c’è un monitor touch da cui è possibile ordinare zuppe e sushi specifici che poi una volta ordinati elettronicamente arrivano di tutta fretta a bordo di un trenino in miniatura. Una volta preso il piattino si preme un pulsante e il treno torna in cucina. Ci sono piattini di vari colori e ogni colore ha un prezzo diverso. In ordine di costo ci sono piattini da 120,180,250,320,380,480 ¥. Ovviamente a seconda della prelibatezza del sushi cambia il prezzo. Per farvi orientare comunque un piattino con due nighiri di salmone abbondante costavano 180¥. Personalmente penso che se si vuole spendere meno conviene andare al sushi bar che ho provato a Ueno (vicino alla stazione) dove si paga 126¥ fissi a piattino e ci sono comunque ottime cose. Qua diciamo che si paga di più però è anche vero che ci sono pezzi migliori e più vari.

Lunedì invece nel pomeriggio ho scoperto il Mandarake di Akihabara, una catena di negozi che vende anime/manga/action figure nuove ma soprattutto vecchie. È Abbastanza facile da trovare: usciti dalla stazione di Akihabara si prosegue verso il palazzo Crossfield, poi arrivati sulla strada principale di Akihabara basta andare sul lato sinistro e addentrarsi nella prima via dopo il palazzone nero enorme (è vicino al linux cafè).

Cercando alcuni souvenir sono entrato da Yodobashi Akiba e salendo in libreria mi  è caduto l’0cchio su una rivista “hacker japan” dove svogliando ho trovato per puro caso una schermata della competizione di sicurezza informatica su stile “Capture The Flag” organizzata per il Defcon, a cui ho partecipato con il team del politecnico di Milano.. Guardando meglio la pagina ho scoperto che nella schermata sulla rivista appariva (tra gli altri 15) anche il nome del nostro team.. Siamo famosi! Bah, forse neanche tanto, però essere in una schermata pubblicata su una rivista dall’altra parte del mondo è già qualcosa!

In serata ho mangiato in un ristorante koreano dove ho preso la tipica carne alla griglia; con la classica griglia in mezzo al tavolo dove prepararsela da sé.

Domani viaggio ad Hakone con pernottamento lì, si spera in una connessione wifi..

Ah, quasi dimenticavo… Ho pubblicato su youtube alcuni video fatti un po’ di giorni fa:


Riguardo a Venerdì non c’è molto da dire: nel pomeriggio ho fatto qualche foto ad Akihabara dove ho esplorato una zona un po’ più distante.
Sabato invece c’era l’home stay. In pratica si trattava di andare per mezza giornata a stare in una famiglia giapponese. Io sono stato mandato insieme all’altro italiano del corso da una famiglia di Omekaido, Kodaira-shi, a Ovest di Tokyo, abbastanza periferico.. Nonostante tutto devo ammettere che è stato abbastanza divertente: la famiglia in cui siamo andati era composta da marito e moglie più un figlio di 17 anni. Abbiamo passato praticamente tutot il tempo con la madre poiché il padre era al lavoro e il figlio stava un po’ per le sue.. Dopo averci portato a casa sua ci ha preparato un ottimo pranzetto e ci ha mostrato alcuni accorgimenti di buona educazione nelle case giapponesi che ignoravo totalmente… Fortunatamente parlava un po’ di inglese, altrimenti farsi capire sarebbe stata veramente una impresa.. Nel pomeriggio voleva portarci alle terme lì vicino, però una mia compagna di corso mi aveva sconsigliato di andarci giusto qualche giorno prima (dato che lei era stata), quindi ho proposto un museo della scienza lì vicino. Niente di particolare, però alla fine è stato divertente.

In serata sono andato a mangiare una pizza con i due italiani del mio corso al ristorante “Bella Napoli” a Miroshita, segnalato da Marco Togni sul suo sito.  Veramente un ottimo posto! Ve lo sconsiglio se avete intenzione di puntare al risparmio (una cena come si deve costa sui 3000¥), però se siete a Tokyo da parecchio tempo come me e vi manca la classica cena all’italiana “pizza + coca + caffè” allora questo posto fa decisamente per voi. La pizza è ottima e hanno anche tanti tipi di mozzarelle locali per la margherita. Il pizzaiolo ha studiato a Napoli e parla un po’ di italiano! Poco dopo che siamo entrati e stavamo leggendo in katakana il menu del ristorante il cuoco ci ha interrotto e ci ha detto in italiano che ci avrebbe spiegato tutto lui 😀 Pochi minuti dopo ci stava leggendo la lista delle pizze in italiano 😀 .
Ho notato che praticamente tutti i giapponesi che venivano nel locale prendevano una pizza in due che poi tagliavano a metà e mangiavano fetta per fetta su piatti separati. Ovviamente noi abbiamo preso una pizza a testa.. Per concludere abbiamo poi ordinato un caffè espresso che incredibilmente era veramente espresso! È raro riuscire a trovare qualcuno che sa cosa sia un vero caffè qua..


Che dire? Stanchezza dopo la serata in internet cafe. Nell’altro post ero di fretta quindi ora posso scrivere qualcosa di più al riguardo:

Dopo il giro serale che ho fatto sono arrivato in internet cafe attorno all’1:20. Appena entrato mi hanno chiesto quanto volevo stare e ho detto 6 ore, poi mi hanno scannerizzato il passaporto e mi hanno mostrato dov’era la saletta.
All’internet cafè “Gran Cyber Cafe Bogus” dove sono stato ci sono vari tipi di postazioni: sedia al tavolo vicino ad altra gente, divanetto e “stanzina” con “sedia”. Io ho scelto l’ultimo tipo (che va benissimo per dormire). In pratica si tratta di una zona di 2-3 m² con un “pavimento” gommoso dove è appoggiata una sorta di schienale (anche quello gommoso) che è possibile spostare. Se si sposta lo schienale e ci si stende sul pavimento si sta dentro giusto giusto per a lunghezza per distendersi. Il pc è sopra una sorta di mensola sotto la quale si possono distendere le gambe.

Non c’è soffitto in questa “area” e quindi se ci si alza in piedi si riescono a vedere negli altri box le altre persone.
Io mi sono trovato bene a dormire, l’unico problema è stato che ero in pantaloni corti e c’era ovviamente l’aria condizionata. Avrei dovuto portare qualcosina tipo un asciugamano o una coperta di qualche tipo..
Per stare a dormire una notte per 6 ore mi è costato 1200¥, circa 11€, prezzo assolutamente irrisorio, soprattutto se considerate poi che oltre alla saletta e al computer c’è anche la macchinetta dei gelati e delle bevande che è gratis: si può prendere qualunque cosa (caffè o tè caldi o freddi..).
In conclusione direi che è una buona soluzione per dormire e spendere poco. L’unico problema a mio parere è per la doccia, che non mi pare che ci sia e ovviamente serve…

Per quanto riguarda invece oggi ho fatto due video ad akihabara in cui mostro molto velocemente le zone principali:


In serata ho provato a mangiare degli spiedini di carne tipici in un posto a Ueno, veramente buoni. Forse un po’ costosi se ci si vuole riempire la pancia..

Diversi giorni fa ho fatto altri video che ho intenzione di caricare oggi/domani, poi li pubblicherò qua.