E’ necessario da prima installare i seguenti pacchetti:

• bluez

Necessario per instaurare la connessione bluetooth seriale con il cellulare.

• wvdial

Per effettuare la connessione vera e propria

Per prima cosa bisogna effettuare il pairing tra i due dispositivi, la procedura da seguire la potrete trovare sul link [2] in fondo alla pagina.

Configurazione

Ora configuriamo la connessione seriale, con il comando hcitool scan cerchiamo il MAC del nostro cellulare e segniamocelo:

Scanning ...
        00:01:02:03:04:05       Nss

Ora cerchiamo il canale su cui è in ascolto il servizio di Dialup con il comando:

sdptool browse 00:01:02:03:04:05

E nell’output cerchiamo la seguente porzione e segniamoci il valore del parametro “Channel”, nel mio caso 3.

...
Service Name: Dialup Networking
Service RecHandle: 0x10002
Service Class ID List:
  "Dialup Networking" (0x1103)
  "Generic Networking" (0x1201)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 3
Profile Descriptor List:
  "Dialup Networking" (0x1103)
    Version: 0x0100
...

Editiamo il file /etc/bluetooth/rfcomm.conf e inseriamoci, sostituendo i parametri visti in precedenza, le seguenti righe:

rfcomm0 {
        bind yes;
        device 00:01:02:03:04:05;
        channel 3;
}

Nel file /etc/wvdial.conf creiamo invece la seguente sezione:

[Dialer tre]
Modem = /dev/rfcomm0
Baud = 115200
Init1 = ATH
Init2 = ATE1
Init3 = AT+CGDCONT=1,"IP","tre.it","",0,0
Dial Command = ATDT
Phone = *99#
Username = tre
Password = tre
Ask Password = 0
Stupid Mode = 1
Idle Seconds = 0
Auto DNS = 1
Check Def Route = 1

Connessione

Per effettuare il collegamento seriale lanciamo da shell il comando che creerà il device /dev/rfcomm0:

rfcomm bind 0

La connessione invece andrà effettuata invece con il comando:

wvdial tre

[1] http://archlinux.it
[2] https://wiki.archlinux.org/index.php/Bluetooth#Pairing

Per evitare di usare la sintassi errata ho dato un occhiata in rete e ho trovato questa utile pagina [1], che riassume gli errori tipici che vengono commessi, e un trucco per “listare” tutti i file in una directory in maniera corretta.

Molti consigliano di usare la seguente sintassi per scorrere i file:

for i in *.txt; do
   echo $i
done

così da sfruttare il sistema di “Shell Expansions”, in questo caso però se non vi fossero file txt all’interno della directory, e quindi la shell non effettuasse l’espansione del carattere “*”, otterremmo un non aspettato:

*.txt

Per evitare questo comportamento va inserito prima del ciclo for il comando shopt -s nullglob, lo script diverrà quindi:

shopt -s nullglob
for i in *.txt; do
   echo $i
done

[1] http://mywiki.wooledge.org/BashPitfalls

Pensate forse che la cosa sia andata liscia la primo colpo??
ASSOLUTAMENTE NO…

Tinc ha bisogno di un interfaccia Tun/Tap per funzionare, questa è stata configurata grazie alla guida [3] trovata sul sito apposito, i comandi principali, che vanno eseguiti nella macchina host, per la creazione del device tun, ammesso che il nostro container sia identificato come 101, sono:

vzctl set 101 --devices c:10:200:rw --save
vzctl set 101 --capability net_admin:on --save

Per permettere al container di usare il dispositivo tun/tap.

vzctl exec 101 mkdir -p /dev/net
vzctl exec 101 mknod /dev/net/tun c 10 200
vzctl exec 101 chmod 600 /dev/net/tun

Per creare il device all’interno del container.

vzctl set 101 --devnodes net/tun:rw --save

Per ricordare a vzctl di ricreare il device ad ogni avvio del container.

Configurando tinc[4] tutto sarebbe dovuto funzionare a dovere… Peccato che lanciando il comando per visualizzare l’output di debug di tinc:

tincd -D -d5 -n tulug

mi sono accorto di questo strano comportamento:

Error while reading from Linux ethertap device /dev/net/tun: File descriptor in bad state

Per risolvere il problema, dopo una ricerca su internet e un minimo di immaginazione è stato sufficiente commentare l’opzione Interface = /dev/net/tun nel file di configurazione della VPN.

In alcuni casi invece di Interface viene usata l’opzione Device, in quel caso dovrete commentare quest’ultima.

