OpenVpn: installazione e configurazione in modalità bridge

Quest’articolo, per fruibilità, l’ho diviso nelle seguenti parti:

L’intera guida è orientata verso un S.O. Debian e Debian-like.
Ho impiegato tre giorni per scrivere questa guida, il motivo per cui l’ho scritta e che in internet si trovano tantissime guide sull’argomento, ma nessuna specifica che spiega per bene come integrare il servizio openvpn, configurato come bridge, con il demone dhcp.
Inoltre molte guide sono obsolete o con informazioni alle volte contraddittorie, per cui spero che possa essere utile a qualcuno. 🙂

Installiamo dei pacchetti necessari

sudo su
apt-get install openvpn bridge-utils

Creare i certificati usando il tool easy-rsa

Eseguite una copia dei file del tool easy-rsa:

mkdir /etc/openvpn/easy-rsa/
cp -R /usr/share/doc/openvpn/examples/easy-rsa/2.0/* /etc/openvpn/easy-rsa/

Settiamo il tool modificando il file vars:

nano /etc/openvpn/easy-rsa/vars

Modificare i campi:

export KEY_COUNTRY=""		# il vostro STATO
export KEY_PROVINCE=""		# la vostra PROVINCIA
export KEY_CITY=""		# la vostra città
export KEY_ORG=""		# la vostra organizzazione
export KEY_EMAIL=""		# il vostro indirizzo di posta elettronica
export KEY_SIZE=2048		# Diffie-Hellman
export KEY_NAME="server"        # X509 Subject Field

Certificati del Server

cd /etc/openvpn/easy-rsa/
source vars
./clean-all			# Cancella tutti i certificati e le chiavi presenti nella cartella /etc/openvpn/easy-rsa/keys
./build-ca			# Crea il certificato di ROOT della Certification Authority
./build-key-server server	# Crea il certificato e la chiave privata del server

Cambiate “server” con il nome che ritenete più opportuno.
All’esecuzione dell’ultimo comando vi verrà chiesto di inserire una password.
1. Inserite una password sicura e accertatevi di non perderla.
2. Alla richiesta di firmare il certificato rispondete di si.
3. Alla richiesta di eseguire il commit rispondete si.

Creiamo i parametri DIFFIE-HELLMAN necessari per il server per la connessione SSL/TSL

./build-dh

Tutti i certificati e le chiavi sono stati generati nella sottocartella “/etc/openvpn/vars/keys”
Se volete attivare il protocollo TSL dovete generare la key corrispondente:

openvpn --genkey --secret keys/ta.key

Wiki: http://it.wikipedia.org/wiki/Transport_Layer_Security

Mettiamo i file creati nella cartella del programma:

cp server.crt server.key ca.crt dh2048.pem ta.key /etc/openvpn/

Certificati del Client

sudo su
cd /etc/openvpn/vars
source vars
./build-key nome_del_pc_client

I certificati e le chiavi del client vengono sempre creati nella cartella “/etc/openvpn/easy-rsa/keys”

Il file che il client ha bisogno per effettuare la connessione con il server sono:

ca.crt				# Certificato di Root della CA
nome_del_pc_client.crt		# Certificato del client
nome_del_pc_client.key		# Chiave privata del client
ta.key				# TSL key

Copiate questi file all’interno della cartella /etc/openvpn/ del client.

Configurazione del server

tun (routing) o tap (bridging) ?

Il device TAP è una scheda di rete virtuale, mentre il dispositivo TUN è un collegamento IP virtuale da punto a punto (point-to-point).

Vantaggi e svantaggi: http://openvpn.net/index.php/open-source/faq/community-software-general/309-what-is-the-difference-between-bridging-and-routing.html

Se si utilizza bridging Ethernet (tap), è necessario utilizzare i parametri dev tap e server-bridge invece dei parametri dev tun e server.

Gli indirizzi utilizzati nella rete del server e nella rete locale del client non devono fare parte della stessa sottorete, altrimenti vi ritroverete con un loop nel routing dei pacchetti.

Es:

dev tap0
server-bridge

Altrimenti:

dev tun
server

L’istruzione server-bridge senza parametri, implica che il rilascio degli indirizzi ip per i client venga fornito dal demone dhcpd (isc-dhcp-server o dnsmasq) e non da openvpn.

Un motivo valido per cui si vuole usare dhcpd del proprio server piuttosto che openvpn e la possibilità che il proprio server abbia un dns (bind) installato e che il demone dhcp annunci i nuovi pc che si collegano alla rete al dns.

Questo aspetto è poco documentato e le informazioni al riguardo sono contraddittorie:

http://openvpn.net/index.php/open-source/faq/community-software-server/323-i-want-to-set-up-an-ethernet-bridge-on-the-1921681024-subnet-existing-dhcp.html

ATTENZIONE: La direttiva “server” con “dev tap” non deve essere usata come è suggerito dalla faq del sito openvpn, usate “server-bridge”:

  1. senza parametri se volete che sia il vostro server dhcp a rilasciare gli indirizzi
  2. con parametri opportunamente settati se volete che la gestione degli indirizzi ip sia lasciata al server openvpn.
    In questo caso c’è molta documentazione valida a riguardo.

Tuttavia è importante fare notare che il server dhcp non deve fornire ai client vpn il gateway di default della rete in cui è presente il server openvpn, pena la perdita di connessione da parte dei client remoti ad internet.

1. Creare un bridge su server

Configurazione di esempio della mia macchina (file: /etc/network/interfaces)

iface eth0 inet manual
iface eth1 inet manual
iface eth2 inet manual
iface eth3 inet manual
iface eth4 inet manual
iface wlan0 inet manual

auto br0
iface br0 inet static
	bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0
	address 172.16.0.10
	netmask 255.255.0.0
	network 172.16.0.0
	broadcast 172.16.255.255
	gateway 172.16.0.1
	# dns-* options are implemented by the resolvconf package, if installed
	dns-nameservers 172.16.0.10 172.16.0.1 8.8.8.8
	dns-search example.org

Le istruzioni:

iface br0 inet static
	bridge_ports eth0 eth1 eth2 eth3 eth4 wlan0 tap0

permettono la creazione di un bridge di rete di nome br0, con configurazione di rete statica, di cui fanno parte le periferiche fisiche:

eth0 eth1 eth2 eth3 eth4 wlan0

e la periferica virtuale

tap0

L’indirizzo di rete del bridge e le varie altre impostazioni vengono settate dalle istruzioni successive.

Una volta modificata la vostra configurazione di rete in relazione alle vostre esigenze potete riavviare il servizio di networking col comando:

sudo /etc/init.d/networking restart

2. Configurare il demone dhcpd, nel caso specifico “isc-dhcp-server”.

Questo è un cat parziale del mio file del mio file di configurazione /etc/dhcp/dhcpd.conf del mio server:

...

# Definizioni delle classi

class "local" {
	match pick-first-value (option dhcp-client-identifier, hardware);
}

class "ospiti" {
	match pick-first-value (option dhcp-client-identifier, hardware);
}

class "vpn" {	
	match if (substring(hardware, 1, 2) = 00:FF );
}

# MAC address delle macchine

subclass "ospiti" 1:00:01:AA:BB:CC:DD;
subclass "ospiti" 1:00:02:AA:BB:CC:DD;

subclass "local" 1:00:03:AA:BB:CC:DD;
subclass "local" 1:00:04:AA:BB:CC:DD;

# Definizione della subnet

subnet 172.16.0.0 netmask 255.255.0.0 {
    allow duplicates;
    default-lease-time 86400;
    max-lease-time 86400;				# 24h
    option domain-name "example.org";
    option subnet-mask 255.255.0.0;
    option broadcast-address 172.16.255.255;
    option domain-name-servers 172.16.0.10;
    option ntp-servers 172.16.0.10;

    # Local					172.16.0.50-89
    pool {
	allow members of "local";
	range 172.16.0.50 172.16.0.89;
	option routers 172.16.0.1;		# gateway della rete locale
	ddns-updates on;
    }

    # Ospiti					172.16.10.0/24
    pool {
        allow members of "ospiti";
       	range 172.16.10.1 172.16.10.254;
	default-lease-time 43200;
	max-lease-time 43200;			# 12h
	option routers 172.16.0.1;		# gateway della rete locale
	ddns-updates on;
    }

    # VPN					172.16.20.0/24
    pool {
	allow members of "vpn";
	range 172.16.20.1 172.16.20.254;
	ddns-updates on;
    }
}

Questa è la definizione del mio pool di indirizzi nel mio server.

Per la sottoclasse VPN l’opzione “option routers 172.16.0.10;” è mancante ne è presente nella definizione generale del range:

subnet 172.16.0.0 netmask 255.255.0.0 {
	...

Tanto basta per evitare che venga fornito ai client vpn un gateway che incasini l’instradamento di default dei client vpn verso internet.
Tuttavia è d’obbligo indicare l’opzione “option routers 172.16.0.10;” in tutti gli altri pool della subnet.

Per assicurarsi che tutti i client vpn finiscano nel pool corretto bisogna indicare come regola “allow members of “vpn”;” nel pool e creare una classe con questa regola qui:

class "vpn" {
        match if (substring(hardware, 1, 2) = 00:FF );
}

La regola funziona perché ogni client che si collega tramite openvpn avrà sempre come MAC address iniziale i valori: 00:FF
Tutti gli altri pool definiti nella subnet hanno regole differenti che non coincidono con la regola della classe vpn.

E’ importante accertarsi che nessuno dei client vpn possa finire in un pool di indirizzi in cui è definita la regola “option routers”, sopratutto se in quest’ultima regola è definito il gateway della rete del server vpn.

E’ possibile instradare tutto il traffico del client vpn verso la rete del server, ma in quel caso bisogna specificare come indirizzo ip quello del server vpn. Es:

option routers 172.16.0.10

Gli altri valori del MAC Address dei client vpn varieranno casualmente ad ogni connessione a meno che non si specificano esplicitamente tramite l’istruzione:

lladdr 00:ff:00:00:00:0d

per le macchine linux e nelle proprietà del device tap0 per le macchine windows.
Nelle macchine windows l’istruzione “lladdr 00:ff:00:00:00:0d” non è riconosciuta.

3. Configurazione del servizio OpenVpn

Nella cartella di configurazione del demone openvpn non sono presenti i file di configurazione per cui bisogna metterceli a mano:

cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/
gzip -d /etc/openvpn/server.conf.gz
rm /etc/openvpn/server.conf.gz

Una configurazione di esempio del file del server.conf è la seguente:

# Quale indirizzo ip dovrebbe rimanere in ascolto OpenVPN?
local 172.16.0.10		# Indirizzo ip del bridge br0

port 1194			# Porta
proto udp			# Protocollo

dev tap0
server-bridge

ca		ca.crt		# Certificato di Root della CA
cert		server.crt	# Certificato del Server
key		server.key	# Chiave privata del Server
dh		dh2048.pem	# Diffie Hellman parameters
tls-auth	ta.key 0	# This file is secret (0 = server)

comp-lzo			# algoritmo di compressione per la connessione
client-to-client
keepalive 10 120

user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log

daemon
verb 3
chroot jail

Anche qui ho omesso i commenti presenti nel file di configurazione di esempio.

Configurazione di un client

Il client ha anche lui bisogno del suo file di configurazione per cui, se non ne avete uno già pronto potete copiare quello di default:

cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/

Esempio di configurazione per un client linux.
E’ stata omessa la documentazione presente nel file di configurazione di esempio.

script-security 2

client
dev tap
proto tcp

remote vpn.example.org 1194	# Indirizzo del vostro server vpn

lladdr 00:ff:00:00:00:0d	# Indirizzo MAC del client

resolv-retry infinite
nobind
user nobody
group nogroup
persist-key
persist-tun

ca ca.crt			# Certificato radice della CA
cert client.crt			# certificato del client
key client.key			# chiave privata del client

ns-cert-type server

tls-auth ta.key 1		# File condiviso con il server (1 = client)
comp-lzo
verb 3

chroot

Per maggiorni informazioni in merito al chroot si può controllare questa pagina della wiki http://it.wikipedia.org/wiki/Chroot

mkdir /etc/openvpn/jail
nano /etc/openvpn/server.conf

Alla fine del file aggiungere l’istruzione:

chroot jail

e salvare.

chroot jail e syslog

Il problema è semplice, alla rotazione giornaliera dei log del sistema il servizio rsyslog viene riavviato dalla macchina facendo perdere la connessione alla socket “/dev/log” da parte del servizio openvpn.
Infatti la socket AF_UNIX “/dev/log” viene terminata e ricreata al riavvio del servizio rsyslog.
Il servizio openvnp, essendo bloccato dentro la cartella “/etc/openvpn/jail” non può più accedere alla socket del demone rsyslog che si torva fuori dalla cartella “jail” (ovvero “/dev/log”).

Per ovviare al problema bisogna creare la cartella dev dentro jail:

mkdir /etc/openvpn/jail/dev

e modificare la configurazione del demone rsyslog creando un nuovo file dentro la cartella “/etc/rsyslog.d” e aggiungere lì la configurazione del nuovo socket per il demone openvpn. Ovvero:

nano /etc/rsyslog.d/openvpn.conf

E aggiungere la seguente istruzione:

$AddUnixListenSocket /etc/openvpn/jail/dev/log

e salvare e riavviare il servizio.

service rsyslog restart

Streaming Evento Ferus Trapani (25-01-2013)

A 30 anni dall’assassinio del magistrato Giangiacomo Ciaccio Montalto, il 25 Gennaio 2013 alle ore 17:00 il Palazzo di Giustizia di Trapani apre le porte alla cittadinanza per affidare un messaggio di speranza alla voce ed al sentire della cultura, dell’arte e dell’impegno civile, nella convinzione che il bello, il giusto ed il buono della nostra terra sconfiggeranno la violenza, la sopraffazione e la devianza criminale che hanno insanguinato ed avvilito la Sicilia dei nostri anni. L’evento Ferus ha già riscosso una grande partecipazione popolare al Palazzo di Giustizia di Catania lo scorso 23 maggio, per il ventennale dalle stragi di Capaci e di Via D’Amelio, trasformando il tribunale in luogo ideale per l’espressione.

In collaborazione con:

Evento Ferus
Associazione Culturale 50mtAssociazione Nazionale Magistrati

TCP Socket (af_inet)(IPv4/IPv6)(with ssl) – c language

This program is an example of programming a TCP socket in C language, using the well-known client-server programming model.
The server side is multi-threaded, but the thread is optional since the developer/designer is still responsible for deciding if he/she needs it.

The library “commv6.c” develops all the functions to create, bind, listen, and remove a socket AF_INET, and the functions to send and receive messages (using the methods read and write). It supports: IPv4/IPv6 and SSL (see commSSL.c).
The structure of a message is defined in the file “msg.h”.

Code tested under debian-like and arch linux platform (thanks to nignux).


Questo programma è un esempio di programmazione di un socket TCP in linguaggio C, utilizzando il ben noto paradigma di programmazione client-server.
Il lato server è multi-threaded, ma è del tutto opzionale, e sarà responsabilità dello sviluppatore decidere se ne ha bisogno.

La libreria “commv6.c” sviluppa tutte le funzioni per creare, pubblicare, rimanere in ascolto e rimuovere una  socket af_inet, e le funzioni per inviare e ricevere messaggi (usando i metodi read e write). Il codice supporta socket ipv4/ipv6 e SSL (commSSL.c)
La struttura di un messaggio è definita nel file “msg.h”.

Codice testato sotto piattaforma debian-like e arch linux (ringraziamenti a nignux).


Be careful when you do a read(/write) on a socket: the machine at the other end of the socket is of your own platform (x86/x64)?
Fate attenzione quando fate una read(/write) su una socket: la macchina dall’altro capo della socket è della vostra stessa piattaforma (x86/x64)?
x86 x64
sizeof(char)  1  1
sizeof(short)  2  2
sizeof(float)  4  4
sizeof(int)  4  4
sizeof(unsigned int)  4  4
sizeof(long)  4  8
sizeof(double)  8  8
sizeof(long unsigned int)  4  8
sizeof(long double) 12 16
sizeof(long int)  4  8

x64

Linux 3.0.0-16-generic #28-Ubuntu SMP Fri Jan 27 17:44:39 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

x32

Linux 2.6.18-6-k7 #1 SMP Thu Aug 20 22:36:26 UTC 2009 i686 GNU/Linux

Si consiglia di utilizzare:

sys/types.h

dove vengono dichiarati i tipi:

int8_t
u_int8_t
int16_t
u_int16_t
int32_t
u_int32_t
int64_t
u_int64_t

Tiscali Netbox G/N (Alcatel Thomson TG784)

If you are not paying for it, you’re not the customer; you’re the product being sold. —
Andrew Lewis MetaFilter, 26 Agosto 2010
Richard Stallman, hackmeeting Firenze, 26 Giugno 2011

Alcatel Thomson tg784g (Tiscali Netbox g)La politica di ogni provider adsl che si rispetti è di lasciare fuori i propri clienti dall’amministrazione del router. Va da se che questo modo di fare cozza, completamente, con i miei ideali. Ovvero, io ho acquistato il modem, dunque, penso di avere il diritto di gestirlo come amministratore.

Parliamo di cose serie, se siete tra i fortunati possessori del router Alcatel Thomson tg784g/n che viene dato (comodato d’uso o venduto) dalla Tiscali, per chi stipula un contratto voce, allora avete un serio problema di sicurezza sulla vostra rete locale.

Questi pazzi hanno lasciato l’accesso telnet attivo e aperto verso internet, inoltre, le credenziali di accesso come amministratore sono note. In termini pratici un lamer potrebbe entrare nel vostro router, copiarne la configurazione e/o modificarla a suo vantaggio. Ovvero, chiunque può amministrare il vostro router senza che voi ve ne accorgete, esponendo la vostra rete locale ad attacchi di tipo man in the middle o al furto delle vostre credenziali di accesso alla rete adsl e voip.

Bene, mettiamoci ai ripari. Il mio suggerimento è di creare un nuovo account sul router con i privilegi di amministratore e di rimuovere l’account di default.

Consiglio: prima di continuare accedete all’interfaccia amministrativa web del vostro router, con le credenziali di accesso di amministratore, e salvatene la configurazione (File: user.ini)

Cambiate l’indirizzo ip del vostro pc con 192.168.1.34 e collegatevi all’interfaccia telnet del vostro router:

telnet 192.168.1.254 8081

Attenzione, da rete locale il router risponderà all’interfaccia telnet solo se il pc che chiede l’accesso ha l’indirizzo 192.168.1.34. Il motivo è una regola impostata nel firewall del router (estratto da user.ini):

Thomson TG 784 H:

rule add chain=sink_system_service index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Thomson TG 784 N:

rule add chain=sink_fire index=1 srcintf=lan srcip=!192.168.1.34 serv=telnet log=disabled state=enabled action=deny

Loggatevi con le credenziali di accesso di root e date i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user add name = <nome> password = <password> role = root
user list
saveall
exit

sostituite:

  • <nome> col nome del vostro nuovo utente amministratore (consiglio: evitate nomi come  admin, administrator, root e simili) e
  • <password> con la password da voi preferita (consiglio: metteteci una password forte).

Attenzione, alcune volte il router si pianta durante la procedura di saveall. Non allarmatevi se, per più di un minuto, la console telnet non risponde, riavviate il modem usando il pulsante di accensione. Generalmente il router riesce a salvare le impostazioni anche quando si pianta.
Loggatevi nuovamente con le credenziali del nuovo utente che avete creato ed eseguite i seguenti comandi:

env set var=SESSIONTIMEOUT value=0
user list
user delete name = <nome>

Sostituite <nome> con il nome dell’utente root standard del router.
Se cancellate anche l’utente della tiscali avrete eliminato la possibilità da parte dell’assistenza remota di entrare nel vostro router: a voi la scelta.

E, giacché ci siamo, abilitiamo il client ntp del router:

sntp add name=it.pool.ntp.org version=3
sntp config poll=60 pollpresync=5
sntp config state=enabled

inoltre, dato che la tiscali censura i dns, aggiungiamone due statici con priorità superiore a i dns della tiscali stessa:

dns server route add dns=208.67.222.222 metric=1 intf=Internet
dns server route add dns=208.67.220.220 metric=1 intf=Internet
dns server route list

I dns che vedete nell’esempio precedente sono di opendns, se non vi piacciono cambiateli con quelli che più preferite. Nel mio caso ho inserito come dns il server di casa mia considerato che ho bind 🙂
Ebbene si! In Italia esiste la censura… (lol) provate a collegarvi al sito www[dot]thepiratebay[dot]org oppure www[dot]btjunkie[dot]org, prima e dopo aver cambiato i dns.
T1scal1 censura, al momento, solo i dns, Alice e altri provider eseguono una censura a livello di pacchetto, quindi, anche cambiando i dns non vi collegherete, comunque, ai siti internet censurati. (ricordate tor è vostro amico)

Aggiornamento del 25/07. Sono spiacente di informare la censura di t1scal1 si è allineata agli altri provider adsl, censurando a livello di pacchetto e non più di solo dns…

Modifichiamo la regola del firewall per il servizio telnet del router, al fine di rendere accessibile telnet da qualsiasi pc della rete locale.
Creiamo una nuova espressione che identificherà il range degli indirizzi della nostra lan:

expr add name=personal type=ip addr=192.168.1.0/24 mask=0

Poi modifichiamo la regola (che vi avevo mostrato prima) per il telnet:

regola da usare per il modello Thomson TG 784 H:

firewall rule modify chain=sink_system_service index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

regola da usare per il modello Thomson TG 784 N:

firewall rule modify chain=sink_fire index=1 srcintf=lan srcip=!personal serv=telnet log=disabled state=enabled action=deny

Il comando “srcintf=lan” (letteralmente source interface expression) indica che la regola è valida solo per la rete locale lan. Se volete creare una regola per le connessioni internet dovete usare la parola “wan“.

Non dimenticatevi di salvare tutto prima di uscire:

saveall
exit

Per maggiori informazioni sulla command line interface di questo router eseguite la ricerca “thomson tg784 cli” su g00gle e scaricate il pdf.

Ad ogni modo, eseguendo la procedura di reset fisico del router, sarà possibile riportare il router alle impostazioni standard della adsl Tiscali.

Abilitazione accesso FTP e HTTP da remoto
(Aggiornamento del 10-10-2011)

Non ho mai usato l’ftp del router… tuttavia sembra che a qualcuno faccia comodo 🙂

service system ifadd name=FTP group=wan
saveall

Regola testata e NON funzionante o almeno sembra che non basti per fare funzionare l’ftp da remoto.

Analogamente per l’interfaccia web di amministrazione del modem..
(sconsiglio caldamente di abilitarla, ma a volte si sa può servire…)

service system ifadd name=HTTP group=wan
saveall

[Regola testata e funzionante]

Rimozione accesso Telnet da remoto (FTP e HTTP)

Una volta per tutte, togliamo questa falla alla sicurezza del router…
Attenzione, potrete sempre accedere al router tramite telnet dalla vostra rete locale di casa vostra, ma non più da internet.

service system ifdelete name=TELNET group=wan
saveall

Regola per rimuovere l’accesso FTP da remoto ..

service system ifdelete name=FTP group=wan
saveall

Regola per rimuovere l’accesso remoto all’interfaccia web di amministrazione del modem.. (l’accesso remoto non è attivo come impostazione di default del modem, almeno di vostre modifiche)

service system ifdelete name=HTTP group=wan
saveall

Insomma, avrete capito che service system ifadd aggiunge e service system ifdelete rimuove, mentre se volte avere una lista dei servizi del router…

service system list

Purtroppo,  quella lista non ci dice nulla su quale lato (internet o lan) del router sono attivi, bisogna andare a spulciarsi il file user.ini.

Aprire le porte sul router…

Aprire le porte su questo router non è esattamente immediato.
E’ facile notare che se si utilizza una regola per servizio già presente sul router la porta viene aperta correttamente.
Potete constatare voi stessi che se si assegna un ad un pc il servizio ssh o qualsiasi altro servizio preimpostato sul router la porta risulta essere effettivamente raggiungibile dall’esterno. Ben altra cosa accade con le regole definite manualmente dall’utente.

Ho visto che ci sono alcuni navigatori che suggeriscono di disabilitare l’intrusion detection. Non è il caso. Vi faccio una metafora: è come se il vostro elettricista di fiducia per fare passare il cavo dell’antenna dal muro anziché fare un buco col trapano, ve l’ho butta giù con il martello pneumatico. Beh sicuramente il filo ci passa, ma non era esattamente quello che volevamo no?

La soluzione esiste:

  • Fissate in modo statico gli indirizzi ip dei pc di casa vostra su cui volete assegnare dei servizi (Home > Home Network > Devices > …)
  • Create tutte le regole che vi servono (Home > Toolbox > Game & Application Sharing > New Game or Application).
  • Assegnate le regole alle vostre macchine
  • Salvate il vostro file user.ini (Home > Thomson Gateway > Configuration > Backup & Restore) sul desktop e apritelo con wordpad/gedit
  • Cercate la sezione “[ service.ini ]” Es:
[ service.ini ]
add name="AIM Talk" mode=client
...
add name=test
add name=VNC mode=server
add name="Xbox Live" mode=server
...
...

Per sinteticità ho tagliato le regole presenti nel router.
La regola che ho creato per queste esempio si chiama test. La regola in questione non ha il parametro mode, per il modem è equivalente a scrivere mode=client. Risultato porta chiusa dall’esterno. Aggiungete mode=server ad ogni vostra regola creata:

add name=test mode=server

Salvate il file, ridatelo in pasto al modem e avete finito. Solo un ultimo consiglio: NON usate la porta 8080 per le vostre regole, pena la perdita dell’accesso all’interfaccia web del router.
(anche se disabilitato, sulla 8080 del router è presente il servizio di parental control)
In generale se volete avere la lista di quali porte NON si devono usare sul router perché sono in uso dallo stesso modem. Dall’interfaccia telnet date:

service system list

Aprire le porte sul router tramite telnet

Un altro metodo, che vi evita di modificare a mano il file user.ini è il seguente:

Si crea un nuovo “nome di regola”. Es:

service host add name=my_torrent mode=server

Se per caso nel vostro nome di regola sono presenti degli spazi, allora:

service host add name="my torrent" mode=server

bisogna inserire i doppi apici.
Successivamente si devono creare le vere regole per questo nuovo “nome di regola”. Es:

per il solo protocollo TCP:

service host rule add name=my_torrent protocol=tcp portrange=9020-9020

per il solo protocollo UDP:

service host rule add name=my_torrent protocol=udp portrange=9020-9020

per entrambi i protocolli:

service host rule add name=my_torrent protocol=any portrange=9020-9020

Qui, abbiamo aperto la porta 9020 del router. Si possono aggiungere molte regole ad ogni nome di regola, anche per più porte e protocolli diversi, tuttavia ogni nome di regola può essere assegnato ad un solo pc alla volta. Ad ogni modo è da evitare categoricamente la creazione di nomi di regole che aprono le stesse porte con lo stesso protocollo.
(Qui serve solo del buon senso e un po di conoscenza del concetto di NAT)

Infine bisogna assegnare la regola al pc:

service host assign name=my_torrent host=192.168.1.69 log=disabled

Modificate l’indirizzo 192.168.1.69 con quello del vostro pc e ricordatevi di settare il suo indirizzo come statico nell’interfaccia del router. (Home > Home Network > Devices > …)

Per rimuovere l’assegnamento:

service host disable name=my_torrent

Altro esempio. Assegnamo l’SSH ad un pc di casa, (la regola è già esistente sul router):

service host assign name="Secure Shell Server (SSH)" host=192.168.1.66 log=enabled

Rimozione dell’assegnamento:

service host disable name="Secure Shell Server (SSH)"

E adesso, divertiamoci con un po’ di hacking…

Attenzione: Questa procedura è valida solo per il modello TG 784 H.
(Per chi non conosce le credenziali di accesso di default del router o, semplicemente, vuole sbirciare dentro il firmware di questo apparecchio.)
Prendetevi una penna usb, la più piccola che avete va bene. Se avete dei dati sul supporto usb che volete conservare salvateli perché con questa procedura la penna usb verrà formattata.

Procedura valida solo per il vecchio modello Thomson TG 784; il nuovo modello (TG784n) non riconosce il filesystem del pennino.

  • Scaricate il file: tg787-sysroot.sqsh.7z (filesystem che contiene un ln -s alla root)
  • Aprite una shell sotto linux (una distro live di ubuntu può fare al caso vostro se  non avete linux installato sul vostro pc)
  • se non l’avete già fatto, inserite la penna usb nel vostro pc ed eseguite il comando
  • $ mount, nella vostra shell e identificate qual’è il nome della vostra penna usb (nel mio caso /dev/sdb), ed eseguite il comando:
  • $ sudo dd if=/dev/zero of=/dev/sdb, che cancellerà ogni dato presente nella penna (più è grande il supporto più questa operazione sarà lunga),
  • andate nella path dove avete scaricato il file e una volta scompattato eseguite il comando:
  • $ sudo dd if=sysroot.sqsh of=/dev/sdb,
  • a operazione terminata staccate la penna usb e inseritela nella porta usb del router
  • Controllate, collegandovi all’interfaccia web del thomson, che in toolbox => content sharing sia attivo server enabled (upnp Av Media Server) (generalmente è già tutto attivato di default).
  • All’indirizzo \\192.168.1.253 o nelle condivisioni di rete (winzoz) troverete un pc chiamato thomson, al cui interno c’è condiviso il firmware del vostro router.
  • Aprite il file mlpuser.def che si trova in /sys/archive/xxxx/active/, per leggere le credenziali di default del vostro router.

thomson tg784g

Qualcuno ha detto TTL?

Thomson TG784g TTL JTAG

Sembra però che bisogna anche saldare due ponticelli dietro la board del modem per fare funzionare la ttl.
A questo link c’è spiegata la procedura per il modello tg782 (estremamente simile al tg784)
Appena ho un po di tempo farò alcune prove in merito.
Sarebbe molto carino riuscire a parlare direttamente con busybox piuttosto che con la command line interface (CLI) sviluppata da thomson.

Cambiare antenna

Procedura valida solo per il modello TG 784 H, sul quale NON è presente il wifi di tipo N.

Qui si può vedere il cavo “Mini PCI U.FL to RP-SMA Pigtail”

Link utili:

Installazione “Palermo a Venezia” di Alessandro Librio

Un giorno di traffico per Venezia.

Alessandro LibrioSegnalo l’evento speciale “Palermo a Venezia” dell’artista Alessandro Librio che avrà luogo il 4 Giugno, giornata di apertura della 54° edizione della Biennale di Venezia.

L’installazione si terrà al n. 63 di Piazza San Marco nel cortile del Palazzo Reale, sarà inoltre possibile seguire l’evento in diretta sul sito internet dello stesso artista: http://www.alessandrolibrio.com/node/173.

L’obbiettivo che l’installazione si propone è l’unione del paesaggio sonoro della città di Palermo con quello di Venezia, infatti per ventiquattro ore i suoni/rumori del traffico palermitano verranno acquisiti e riprodotti in tempo reale a Venezia.

Per informazioni più approfondite rimando all’intervista del sito SiciliaInformazioni:
http://www.siciliainformazioni.com/giornale/cultura/125290/suoni-palermo-invadono-venezia-linstallazione-librio-apre-biennale-darte.htm

Threads pool (posix) – c language (ver 2)

Example of generalized thread pool in C language with signal handling.

rev 2: Completely revised the code of the library.
Now there is a queue of jobs, a thread is awakened when a new job is available, following the classic mechanism of producer / consumer.

You can set: the thread pool size, its signal mask and the size of the job queue, calling the poolInit function that returns a new pool. If the signal mask is null then the signal mask shall be inherited from the creating thread.

The function poolDispatcher gets three arguments the pointer to the pool; a void pointer to function (start_routine), with a single argument void arg. (very similar to pthread_create). The poolDispather when executed creates a new job that is inserted into the queue of jobs.

If you send too many jobs to the pool and the queue fills up, the poolDispatcher reject the new job and returns the error code “-5” (to avoid DOS attacks).
The function poolDestroy, puts the pool in termination state, (the pool is no longer available to run new job), it waits for all active and pending jobs to finish; execute the join of the threads; free resources and exit.
doxygen docomuntation and source code (license GPLv2)

 

Esempio di pool di thread in linguaggio C generalizzato con gestione dei segnali.

E’ possibile passare a questa libreria un proprio puntatore a funzione.
La funzione verrà eseguita dal primo thread disponibile del pool di threads.

E’ facile notare come la funzione addjob esegue, nel caso in cui tutti i threads siano impegnati, attesa attiva.
La soluzione è presto detta, implementare una lista di jobs, oppure (per chi non ha voglia) aumentare opportunamente la dimensione del pool threads.

[update]
Rivisto completamente il codice della libreria.
Adesso esiste una lista di job; un thread del pool viene risvegliato quando un nuovo job è disponibile, seguendo il classico meccanismo di produttore/consumatore.

La dimensione massima della coda dei job è settabile in fase di creazione del pool.
Se si inviano troppi job al pool e la coda si riempie, la poolDispatcher rifiuterà il nuovo job ritornando il codice di errore “-5” (evitiamo attacchi di DOS).

La funzione poolDestroy, mette il pool in fase di terminazione, (ovvero il pool non è più disponibile ad eseguire nuovi job), aspetta che tutti i job attivi e pendenti terminino; esegue la join dei threads; libera le risorse ed esce.
[update-end]

Una volta terminato il job, il thread viene reso automaticamente disponibile per un nuovo job.
La dimensione del pool e la maschera dei segnali per i threads sono passate in fase di inizializzazione del pool stesso.

E’ possibile creare infiniti pool di threads, dato che ogni struttura dati viene creata dinamicamente in fase di inizializzazione del pool stesso. La maschera dei segnali è invece opzionale.

Per commenti e info più dettagliate sul codice: documentazione html (doxygen).

E per scaricare il codice sorgente: codice sorgente (in licenza gpl v2).

LaCie 2Big Network: supporto nfs

No, I will not fix your pc.
[Detto anonimo e largamente condiviso]

Aggiornamento / Update (05/02/2012):

Per il servizio nfsd in kernelspace, guardate i commenti di questo stesso articolo.
Suggerisco di usare il servizio nfsd in kernelspace, dato che supporta il lock dei file.

For nfsd kernel space, look at the comments of this article.
I recommend to use nfs kernel space since it supports file locking.

All thanks go to Bert.


Avevo tentato precedentemente di installare il supporto nfs sul mio vecchio (v1) nas 2Big Network della LaCie ma avevo desistito per la mancanza del modulo kernel nfsd, che permette di abilitare nfs server in kernelspace.

Di recente, dopo una richiesta di aiuto da parte di un navigatore, ho riaffrontato il problema trovando una soluzione: nsf in spazio utente. Ok storco il naso anche io per l’enormità di quello che ho appena detto..
Infatti ci sono grossi handicap per nfs userspace: lo sviluppo del codice è stato completamente abbandonato (l’ultima versione è la 0.9.22 e risale al 05/01/2009), ma il problema più grave che non vi è alcun supporto per il lock dei file.

Per installare il supporto per nfs v3 sul nas c’è bisogno dei demoni unfsd e portmap, il primo è nfs stesso il secondo è un servizio ONC RPC, in esecuzione su una macchina collegata in rete, che fornisce altri servizi ONC RPC (Remote Procedure Call). (Chi è abituato a programmare sa di che sto parlando)
Per farla breve il pacchetto unfs3 dipende dal pacchetto portmap. Ai fini pratici significa che è richiesto  l’installazione anche del servizio portmap per avere nfs funzionante.
Significa anche che ho dovuto scrivere due script per initng per avviare/arrestare correttamente i due demoni.

File portmap.i:

# NAME: portmap
# DESCRIPTION: DARPA port to RPC program number mapper
# WWW: 

# exec daemon = /sbin/portmap -d ${PORTMAP_OPTS};
daemon portmap {
	need = bootmisc virtual/net;
	provide = virtual/portmap;
	pid_file = /var/run/portmap.pid;
	forks;
	env PORTMAP_OPTS=;
	env_file = /etc/portmap.conf;
	exec daemon = /sbin/portmap;
}

File unfs3.i:

# NAME: unfs3
# DESCRIPTION: starts user-space NFSv3 server.
#	       UNFS3 is a user-space implementation of the NFSv3 server specification.
#	       It provides a daemon for the MOUNT and NFS protocols,
#	       which are used by NFS clients for accessing files on the server.
#	       Unlike nfs-user-server, unfs3 is capable of handling files larger than 2GB,
#              but there is currently no support for file locking.
# WWW:

daemon unfs3 {
	need = initial virtual/portmap virtual/net;
	env PID_FILE = /var/run/unfsd.pid;
	env_file = /etc/unfs3.conf;
	pid_file = ${PID_FILE};
	require_network;
	forks;
	exec daemon = /usr/sbin/unfsd -i ${PID_FILE} $DAEMON_OPTS;
	daemon_stops_badly;
}

Installazione di nfs3 server

Come premessa generale si presuppone che:

  • abbiate già effettuato l’hack del vostro nas (vedi articolo),
  • installato ssh e soprattutto con esso le librerie tcp-wrappers,
  • avete un account di root sul vostro nas (tutte operazioni documentate nell’articolo già citato)
  • e sopratutto, una buona padronanza della bash e dei sistemi linux.

Per installare nfs server dovete scaricare questi due archivi:

I pacchetti sono stati scaricati della distro debian lenny e sono compilati per armtel, da entrambi gli archivi ho eliminato i man page e i doc al fine di recuperare tutto lo spazio possibile.
Ho spostato il file di configurazione di portmap nella cartella /etc e l’ho rinominato in portmap.conf.
Il demone unfsd ha in file di configurazione proprio (da non confondere con il file /etc/exports) che ho rinominato in unfs3.conf e inserito anch’esso nella cartella /etc.
Queste modifiche erano dovute dato che l’architettura del nas differisce dall’architettura di un sistema operativo debian. Gli script per initng riflettono queste modifiche per cui se cambiate posto a quei file dovrete modificare di conseguenza gli script di avvio dei demoni.

Copiate l’archivio nella vostra cartella condivisa del nas.

# cd /home/share/nome_cartella_della_vostra_condivisione
# tar -xvzf portmap_6.0-9_armel.tar.gz -C /
# tar -xvzf unfs3_0.9.21_armel.tar.gz -C /
# rm portmap_6.0-9_armel.tar.gz
# rm unfs3_0.9.21_armel.tar.gz
# cd /etc/initng/runlevel/
# echo portmap >> default.runlevel
# echo unfs3 >> default.runlevel

Adesso dovete configurare il file exports che indica al demone nfs quali cartelle deve condividere nella vostra rete locale:

# vi /etc/exports

Vi ricordo che i comandi per modificare un file con l’editor vi sono “i” per inserire nuovo testo e “ESC”+“:wq” per salvare e uscire, “ESC”+“:q!” per forzare l’uscita dal file senza salvare le modifiche apportate.

La configurazione del file in questione la lascio alla vostra esperienza personale, se state installando nfs sul nas si presuppone che sappiate quello che state facendo. Vi informo tuttavia che questa versione di nfs (unfs3) non supporta nfs v4 ne nfs v2, inoltre non supporta nemmeno alcuni tag di configurazione come sync.

Non ho voluto implementare il supporto per nfs v2 perché assolutamente obsoleto, infatti un client nfs presuppone che, se non diversamente specificato, il protocollo, che deve usare per condividere in locale una cartella esportata da una macchina remota, sia nfs v3. Per finire nfs v2 non supporta file di dimensione superiore a i 2Gb.

Una volta configurato il file exports potete riavviare la macchina o se preferite avviare manualmente i demoni con i comandi:

# ngc -u portmap
# ngc -u unfs3

Per maggiori informazioni su ngc, digitate:

# ngc -h

E dire che questo nas non lo uso neanche più…

Aggiornamento.

Ho modificato nuovamente lo script unfs3.i inserendo la riga require_network a causa dell’avvio immediato del demone unfsd da parte di initng (prima ancora che l’interfaccia di rete lan fosse attiva). Il demone unfsd non pubblicava la socket sull’indirizzo di rete locale impedendo l’accesso da remoto.

La clausola require_network impone ad initng di attendere che l’interfaccia di rete della lan sia attiva prima di avviare il server unfsd: problema risolto.

Rsync

Script di avvio per rsync. (Il programma è già incluso nel nas)
File rsyncd.i:

#!/sbin/itype

# Short-Description: fast remote file copy program daemon
# Description: rsync is a program that allows files to be copied to and
# from remote machines in much the same way as rcp.
# This provides rsyncd daemon functionality.

daemon rsyncd {
       need = bootmisc virtual/net;
       require_network;
       env RSYNC_CONFIG_FILE=/etc/rsyncd.conf;
       env_file = ${RSYNC_CONFIG_FILE};
       exec daemon = /usr/bin/rsync --daemon --no-detach --config ${RSYNC_CONFIG_FILE};
       daemon_stops_badly;
}

Per maggiori informazioni su rsync vedere nei commenti di questo stesso articolo.

Race condition tra Upstart e Samba se nel pc è presente un interfaccia bridge

Vengo subito al dunque, dopo un recente aggiornamento del pacchetto samba ho cominciato ad avere problemi ad accedere alle mie cartelle condivise sul mio ubuntu server 10.04.
Nella mia macchina è presente un bridge di rete che collega la mia interfaccia ethernet su cavo (eth0) con quella wifi (wlan0):

router <= eth0 (0.0.0.0) => br0 (192.168.1.10) <= wlan0 (0.0.0.0) => altri pc.

Il problema si risolveva se, dopo l’avvio della macchina, riavviavo il servizio samba.

Per trovare l’origine del problema ho controllato i file di log di samba:

[2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in)
bind failed on port 445 socket_addr = fe80::201:2eff:fe2f:d55%br0.
Error = Cannot assign requested address
[2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Cannot assign requested address
[2010/09/17 08:39:56, 0] lib/util_sock.c:938(open_socket_in)
bind failed on port 139 socket_addr = fe80::201:2eff:fe2f:d55%br0.
Error = Cannot assign requested address
[2010/09/17 08:39:56, 0] smbd/server.c:457(smbd_open_one_socket)
smbd_open_once_socket: open_socket_in: Cannot assign requested address

La mia configurazione di rete di samba è la seguente:

interfaces = 127.0.0.0/8 192.168.1.0/24 br0
bind interfaces only = yes

In pratica samba pubblica le sue sockets nell’interfaccia di rete br0 e loopback.

Il problema si presenta perché upstart non aspetta che il bridge di rete sia attivo prima di avviare il servizio samba. Il bridge impiega circa 15 secondi ad avviarsi, nel mentre samba pubblica le sue sockets solo nelle interfacce di rete attive  in quel momento, essendo l’interfaccia bridge ancora non attiva, samba fallisce la pubblicazione del servizio sul bridge impedendo così l’accesso da un computer remoto.
La conferma mi è stata data dal comando netstat -an.

Prima del riavvio del servizio samba:

tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN
...
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN

Dopo il riavvio del servizio samba:

tcp 0 0 127.0.0.1:139 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:139 0.0.0.0:* LISTEN
...
tcp 0 0 127.0.0.1:445 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.10:445 0.0.0.0:* LISTEN

La soluzione al problema è modificare lo script di avvio di samba di upstart.
Ovvero:

sudo nano /etc/init/smbd.conf

e cambiare la linea:

start on local-filesystems

in

start on (local-filesystems and net-device-up IFACE=br0)

Ovviamente se la vostra interfaccia bridge ha un nome diverso da br0 cambiatelo opportunamente.

In questo modo obbligherete upstart ad aspettare che il bridge sia attivo prima di avviare il demone samba.

Errori simili posso verificarsi se sulla vostra macchina viene eseguito il demone dhcp3-server configurato per fornire indirizzi ip sull’interfaccia bridge.

Race condiction analogo per dhcpd

(!sic) Ho risolto il problema con il servizio dhcp3 editando il file:

sudo nano /etc/init/rc-sysinit.conf

e cambiando la linea

start on filesystem and net-device-up IFACE=lo

in

start on filesystem and net-device-up IFACE=br0

For more info about this problem see:
https://bugs.launchpad.net/ubuntu/+source/dhcp3/+bug/580319

tftpd-hpa

Problemi anche con lui. il più delle volte si avvia e pubblica le sue socket sull’interfaccia bridge correttamente, tuttavia, sporadicamente fallisce.
Quindi forziamo lo script di avvio, del servizio tftp-hpa, ad attendere la disponibilità del bridge prima di avviare il demone:

nano /etc/init/tftpd-hpa.conf

e cambiare la riga:

start on (filesystem and net-device-up IFACE!=lo)

in

start on (filesystem and net-device-up IFACE=br0)

La condizione IFACE!=lo è sicuramente più furba tra tutte la condizioni di avvio riscontrate nei precedenti file di configurazione (dhcpd e samba), tuttavia non è sufficiente se nella vostra macchina avete più di un interfaccia di rete (es. tunnel ipv6). Il bridge è un interfaccia lenta e il servizio in questione finisce col pubblicare le proprie socket sulle altre interfacce di rete attive ma non sul bridge.

Giacché sono in tema…
Dato che in internet non ho visto molti esempi corretti di configurazioni (per debian) di interfacce bridge, riporto la mia configurazione di rete:

/etc/network/interfaces

auto lo
iface lo inet loopback

iface eth0 inet manual

iface wlan0 inet manual

auto br0
iface br0 inet static
	bridge_ports eth0 wlan0
	address 192.168.1.10
	network 192.168.1.0
	netmask 255.255.255.0
	gateway 192.168.1.1
	broadcast 192.168.1.255

Per esempi di configurazione diversi e più completi vi rimando alla pagina, in inglese, della wiki di debian.

LaCie 2Big Network tweaking: deframmentazione filesystem con xfs_fsr

It’s not a bug, it’s a feature. [Anonimo]

Chi ha già eseguito l‘hack del proprio nas avrà sicuramente notato che la partizione contenente i dati dell’utente è formattata con il filesystem xfs. Questo ottimo filesystem ha la brutta abitudine, con l’uso, di frammentarsi deteriorando così le sue prestazioni.

Per vedere lo stato di frammentazione del proprio filesystem:

# xfs_db -c frag -r /dev/md4

Vedrete qualcosa del tipo:

actual 3144, ideal 3135, fragmentation factor 0.29%

Per deframmentare il nas abbiamo bisogno dell’utility xfs_fsr, che non è installata sul nas.
Ho recuperato il programma dal pacchetto xfsdump della distro debian lenny compilato per armtel, quindi compatibile con il nas. Ho rimosso dal pacchetto tutti i file strettamente non necessari riducendolo a 14kb.

Potete anche andare a farvi un caffè, la prima esecuzione del programma ha impegnato più di 4 ore per finire. 😛

Per chi non si fosse informato, recentemente è uscito un aggiornamento del firmware del nas ver 2.2.6.
Se vi chiedete che fine hanno fatto le versioni 2.2.4 e 2.2.5… bhe della 2.2.4 non so dirvi molto ma la versione 2.2.5 del firmware è stata un flop totale. Il processo di installazione, che consisteva in due file da caricare sul nas, si piantava al caricamento del secondo file.

Ho testato l’hack su questa nuova versione del firmware, nei seguenti modi:

  • nas con firmware 2.2.3 bucato e aggiornato successivamente alla ver 2.2.6
  • aggiornato il nas alla versione 2.2.6 e successivamente bucato

in entrambi i casi è stato possibile bucare il nas.

Pulizie di fine pasqua…

Dopo un po di mesi che non aggiornavo il mio sito internet ho, in questi ultimi giorni, fatto un po di pulizie…

Ho pubblicato un progetto in linguaggio Java per il corso di programmazione di rete (BitCreek, una Content Distribution Network (CDN) ispirata a BitTorrent) compreso, come sempre, di codice, documentazione e sorgenti. Spero che possa dare uno aiuto a chi si affaccia per la prima volta alle socket tcp, tcp-ssl, udp, remote method invocation, pool di thread, ecc.. ecc.. in java.

D’altra parte ho eliminato il vecchio sito del liceo: inutile strascico di pagine obsolete. Ultima modifica, degna di nota, è la pagina di benvenuto al sito che adesso è integrata nel blog e il ripristino di alcuni collegamenti interrotti in alcuni post.

Appena ho un po di tempo pubblicherò un altro post sul nas 2big network. 😉

Good code Vs Bad code