Gizmodo riporta che i militari erano a conoscenza dei rischi potenziali legati allo spoofing GPS con la conseguenza per un drone di venire costretto ad atterrere in maniera analoga a quanto successo sin dal 2003 e non avevano mai affrontato il problema.

Tuttavia, certi attacchi basati su GPS spoofing sono molto difficili da mettere in pratica, e gli analisti diffidano fortemente delle tesi iraniane, classificandola propaganda. Le autorità iranian avrebbero dovuto conoscere la localizzazione del drone entro una manciata di metri e colpirlo con un segnale GPS più forte delle trasmissioni satellitari. Nessuno di questi segnal è criptato cosicchè il segnale più forte l’avrebbe vinta, ma a questo punto sarebbe necessario introdurre gradualmente degli errori per guidare il velivolo al punto di atterraggio scelto.
Gli USA controbattono infatti che il drone è andato perso durante una missione nell’Ovest dell’Afghanistan e portato in Iran in seguito ad una operazione spionistica.

Send post as PDF to

In Asterisk 10, è stato sostituito il media engine precedente, basato sugli standard telefonici, con uno in grado di supportare audio di alta qualità ed un pressoché illimitato numero di codecs. Nello specifico, oltre alle frequenze di campionamento a 8 e 16 kHz, Asterisk 10 ora supporta gli 8, 12, 16, 24, 32, 44.1, 48, 96 e 192 kHz per un audio a banda ultra larga. Supporta inoltre nativamente nuovi codecs, inclusi il codec di Skype, SILK, e lo Speex 32kHz. Tutto questo riguarda però esclusivamente il SIP channel driver.

Digium ha inoltre sostituito il MeetMe conferencing bridge di Asterisk con uno chiamato ConfBridge, che supporta tutti i codecs. Algoritmi intelligenti di mixing forniscono a ciascun participante la qualità audio ottimale, non la più bassa comune. ConfBridge comprende anche una applicazione leggera di video conferencing, che inoltra il video di uno speaker predefinito o dello speaker attuale agli altri participanti alla conference. Sono comunque richiesti SIP devices video che facciano uso dello stesso codec.

Asterisk 10 ora possiede capacità T.38 gateway che fanno in modo che fax in uscita provenienti da macchine fax analogiche siano connessi a T.38 fax endpoints su SIP e che chiamate fax T.38 siano inoltrate direttamente a macchine fax analogiche.

Infine, Asterisk 10 si sta avviando a divenire un text-message router, un bridge tra differenti protocolli di messaging, come SIP MESSAGE e XMPP.

Send post as PDF to

I passi da seguire sono semplicissimi, pertanto utilizzerò un modo molto schematico di rappresentarli.

Sullo smartphone
Impostazioni -> Controlli Wireless

Disattivare Wi-Fi se per caso fosse attivato

Tethering e hotspot portatile

Attivare Hotspot Wi-Fi portatile

A questo punto lo smartphone emette un messaggio di avvertimento che, con la funzione di Hotspot attivata, la batteria potrebbe esaurirsi rapidamente (putroppo è proprio così).

Ad ogni modo viene richiesta l’introduzione di una passphrase (8-64 caratteri) che sarà quella utilizzata per impostare la protezione WPA2 PSK.

Effettuata una prima volta questa operazione diverrà disponibile anche la voce di menu Configura Hotspot Wi-Fi, dalla quale sarà possibile reimpostare SSID di rete (che per default è AndroidAP) , password, e protezione (in questo caso, oltre a OPEN, risulta disponibile solo WPA2-PSK)

Da questo momento in poi ogni pc della rete potrà associarsi all’ hotspot Android, come risulta dalla seguente porzione di kern.log:

... wlan0: authenticate with 5c:da:d4:7f:c0:5a (try 1)
... wlan0: authenticated
... wlan0: associate with 5c:da:d4:7f:c0:5a (try 1)
... wlan0: RX AssocResp from 5c:da:d4:7f:c0:5a (capab=0x411 status=0 aid=1)
... wlan0: associated

l’hotspot sarà inoltre in grado di operare da server DHCP (al mio laptop viene infatti attribuito un IP 192.168.43.102, mentre, abbastanza ovviamente l’Hotspot assume per se stesso un indirizzo IP 192.168.43.1)