Ora tutto funziona a dovere e il server è raggiungibile all’interno della VPN.

La soluzione sembrava trovata… in realtà il problema sembra essere un’altro, al secondo tentativo di tirare su la vpn il problema si ripropone e spulciando l’output del comando dmesg sulla macchina Host è spuntato questo “simpatico” messaggio…

sysfs: cannot create duplicate filename '/devices/virtual/net/tulug'
...
Pid: 9675, comm: tincd Tainted: G        W  2.6.32-3-pve #1
Call Trace:
 [<ffffffff811439c7>] ? sysfs_add_one+0xcc/0xe4
 [<ffffffff811439c7>] ? sysfs_add_one+0xcc/0xe4
 [<ffffffff8104dec8>] ? warn_slowpath_common+0x77/0xa3
 [<ffffffff8104df50>] ? warn_slowpath_fmt+0x51/0x59
 [<ffffffff811438f3>] ? sysfs_pathname+0x35/0x3d
 [<ffffffff811438f3>] ? sysfs_pathname+0x35/0x3d
 [<ffffffff811438f3>] ? sysfs_pathname+0x35/0x3d
 [<ffffffff811438f3>] ? sysfs_pathname+0x35/0x3d
 [<ffffffff811439c7>] ? sysfs_add_one+0xcc/0xe4
 [<ffffffff81143f75>] ? create_dir+0x4f/0x7c
 [<ffffffff81143ff5>] ? sysfs_create_dir+0x53/0x68
 [<ffffffff8117b00b>] ? kobject_get+0x12/0x17
 [<ffffffff8117b141>] ? kobject_add_internal+0xcb/0x181
 [<ffffffff8117b3a3>] ? kobject_add+0x74/0x7c
 [<ffffffff8117b27f>] ? kobject_set_name_vargs+0x4e/0x56
 [<ffffffff810e8a98>] ? __kmalloc+0x15a/0x17f
 [<ffffffff81312006>] ? mutex_lock+0xd/0x31
 [<ffffffff8117b00b>] ? kobject_get+0x12/0x17
 [<ffffffff8120ddcf>] ? get_device_parent_nodep+0x125/0x19f
 [<ffffffff8120edeb>] ? device_add+0xce/0x53f
 [<ffffffff81258bed>] ? sk_prot_alloc+0x5b/0x108
 [<ffffffff812671a7>] ? register_netdevice+0x218/0x30c
 [<ffffffffa0219dd4>] ? tun_chr_ioctl+0x294/0x827 [tun]
 [<ffffffff810b6587>] ? find_get_page+0x1a/0x77
 [<ffffffff810fc926>] ? vfs_ioctl+0x21/0x6c
 [<ffffffff810fce74>] ? do_vfs_ioctl+0x48d/0x4cb
 [<ffffffff810fceef>] ? sys_ioctl+0x3d/0x5c
 [<ffffffff8112729a>] ? dev_ifsioc+0x10f/0x24c
 [<ffffffff81127fcb>] ? compat_sys_ioctl+0x3f8/0x459
 [<ffffffff81037492>] ? ia32_sysret+0x0/0x5
---[ end trace 5b6bc3d8be2d0a32 ]---
kobject_add_internal failed for tulug with -EEXIST, 
don't try to register things with the same name in the same directory.

Sono ancora alla ricerca di una eventuale soluzione al problema…

[1] Proxmox OpenVZ e veth
[2] http://www.tinc-vpn.org/
[3] http://wiki.openvz.org/VPN_via_the_TUN/TAP_device
[4] Una semplice VPN con tinc

Dati utili:

• vzctl version 3.0.24
• ID Macchina: 101
• Veth name: veth101.0
• IP Pubblic: X.Y.Z.T

Ho aggiunto nella macchina Host una rotta statica del tipo:

X.Y.Z.T 0.0.0.0 255.255.255.255 UH 0 0 0 veth101.0

E nel container ho configurato la eth0 con i seguenti parametri:

auto eth0
iface eth0 inet static
	address X.Y.Z.T
	netmask 255.255.255.255
	up /sbin/ip route add default dev eth0

Tutto sembrava essere corretto, peccato che la macchina in questo modo non riusciva a comunicare con l’esterno in entrambi le direzioni.

Il problema sorgeva nel momento in cui l’interfaccia veth101.0, settata nel file di configurazione della macchina virtuale, veniva messa in bridge su vmbr0, anche se non specificato, “grazie” al file di configurazione /etc/vz/vznet.conf che dichiara:

#!/bin/bash
EXTERNAL_SCRIPT="/usr/sbin/vznetaddbr"

L’interfaccia se messa in bridge rendeva non raggiungibile il container, contrariamente togliendo veth101.0 dal bridge tutto funzionava perfettamente.

Per risolvere questo problema ho modificato lo script trovato qui [1] in questo modo

#!/bin/bash
# This script source VPS configuration files
#in the same order as vzctl does
 
# if one of these files does not exist
#then something is really broken
 
[ -f /etc/vz/vz.conf ] || exit 1
[ -f $VE_CONFFILE ] || exit 1
 
# source both files. Note the order, it is important
. /etc/vz/vz.conf
. $VE_CONFFILE
 
# Configure veth with IP after VPS has started
{
  IP=X.Y.Z.T
  DEV=veth101.0
  BRIDGE=vmbr0
  while sleep 1; do
    /sbin/ifconfig $DEV 0 >/dev/null 2>&1
    if [ $? -eq 0 ]; then
      /sbin/ip route add $IP dev $DEV
      brctl delif $BRIDGE $DEV
      break
    fi
  done
} &

l’ho salvato in /etc/vz/conf/101.mount e ho dato il permesso di esecuzione al proprietario con

 chmod u+x /etc/vz/conf/101.mount

Così, riavviando la macchina, tutto è tornato a funzionare.

[1] OpenVZ wiki

In questo caso ho trovato un post su un interessante servizio di creazione di diagrammi on-line in maniera collaborativa.
Cacoo http://cacoo.com/.

Cacoo is a user friendly online drawing tool that allows you to create a variety of diagrams such as site maps, wire frames, UML and network charts. Cacoo can be used free of charge.

Me lo appunto qui per non scordarlo ;).

[1] http://leganerd.com

Per installare pacchetti nel NAS è però necessario sbloccare l’accesso telnet!!
Al boot il NAS cerca ed esegue lo script fun_plug che si trova nella directory Volume1, nel nostro caso possiamo utilizzare un particolare fun_plug realizzato da “fonz” [2].

Le istruzione per installarlo/configurarlo sono nel wiki specificatamente dedicato al Nas (DNS-323) [3].

Personalmente ho creato il pacchetto tramite l’ambiente di compilazione [4] fornito dallo stesso “fonz”.

Potete trovare in fondo alla pagina il links ai file contenenti i sorgenti [5] e il pacchetto [6].
This is the md5sum of the package 2d2219663d0c4248cf8100bda451ba6c.

Per installarlo basterà copiare il pacchetto nel NAS accedere tramite telnet o ssh e utilizzare il comando:

funpkg -i tinc-1.0.13-1.tgz

e seguire le istruzioni mostrate al termine dell’installazione.

Per eseguire tinc all’avvio è invece necessario aggiungere i permessi di esecuzione allo script tinc.sh in /ffp/start con il comando:

chmod +x /ffp/start/tinc.sh

Have fun… :D

[1] DNS-323
[2] http://www.inreto.de/dns323/fun-plug/
[3] http://wiki.dns323.info/howto:ffp?s=ffp
[4] http://nas-tweaks.net/CH3SNAS:Tutorials/Compiling_software
[5] Source of tinc for DNS-323 (402)
[6] Package of tinc for DNS-323 (448)

• Automatic full mesh routing

Regardless of how you set up the tinc daemons to connect to each other, VPN traffic is always (if possible) sent directly to the destination, without going through intermediate hops.

• Easily expand your VPN

When you want to add nodes to your VPN, all you have to do is add an extra configuration file, there is no need to start new daemons or create and configure new devices or network interfaces.

• Ability to bridge ethernet segments

You can link multiple ethernet segments together to work like a single segment, allowing you to run applications and games that normally only work on a LAN over the Internet.

Verranno mostrati i passi essenziali da seguire…

• Abbiamo 2 computer PCA e PCB
1. PCA con direttamente raggiungibile e con ip pubblico x.y.z.t
2. PCB dietro nat quindi non direttamente raggiungibile

entrambi i pc hanno installata la distribuzione ArchLinux.

• Su entrambi i PC:
1. Installiamo i pacchetti necessari

pacman -S openssh zlib lzo
yaourt -S tinc

2. Definiamo la variabile $VPNNAME assegnandole il nome che vogliamo dare alla vostra VPN

VPNNAME=mia_vpn

3. Creiamo i file e le directory necessarie