Send post as PDF to

Il software, può venire scaricato da SourceForge

Supposto di averlo archiviato in /opt/

e soddisfatti i prerequisiti:

# apt-get install libmysql++-dev libvorbis-dev libpcap-dev apache2 php5-mysql php5-gd

# mkdir /var/spool/voipmonitor
# cd /opt
# tar xvzf voipmonitor-3.0.1.tar.gz
# cd voipmonitor-3.0.1
# make
# make install
# mysqladmin -u root -p create voipmonitor
password:
#
# cat cdrtable.sql | mysql voipmonitor -p
password:
#

A questo punto, allo scopo di testare la cattura di una chiamata VoIP in ingresso (tramite il provider Messagenet) su un server Asterisk che la tratti come segue nel relativo context:

[incoming]
exten => 04371956065,1,Ringing(5)
exten => 04371956065,n,Answer
exten => 04371956065,n,Wait(5)
exten => 04371956065,n,MusiconHold()

si può avviare il programma così:

# ./voipmonitor -k -SRG -W -i eth0 -p password -v
Capturing on interface: eth0

Total calls [0] calls in queue[0]
voipmonitor: calls[0]
…
Total calls [0] calls in queue[0]
voipmonitor: calls[1]
…
Total calls [1] calls in queue[0]
…
storing to MySQL. Queue[1]
INSERT INTO `cdr` SET caller = ‘+390437xxxxxx’, callername = ‘+390437xxxxxx’, sipcallerip = 3563141964, sipcalledip = 3232235788, called = ‘04371956065′, duration = 21, progress_time = 0, first_rtp_time = 6, connect_duration = 21, calldate = FROM_UNIXTIME(1319031659), fbasename = ‘769284ca58464edc4b9770f53faeee04@sip.messagenet.it’, sighup = 0, lastSIPresponse = ‘200 OK’, lastSIPresponseNum = 200, bye = 3 , whohanged = ‘caller’ , a_ua = ” , b_ua = ‘foxtrot’ , a_index = 1 , a_received = 742 , a_lost = 0 , a_avgjitter = 1 , a_maxjitter = 1 , a_payload = 8 , a_sl1 = 0 , a_sl2 = 0 , a_sl3 = 0 , a_sl4 = 0 , a_sl5 = 0 , a_sl6 = 0 , a_sl7 = 0 , a_sl8 = 0 , a_sl9 = 0 , a_sl10 = 0 , a_d50 = 0 , a_d70 = 0 , a_d90 = 0 , a_d120 = 0 , a_d150 = 0 , a_d200 = 0 , a_d300 = 0 , a_saddr = 3252906024 , a_lossr_f1 = 0 , a_burstr_f1 = 0 , a_mos_f1 = 4.5 , a_lossr_f2 = 0 , a_burstr_f2 = 0 , a_mos_f2 = 4.5 , a_lossr_adapt = 0.00135135 , a_burstr_adapt = 0.998649 , a_mos_adapt = 4.2670996286306941 , b_index = 0 , b_received = 745 , b_lost = 0 , b_avgjitter = 1 , b_maxjitter = 2 , b_payload = 8 , b_sl1 = 0 , b_sl2 = 0 , b_sl3 = 0 , b_sl4 = 0 , b_sl5 = 0 , b_sl6 = 0 , b_sl7 = 0 , b_sl8 = 0 , b_sl9 = 0 , b_sl10 = 0 , b_d50 = 0 , b_d70 = 0 , b_d90 = 0 , b_d120 = 0 , b_d150 = 0 , b_d200 = 0 , b_d300 = 0 , b_saddr = 3232235788 , b_lossr_f1 = 0 , b_burstr_f1 = 0 , b_mos_f1 = 4.5 , b_lossr_f2 = 0 , b_burstr_f2 = 0 , b_mos_f2 = 4.5 , b_lossr_adapt = 0 , b_burstr_adapt = 0 , b_mos_adapt = 4.5
converting RAW file to WAV Queue[1]
voipmonitor: calls[1]
…
Total calls [0] calls in queue[0]
…
^Cvoipmonitor: SIGINT received, terminating

E’ evidente, dallo stesso output del programma, la creazione di un record relativo alla chiamata nel database MySQL
A questo punto, risulta inoltre presente in /var/spool/voipmonitor una directory corrispondente alla data/ora corrente (2011-10-19/) e contenente i seguenti file:

-rw-rw-rw- 1 root root 1235746 2011-10-19 13:12 2c5c0e485348eb282a46bda55600bcec@sip.messagenet.it.pcap
-rw-rw-rw- 1 root root  856364 2011-10-19 13:12 2c5c0e485348eb282a46bda55600bcec@sip.messagenet.it.wav
-rw-rw-rw- 1 root root   40704 2011-10-19 13:12 2c5c0e485348eb282a46bda55600bcec@sip.messagenet.it.1.graph
-rw-rw-rw- 1 root root   45295 2011-10-19 13:12 2c5c0e485348eb282a46bda55600bcec@sip.messagenet.it.0.graph

Se il significato dei primi due è inequivocabile, gli altri due sono file ASCII contenenti liste di coordinate. Esiste infatti, a cura dello stesso produttore, una applicazione web PHP (che però non è compresa nel package open source) che filtra i dati presenti nel database e graficizza la distribuzione di latenza e perdita di pacchetti.

Send post as PDF to

Dennis Ritchie (in piedi) e Ken Thompson al lavoro sul mitico PDP-11

Send post as PDF to

Ho notato, ad esempio, in più occasioni che i responsabili IT, almeno quelli già consapevoli del problema, tendono a far predisporre collegamenti di tipo SHDSL, talora in sostituzione di semplici ADSL che fino a quel momento avevano ben lavorato, pensando (giustamente per la verità) che sia importante per il VoIP avere una capacità di upstream pari a quella di downstream. Il problema, con questa adozione, è che il downstream, che costituisce la maggior parte del traffico non VoIP, viene fortemente limitato, e di conseguenza la competizione tra traffico realtime e traffico eterogeneo diviene ancora più critica, e il malcontento degli utenti, diffuso.
La soluzione classica consiste nell’implementare qualche forma di QoS o almeno traffic-shaping per priorizzare (ma in questo caso funziona solo in EGRESS) il traffico VoIP. In genere così la qualità della telefonia migliora (più o meno) ma il malcontento, riguardo alla peggiorata efficienza delle altre tecnologie, è semmai destinato ad aumentare.

Personalmente ritengo che un approccio alternativo possa essere preferibile.

Facciamo l’ipotesi che la azienda Pinco Pallino, (potrebbe trattarsi di un concessionario di auto o di un grossista di alimentari), abbia una decina di persone, tra impiegati, venditori e magazzino, abilitati ad accedere ad Internet. Ipotizziamo anche che chi si occupa dell’ IT sia una persona competente e magari, avendo implementato un cache dns server e un proxy tipo Squid, sia sempre riuscito a garantire un buon livello di accesso ad Internet tramite una normale ADSL aziendale. Coerentemente, progetti poi di implementare un sistema di telefonia VoIP basato su Asterisk.

Se adottare il modo visto sopra, probabilmente si troverebbe nei guai, ma potrebbe pure adottare una soluzione alternativa, anche discretamente più economica, semplicemente richiedendo l’installazione di una seconda ADSL aziendale, dedicata esclusivamente al traffico VoIP gestito dal server Asterisk, fondamentalmente quello scambiato con il VoIP Service Provider che si sarà scelto.
Un possibile schema è quello riportato qui sotto:

                                       +-----------------+
                                       |      gw 1       | ADSL1 provider1
                            +----------+   (default)     +------+
                            |          | NNN.NNN.NNN.NNN |      |
                     +------+-------+  +-----------------+      |
+-------------+      |     eth1     |                           |
|             |  eth0|              |                           |
| Rete Locale +-+----+ Linux router |                           | Internet
|             | |    |              |                           |
+-------------+ |    |     eth2     |                           |
+---------------+-+  +------+-------+  +-----------------+      |
|                 |         |          |      gw 2       |      |
| Asterisk Server |         +----------+     (VOIP)      +------+
|                 |                    | ZZZ.ZZZ.ZZZ.ZZZ | ADSL2 provider2
+-----------------+                    +-----------------+