mkdir -p /etc/tinc/$VPNNAME/hosts
mkdir -p /usr/var/run/
touch /etc/tinc/$VPNNAME/tinc.conf
touch /etc/tinc/$VPNNAME/tinc-down
touch /etc/tinc/$VPNNAME/tinc-up
chmod +x /etc/tinc/$VPNNAME/tinc-up
chmod +x /etc/tinc/$VPNNAME/tinc-down

• Ora spostiamoci su PCA (quello con ip pubblico x.y.z.t)

ATTENZIONE: sostituire a $PCxHOSTNAME l’hostname della macchina, a $INTERNETIF l’interfaccia con la quale la macchina esce su internet e a $VPNNAME il nome della vpn usato precedentemente (VPNNAME=mia_vpn)

1. Inseriamo le seguenti righe nel file /etc/tinc/$VPNNAME/tinc.conf

Name = $PCAHOSTNAME
AddressFamily = ipv4
BindToInterface = $INTERNETIF
Device = /dev/net/tun
PrivateKeyFile=/etc/tinc/$VPNNAME/rsa_key.priv

2. Creiamo il file /etc/tinc/$VPNNAME/hosts/$PCAHOSTNAME e all’interno mettiamo:
   l’ip 10.0.10.1 è stato preso a caso dalla classe 10.x.x.x, potrete cambiarlo a vostro piacimento

Address = x.y.z.t
Subnet = 10.0.10.1/32

3. Aggiungiamo al file /etc/tinc/$VPNNAME/tinc-up

#!/bin/bash
ifconfig $VPNNAME 10.0.10.1 netmask 255.255.0.0 up

4. Mentre nel file /etc/tinc/$VPNNAME/tinc-down mettiamo

#!/bin/bash
ifconfig $VPNNAME down

5. Lanciamo il comando per generare la chiave per criptare la comunicazione e diamo invio alle successive richieste

tincd -K -n $VPNNAME

• Possiamo finalmente passare a PCB, i passi saranno uguali se non per alcuni dettagli
1. Configuriamo il portforwarding del router in modo da mandare tutte le richieste delle porte 655 TCP/UDP su PCB
2. Inseriamo le seguenti righe nel file /etc/tinc/$VPNNAME/tinc.conf

Rispetto alla configurazione di PCA abbiamo aggiunto le righe 5 e 6.

1 2 3 4 5 6 7

Name = $PCBHOSTNAME AddressFamily = ipv4 BindToInterface = $INTERNETIF Device = /dev/net/tun ConnectTo = $PCAHOSTNAME TCPOnly = yes PrivateKeyFile=/etc/tinc/$VPNNAME/rsa_key.priv

3. Creiamo il file /etc/tinc/$VPNNAME/hosts/$PCBHOSTNAME e inseriamoci:

l’ip 10.0.10.2 è stato preso a caso dalla classe 10.x.x.x, potrete cambiarlo a vostro piacimento

Subnet = 10.0.10.2/32

4. Aggiungiamo al file /etc/tinc/$VPNNAME/tinc-up

#!/bin/bash
ifconfig $VPNNAME 10.0.10.2 netmask 255.255.0.0 up

5. Mentre nel file /etc/tinc/$VPNNAME/tinc-down mettiamo

#!/bin/bash
ifconfig $VPNNAME down

6. Lanciamo il comando per generare la chiave per criptare la comunicazione e diamo invio alle successive richieste

tincd -K -n $VPNNAME

La procedura è quasi terminata, dovremmo solo copiare i file

• /etc/tinc/$VPNNAME/hosts/$PCAHOSTNAME sulla stessa directory in PCB
• /etc/tinc/$VPNNAME/hosts/$PCBHOSTNAME sulla stessa directory in PCA

In questo momento dovremmo avere nella directory etc/tinc/$VPNNAME/ di entrambe le macchine i seguenti file

./tinc.conf
./tinc-up
./rsa_key.priv
./tinc-down
./hosts
./hosts/$PCAHOSTNAME
./hosts/$PCBHOSTNAME

Se tutto è stato configurato in maniera corretta, basterà dare il seguente comando su entrambi i pc

tincd -n $VPNNAME

e per verificare l’effettivo funzionamento

• Da PCA proviamo:

ping 10.0.10.2

• Da PCB proviamo:

ping 10.0.10.1

In caso di problemi è possibile lanciare tinc in modalità debug per analizzare al meglio eventuali errori

tincd -D -d5 -n $VPNNAME