Il server Asterisk è semplicemente un elemento della rete locale, nello stesso spazio di indirizzamento IP. La connettività Internet è filtrata da un router Linux. La eth1 di quest’ultimo è connessa tramite gw1 all’ ADSL provider1, mentre la eth2, tramite gw2, con l’ADSL2 provider2.

Il problema del router è solo quello di fornire appunto un semplicissimo routing differenziato.
Ipotizzando che il default gateway originale fosse gw1, dovremo ora fare in modo che qualsiasi traffico in ingresso su eth2 ottenga risposta sempre tramite eth2, e non tramite eth1, come invece avverrebbe normalmente.

Bisogna per prima cosa essere certi che il kernel Linux del router fornisca il supporto al “policy routing”.
Ad esempio, durante un eventuale ricompilazione del kernel, occorrerebbe effettuare le scelte sottostanti:

# cd /usr/src/linux
# make menuconfig
Selezionare "Networking --->"
Selezionare "Networking options --->"
[*] TCP/IP networking
[*] IP: advanced router
Scegliere IP: FIB lookup algorithm (FIB_HASH)
[*] IP: policy routing
[*] IP: use netfilter MARK value as routing key

A questo punto viene in soccorso il tool iproute2

Occorre innanzitutto creare una nuova voce nella policy routing table definita in /etc/iproute2/rt_tables.
Numerandola #1, chiamiamola “VOIP” (servirà proprio al routing del traffico VoIP attraverso eth2).

Dal prompt di root:

# echo 1 VOIP >> /etc/iproute2/rt_tables

Il passo successivo sarà quello di impostare una route con una singola regola per la table VOIP:

# ip route add default via ZZZ.ZZZ.ZZZ.ZZZ dev eth2 table VOIP
# ip rule add from table VOIP

Da ora in avanti i pacchetti in arrivo dal server Asterisk verranno sottoposti alla routing table VoIP dove, essendo presente una default route, verranno passati al gateway gw2. mentre i pacchetti che arrivano da tutti gli altri nodi locali continueranno ad utilizzare la main routing table.
E tutti vissero felici e contenti

Send post as PDF to

Per metterlo in pratica occorre avere installato, come prerequisito, il package bridge-utils e procedere esattamente come gia visto nel post precedente, ma invocare l’iniziale comando ssh lato client in questa maniera:

# ssh -o Tunnel=ethernet -f -w 0:0 true

Con lo switch -o viene specificato il tipo di tunnel come ethernet (bridge) anziché point-to-point, mentre lo switch -f invia ssh in background in modo da ritornare , dopo l’autenticazione, immediatamente alla linea di comando locale e non a quella remota, e prima dell’esecuzione del comando finale (true). questo switch si aspetta un comando remoto di qualche tipo, motivo per cui va bene specificare “true”, che effettivamente non fa niente se non restituire 0 (success). Lo switch -w 0:0 serve a fare in modo che vengano generati i devices tap in entrambi i nodi come tap0. Se specificassimo -w 0:1, ad esempio, otterremmo tap0 localmente e tap1 in remoto, ecc.

Consideriamo di voler attuare questo bridging tra una lan locale ed una lan remota, entrambe affacciate su Internet, ciascuna tramite un router Linux avente due interfacce, una (eth0) collegata ad Internet con indirizzo IP pubblico e l’altra (eth1) collegata fisicamente alla propria LAN. Per comodità ipotizziamo che gli indirizzamenti IP delle due LAN siano 172.16.1.0/16 il primo e 172.16.2.0/16 (in pratica due sottoinsiemi facilmente distinguibili della stessa sottorete).

Su entrambi i router dovrebbe essere a questo punto possibile (via ifconfig -a) sia eth0 che eth1 che tap0. Ora che entrambi sono connessi l’uno con l’altro tramite Internet via SSH, occorre infine impostare l’interfaccia bridge. Qui tornano necessarie le bridge-utils per creare una bridge interface br0, impartendo i comandi (su entrambi i nodi!):

brctl addbr br0
brctl addif br0 eth1
brctl addif br0 tap0

quindi attivarle, se già non lo fossero:

ifconfig tap0 up
ifconfig br0 up

Ciò ha generato la interfaccia br0, quindi messo in bridge eth1 con tap0.

Send post as PDF to

DHCP, invece, è un sistema client/server che si occupa della configurazione automatica dei parametri di rete delle varie postazioni collegate alla stessa quando queste la richiedono. Il server DHCP accoglie la richiesta e, in base al MAC address del client, agli IP disponibili e alla propria configurazione, fornisce loro i parametri di rete necessari per utilizzare la rete locale e Internet, parametri che in genere sono: l’IP locale, la netmask, l’indirizzo del gateway di rete e quello dei server DNS. L’IP locale può anche essere univocamente associato ad un MAC address. In questo modo l’utente (la macchina) avrà sempre lo stesso indirizzo al posto di uno scelto tra quelli disponibili. Inoltre, il server DHCP può essere configurato per comunicare a BIND l’hostname e l’indirizzo delle macchine a cui ha fornito i parametri di connessione in modo da aggiornare automaticamente il file di zona relativo alla rete locale. Tuttavia, ripeto, la configurazione di un tale sistema non è banale e si rivela spesso inopportuna per reti casalinghe o anche aziendali di piccole dimensioni.

Una valida alternativa al binomio BIND e DHCP, per rendere più semplice e coerente l’accesso sia alla LAN che a Internet in un contesto del genere, è però costituita dal software dnsmasq, che permette di ottenere gli stessi risultati con una complessità di configurazione e gestione decisamente minore.
Anziché usare i file di zona, decisamente complessi da creare e aggiornare, Dnsmasq fa uso del solo file di sistema “/etc/hosts” presente nella macchina su cui gira il servizio.

L’installazione su sistemi Debian e Debian-like, come Ubuntu, è semplicissima:

# sudo apt-get install dnsmasq-base
# sudo apt-get install dnsmasq

Il primo package contiene l’eseguibile dnsmasq (e la relativa documentazione), mentre il secondo l’ infrastruttura necessaria perché possa venire eseguito come system daemon.

La configurazione di default è già funzionale: imposta un server DNS che, per prima cosa, tenta di risolvere i nomi esaminando il proprio file /etc/hosts, e se così non fosse possibile, inoltra la richiesta ai server elencati in /etc/resolv.conf. Così è sufficiente mantenere aggiornato l’elenco degli host della propria rete locale solo sulla macchina server su cui è installato dnsmasq.

Per fare una semplice verifica:

# dig ubuntu.com @localhost

; <<>> DiG 9.7.1-P2 <<>> ubuntu.com @localhost
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10350
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;ubuntu.com. IN A

;; ANSWER SECTION:
ubuntu.com. 202 IN A 91.189.94.156

;; Query time: 29 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sun Sep 25 23:12:06 2011
;; MSG SIZE rcvd: 44

Per configurare dnsmasq ad agire come cache per l’ host sul quale è in esecuzione basta che la lista dei nameservers in /etc/resolv.conf contenga la linea

nameserver 127.0.0.1

come prima linea.

Di conseguenza, impartendo una seconda volta il comando precedente il Query time si riduce a 0 msec, a testimonianza che la cache DNS conteneva già la risposta.

L’ideale sarebbe disporre di un resolver così strutturato:

nameserver 127.0.0.1
nameserver 208.67.222.222
nameserver 208.67.220.220

nel quale, oltre al nameserver locale, vengono utilizzati i server unicast di OpenDNS, consigliati per la loro velocità, per l’efficienza dei filtri e perché capaci di aggirare le restrizioni sui DNS operate da provider presenti in Italia, Cina e altri paesi non esattamente paladini delle libertà civili.

Desiderando inoltre che il DNS server risolva i nomi locali, basta semplicemente aggiungerli al file /etc/hosts:

# echo 192.168.1.3 blackstar >>/etc/hosts

e riavviare il servizio:

# /etc/init.d/dnsmasq restart [ OK ]
* Restarting DNS forwarder and DHCP server dnsmasq