[1] http://it.wikipedia.org/wiki/Virtual_Private_Network
[2] http://www.tinc-vpn.org/

Niente di più semplice, basterà inserire nel file .h la seguente macro

 
#ifdef DEBUG
#define YELLOW ”\033[1;33m”
#define RED "\033[31m"
#define GREEN "\033[32m"
#endif
 
#ifdef DEBUG
  /**PRINTE... PRINTError*/
  #define PRINTE(format, args...)  printf(RED format NORMAL "\n", ##args);
  /**PRINTW... PRINTWarning*/
  #define PRINTW(format, args...)  printf(YELLOW format NORMAL "\n", ##args);
  /**PRINTA... PRINTAlarm*/
  #define PRINTA(format, args...)  printf(GREEN format NORMAL "\n", ##args); 
#else
  #define PRINTE(format, args...)
  #define PRINTW(format, args...)
  #define PRINTA(format, args...)
#endif

e nel codice, volendo lasciare un messaggio di debug, al posto della solita printf, basterà usare una tra le seguenti macro PRINTE/PRINTW/PRINTA.

Per abilitare il debug basterà compilare con l’opzione -DDEBUG e le macro faranno il resto.
Se il codice viene compilato senza tale opzione, le chiamate a PRINTE/PRINTW/PRINTA verranno completamente eliminate dal software.

Per navigare attualmente con un indirizzo IPv6 (alcuni siti/servizi sono già disponibili con questo protocollo) vi è la necessità che qualcuno ce ne fornisca uno.

Perché crearsi un tunnel IPv6?
La mia è stata semplice curiosità…

Per creare il tunnel abbiamo bisogno di un Tunnel broker [2], personalmente ho usato HURRICANE ELECTRIC [3] e di seguito vi illustrerò la serie di passi necessari per crearsi un proprio tunnel IPv6.

Iniziamo la procedura…

Per usufruire del servizio è necessario registrarsi alla pagina http://tunnelbroker.net/register.php.
Una volta effettuato il login alla pagina, sulla destra si avrà a disposizione un pannello con le funzioni utente da cui andrà selezionata la voce Create Regular Tunnel.

Verrà chiesto, a questo punto, di inserire un “IPv4 endpoint”, l’indirizzo IPv4 della vostra parte del tunnel…

• Se avete un indirizzo IPv4 fisso potete inserirlo tranquillamente nella casella
• Se invece il vostro indirizzo non è fisso ma varia di volta in volta dovrete usare uno script per aggiornare l’indirizzo di volta in volta come indicato qui [4](nel prossimo post mostrerò lo script)

Se la macchina da collegare via IPv6 è quella su cui stiamo lavorando, basterà inserire come “IPv4 endpoint” il valore che si trova in “You are viewing from IP” e premendo il tasto Submit verremo rimandati alla pagina con i dettagli del tunnel appena creato…

Qui, in fondo alla pagina sarà presente un menù con la scritta Example IPv6 Tunnel Configurations by OS (Windows, Linux, etc.), dal quale è possibile ricavare i comandi per una corretta configurazione del tunnel.

Config Examples

Nel caso di linux ci verranno mostrate le righe da copiare e incollare nella nostra shell per abilitare il tunnel…
Fatto questo basterà verificarne il funzionamento attraverso il comando

ping6 ipv6.google.com

[1] http://it.wikipedia.org/wiki/IPv6
[2] http://en.wikipedia.org/wiki/Tunnel_broker
[3] http://he.net/
[4] https://tunnelbroker.net/ipv4_end.php

Problema:

• Router con pagina di amministrazione sulla porta 8081
• Ip del router settato a 192.168.10.1
• Router con dmz abilitata su ip 192.168.10.90
• Come accedo dall’esterno alla porta 8081 del router se quest’ultimo redirige tutte le richieste su 192.168.10.90

Soluzione…

• Lorenzo :D

Basterà aggiungere sulla macchina 192.168.10.90 il file /etc/xinetd.d/routerwebmin e all’interno di questo le seguenti righe:
Il servizio sarà di tipo tproxy sunproxyadmin in quanto è il servizio abbinato alla porta 8081 nel file /etc/services

service sunproxyadmin
{
        socket_type = stream
        protocol = tcp
        wait = no
        user = root
        bind = 192.168.10.90
        redirect = 192.168.10.1 8081
        disable = no
}

a questo punto avviamo xinetd con il comando /etc/rc.d/xinetd start.
PS. ricordiamoci di aggiungere tale demone tra quelli che partono all’avvio…