quindi:

# nslookup blackstar localhost
Server: localhost
Address: 127.0.0.1#53

Name: blackstar
Address: 192.168.1.3

Nel file degli host è possibile tuttavia elencare solamente postazioni con ip statico. Per tutti quei dispositivi (laptop, smartphone, ecc.) cui è preferibile assegnare l’indirizzo dinamicamente, dnsmasq mette a disposizione il server DHCP integrato: in tal modo, quando un dispositivo ottiene l’ip, dnsmasq lo aggiunge all’elenco degli host noti di cui è in grado di risolvere il nome. Per attivare il DHCP (che per default è disattivato), facendo contemporaneamente attenzione a disattivare qualsiasi altro servizio analogo eventualmente presente sulla LAN, per evitare conflitti, basta aggiungere un paio di righe al file di configurazione /etc/dnsmasq.conf, ad esempio:

dhcp-range=192.168.1.50,192.168.1.150,12h
dhcp-option=option:router,192.168.1.1

La prima definisce il range degli indirizzi assegnabili, con un “lease time” di 12 ore; la seconda indica l’indirizzo del gateway di default. Come server DNS viene assegnato automaticamente quello sui cui gira dnsmasq.

Il modo più semplice di effettuare la risoluzione dei nomi negli indirizzi assegnati dinamicamente dal DHCP server in Dnsmasq consiste nell’impostare correttamente gli hostnames in ciascun host della LAN.
Ad esempio, nella maggior parte dei sistemi Linux, basta editare /etc/hostname, che imposta appunto l’ hostname.
Per i dispositivi mobili il discorso si fa più complesso.
Per fare un esempio pratico entrambi gli smartphone android che possediamo in famiglia presentano lo stesso hostname, tra l’altro decisamente poco memorizzabile:

android_9774d56d682e549c

ma ciascuno, ovviamente un MAC diverso, e nella fattispecie 5C:DA:D4:7F:C0:5A il mio personale, e 5C:DA:D4:42:AD:EB quello della mia compagna.

E’ certamente possibile modificare all’origine l’hostname dopo aver avviato lo smartphone in recovery mode, oppure tramite l’Android SDK, ma si può anche intraprendere una strada alternativa, anche per evitare discussioni e patemi d’animo al proprietario dell’apparecchio.
Si può infatti impostare una nuova riga in /etc/dnsmasq.conf contenente:

dhcp-host=5C:DA:D4:7F:C0:5A,smartphone1

e una volta riavviato il servizio dnsmasq ottenere, come desiderato, la corretta risoluzione del nome appena assegnato:

# cat /var/lib/miscdnsmasq.leases
1317075600 5c:da:d4:7f:c0:5a 192.168.1.88 smartphone1 *

# nslookup smartphone1
Server: 127.0.0.1
Address: 127.0.0.1#53

Name: smartphone1
Address: 192.168.1.88

Send post as PDF to

In questo contesto, con tunneling si vuole intendere un reale tunneling di livello-3 (IP sopra SSH), e non l’ SSH forwarding cui spesso ci si riferisce impropriamente come SSH tunneling.
In questo caso viene creata una nuova interfaccia di rete virtuale, utilizzabile al pari di qualsiasi altra.
Questo meccanismo è decisamente più potente e flessible del semplice forwarding e può venire sfruttato oltre che per TCP, anche per UDP e ICMP.
Una volta stabilita, tale VPN permette l’i inoltro di traffico tra due network remote, o quantomeno distinte, tramite una connessione SSH.
Impostarla è realmente molto semplice:

Sulla macchina server occorre abilitare il tunneling e permettere l’accesso come root, modificando /etc/ssh/sshd_config:

PermitTunnel yes
PermitRootlogin yes

quindi riavviare il server:

# /etc/init.d/sshd restart

Sulla macchina client, e già come utente root (altrimenti non sarebbe possibile la creazione dei necessari network devices) si può quindi effettuare il login al server.

# ssh -w any:any server

In seguito a cio, sia sul server che sul client, sarà presente un nuovo tun device:

tun0    Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          POINTOPOINT NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

Per configurarli, dato che si tratta di devices di tipo point-to-point, su ciascuno dei due andrà impostato il corrispondente peer.
Rispettivamente, sul client:

# ifconfig tun0 172.16.0.1 pointopoint 172.16.0.2

e sul server:

# ifconfig tun0 172.16.0.2 pointopoint 172.16.0.1

Da ultimo, ovviamente, sarà necessario impostare un routing coerente tra le due reti appena aggregate.

Vi è modo, pure, di impostare il tunneling a layer 2, con devices ethernet virtuali. Tutto ciò che occorre fare in tal caso è impostare il device type nel file di configurazione del client (/etc/ssh/ssh_config) con la direttiva:

TunnelDevice ethernet

dopodiche i nuovi network devices saranno di tipo tap anziché tun.

Send post as PDF to

Qui invece, vi è l’esempio di come un socket tcp gestito tramite bash possa venire usato a tale scopo.

Ipotizziamo, per comodità, di trovarci a dover scaricare l’ultima release di Asterisk da una macchina, priva di qualsiasi browser, e sprovvista degli abituali tools finalizzati al download.

Quanto basta è solamente:

# (echo -e "GET /pub/telephony/asterisk/releases/asterisk-1.8.7.0.tar.gz HTTP/1.0rnrn"
1>&3 & cat 0<&3) 3<> /dev/tcp/downloads.asterisk.org/80
| (read i; while [ "$(echo $i | tr -d 'r')" != "" ];
do read i; done; cat) > asterisk-1.8.7.0.tar.gz

Appena lanciato il comando è possibile verificare da un altro terminale che è effettivamente stata stabilita una connessione al server specificato:

# netstat -t
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 silversurfer:46365      downloads.asterisk.:www ESTABLISHED

mentre il file specificato si sta generando nella directory corrente fino a raggiungere le dimensioni originali:

# ls -lrt
-rw-r--r--  1 myuser mygroup    27828568 2011-09-24 00:42 asterisk-1.8.7.0.tar.gz

successivamente potremo verificare che il file sia stato correttamente trasferito:

# sha1sum asterisk-1.8.7.0.tar.gz  |grep "e28ad2f52a227acc7ec6d6952f3fd41baecd6292"
e28ad2f52a227acc7ec6d6952f3fd41baecd6292  asterisk-1.8.7.0.tar.gz

Vediamo come opera il codice bash utilizzato per effettuane il download:

Per scaricare un file tramite HTTP, occorre connettersi al server, inviare una richiesta HTTP (in questo caso “GET / HTTP/1.0″) eventualmente seguita da qualsiasi altro HTTP headers sia opportuno specificare, e da una linea vuota. Il server HTTP dovrebbe replicare di conseguenza con uno status code e relativo significato (tipo “200 OK”), altri headers HTTP, una linea vuota, quindi il contenuto.

Sappiamo già che in bash, è possibile aprire network socket, tramite l’ interface virtuale /dev/tcp/<server>/<porta>. Infatti reindirizziamo la richiesta HTTP a /dev/tcp/downloads.asterisk.org/80 proprio per contattare il server downloads.asterisk.org sulla porta 80. Tuttavia, dato che ogni singola operazione su /dev/tcp crea una nuova connessione e infine la chiude, dobbiamo riuscire a mantenere la stessa connessione e da essa ottenere il contenuto desiderato.
Ciò si effettua creando una subshell, ed impostando il file descriptor 3 per leggere dal e scrivere sul socket:

# (echo -e "GET /pub/telephony/asterisk/releases/asterisk-1.8.7.0.tar.gz HTTP/1.0rnrn"
1>&3 & cat 0<&3) 3<> /dev/tcp/downloads.asterisk.org/80

I due comandi nella subshell vengono eseguiti in modo concorrente, pertanto il comando echo è seguito da un carattere di ampersand (&) per procedere in background, mentre il suo output viene rediretto al file descriptor 3 (1>&3). Viene usato read per leggere l’ input, tramite pipe, sempre dal file descriptor 3 (0<&3).
Ciò avviene all’interno di un loop che legge tutti gli headers HTTP fino a trovare una linea vuota, quindi il resto viene passato a cat, ed infine rediretto su file.

Send post as PDF to