Come faccio a sapere se il mio ISP blocca il traffico P2P?

Qualche volta le richieste di consulenza informatica che ricevo sono alquanto bizzarre. Non per questo però sono da ritenersi banali.

L’ultima mi è stata rivolta da un amico che, dopo aver sottoscritto un contratto di abbonamento ADSL con un noto gestore di telefonia italiano, mi chiede:

“Ma secondo te, il mio ISP (Internet Service Provider) manipola il traffico P2P (Peer-To-Peer) sul mio account?”

Sembrerebbe una domanda banale, tuttavia da consulente mi sento di dover fare alcune considerazioni in merito.

In primo luogo è necessario comprendere cosa sono e come funzionano i protocolli P2P. Banalmente, quando pensiamo a questi protocolli, salta subito alla mente eDonkey (ampiamente sfruttato dal client eMule) e BitTorrent. In realtà si tratta di protocolli ampiamente utilizzati per la condivisione di file (non necessariamente a scopo di pirateria) che non impiegano una gerarchia fra i nodi. In questi protocolli quindi non esiste una relazione Client-Server ma i nodi sono considerati contemporaneamente Client e Server.

Non tutti i protocolli sono uguali
C’è inoltre da tenere presente che i protocolli P2P possono essere molto diversi tra loro. Ad esempio, il protocollo eDonkey, conosciuto anche come ed2k o swamp, prevede l’impiego di alcuni server con lo scopo mi mantenere una sorta di indice dei file presenti in una rete di nodi. Il bittorrent invece prevede l’uso del tracker, un server a cui i client si collegano periodicamente per aggiornare e coordinare i nodi. Nel tracker vengono mantenuti solo le informazioni utili a reperire le risorse, non le risorse stesse. Queste informazioni sono conservate ed aggiornate in file con estensione torrent.

Poiché i nodi sono contemporaneamente client e server, tutti i nodi sono chiamati a gestire connessioni in ingresso per consentire ad altri client la condivisione delle risorse. Questo vuol dire che di norma, i client ricevono connessioni dall’esterno su alcune porte TCP/IP.

eMule ad esempio, utilizza le porte 4662/TCP e 4772/UDP (a volte anche 4672) per gestire il traffico entrante, mentre il protocollo Bittorrent impiega un range che va da 6881 a 6900. Questi sono i parametri standard che generalmente vengono utilizzati e che comunque possono essere modificati all’occorrenza dall’utente.

Nei panni dell’ISP
Per rispondere alla domanda precedente io ne fare un’altra: “Se fossi chiamato a gestire un ISP, come mi comporterei nei confronti delle comunicazioni P2P?”.

In Italia i provider Internet a carattere nazionale sono dotati di linee commerciali e linee business. Queste ultime sono dedicate a contratti aziendali utilizzati ad esempio da: pubblica amministrazione, ospedali, banche, liberi professionisti, ecc. Le linee commerciali sono invece destinate all’uso domestico. Questa segregazione delle reti aiuta sicuramente ad ovviare al rallentamento che la linea commerciale provoca, specie nelle ore di punta.

QOS
Al di là della banda disponibile, c’è da dire che non tutti i servizi offerti da Internet sono uguali. Dal punto di vista dell’utente che ne deve usufruire, potremmo suddividerli in tre macro gruppi:

- Servizi Batch: sono quei servizi che non necessitano di un intervento da parte dell’utente se non marginalmente: ad esempio all’avvio dello stesso. Pensiamo al servizio di trasferimento dei file come FTP (File Transfer Protocol) oppure ai protocolli P2P. Può sembrare strano ma per questi servizi, i difetti dovuti ad una congestione della banda non sono tanto sentiti poiché l’utente non deve forzatamente stare davanti al PC attendendo la fine delle operazioni. E’ vero quindi che, entro certi limiti, avere una banda larga o piccola fa poca differenza.

- Servizi Interattivi: sono servizi che richiedono una continua iterazione da parte dell’utente. Appartengono a questa famiglia la navigazione sul web, l’invio di posta elettronica (con ovvi limiti), l’uso di ERP (come ad esempio SAP) e così via. In genere sono servizi che occupano poca banda, di contro però necessitano di essere molto veloci perché l’utente poco sopporta anche pochi secondi di ritardo.

- Servizi ad Alta Disponibilità: sono quei servizi per i quali la banda è da considerarsi il driver prioritario. Sono ad esempio i servizi di streaming audio/video ed il VoIP. In questo caso una rete sottodimensionata oppure una banda insufficiente rischia non solo di irritare gli utenti ma addirittura di rendere inutile il servizio stesso.

Fatta questa distinzione possiamo immaginare come sia necessario intervenire in qualche maniera al fine di dare una priorità ad alcuni servizi togliendola ad altri.
Il metodo oggi più utilizzato per priorizzare i servizi è quello che impiega il modello di Qualità del Servizio (QoS). Si tratta di accorgimenti ed algoritmi adottati dai vari dispositivi di rete in tempo reale durante lo smistamento del traffico. Ce ne sono tanti e con nome diverso ma tutti vengono generalmente identificati come QoS.

Restando nell’ambito delle linee commerciali, la prima misura che adotterei è quella di introdurre un modello di qualità del servizio (qos).

Blocco del traffico
Bloccare il traffico su alcune porte è sicuramente il metodo più semplice di intervenire ma è anche il metodo più facile da aggirare. In effetti per bloccare le porte che comunemente vengono utilizzate da questi protocolli non vi è bisogno di hadrware particolarmente dotati in termini di CPU perché è possibile definire delle regole statiche. Non a caso i firewall che adottano questo approccio prendono il nome di stateless cioè senza memoria. In realtà basta modificare le porte usate dal servizio per ovviare al problema. E’ ovvio che se l’interesse dell’ISP è quello di arginare il traffico del 70%-80% degli utenti questo è sicuramente un ottimo metodo.

Analisi del traffico di rete
Il modo più efficace invece consiste nell’adottare un sistema di monitoraggio attivo in grado di discriminare il traffico che attraversa la rete al livello più alto dello strato OSI ossia il livello applicativo. E’ il lavoro svolto dalla maggior parte dei firewall statefull che al contrario dei fratelli minori stateless riassemblano tutti i pacchetti prima di consegnarli al destinatario. Vengono spesso usati per intercettare virus e connessioni pericolose e possono dare i loro frutti anche nel caso di protocolli P2P anche su porte non convenzionali. Il rovescio della medaglia è dato dal fatto che ispezionare tutti i pacchetti in transito mantenendo una velocità adeguata necessita di molta potenza di calcolo e questo implica un costo che potrebbe non essere compensato dalla maggior larghezza di banda a disposzione.

A valle di queste considerazioni vi consiglio un sito web dove poter fare alcuni test e capire effettivamente se il vostro ISP adotta uno o più metodi indicati in precedenza:

http://broadband.mpi-sws.org/transparency/bttest.php

Alla prossima.

IPCop – Come aprire la rete Green alla rete Blue

La Blue Net di IPCop serve ad interfacciare una connettività wifi che si ntende mantenere separata dalla rete locale LAN (Green Net). Questo per consentire una maggiore sicurezza, dal momento che gli endpoint che si collegano ad IPCop tramite wifi non vedranno la rete locale a meno di aprire le porte desiderate per i protocolli TCP ed UDP.

IPCop però non supporta nativamente il bridging delle schede di rete e non risulta agevole simulare il comportamento tipico dei router adsl comunemente in commercio nei negozi al giorno d’oggi. Non c’è modo infatti, tramite interfaccia grafica, di consentire il pieno accesso alla Green Net da parte dei computer che si collegano per mezzo della wifi (vedi ad esempio il trafico ICMP).

Mi è capitato di recente di installare una versione di IPCop con supporto wifi per mezzo dell’addon WLAN-AP e di dover simulare proprio il tipico comportamento dell’Access Point, dove la rete cablata è condivisa con quella senza fili.

Per abilitare tutto il traffico ho inserito alcune righe nel file /etc/rc.d/rc.firewall.local che è il file contenente i comandi da impartire al sistema operativo durante il boot per personalizzare le regole di firewalling senza interferire con la distribuzione:

/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT

Queste righe sono state inserite nella sezione start (ovviamente). In linea di principio, per abiitare un protocollo è sufficiente impartire il comando secondo a forma:

/sbin/iptables -A CUSTOMFORWARD -i 'blue device' -o 'green device' -p 'protocollo' -j ACCEPT

Per comodità, di seguito è riportato un esempio di rc.firewall.local che svolge questa attività:

#!/bin/sh
# Used for private firewall rules
# See how we were called.
case "$1" in
start)
## add your 'start' rules here
#morzello blue vs green
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p icmp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p tcp -j ACCEPT
/sbin/iptables -A CUSTOMFORWARD -i ath0 -o eth0 -p udp -j ACCEPT
;;
stop)
## add your 'stop' rules here
;;
reload)
$0 stop
$0 start
## add your 'reload' rules here
;;
*)
echo "Usage: $0 {start|stop|reload}"
;;
esac

Spero che questo articolo possa essere utile a chi deve ottenere questo risultato.

SGCop ver 1.4.21

Nuova versione di SGCop disponibile sul sito.

Anche questa volta non ci sono sostanziali differenze con la relativa versione di originale. L’unica modifica apportata riguarda l’upload degli aggiornamenti.
Da questa versione infatti il firewall punterà ad una cartella di questo sito per fare gli aggiornamenti e non più sul server di IPCop. Resta comunque possibile caricare i files di IPCop perchè il relativo certificato GPG è ancora presente.
Da notare che l’indice dei nuovi upgrade è ancora prelevato dal sito di IPCop; questo per consentire all’amministratore di sapere se ci sono nuovi aggiornamenti per la piattaforma (Io purtroppo non sono molto veloce a mantenere il codice sorgente).

Per qualunque informazione lasciate un post.

Alla prox.

SGCop Downloads

SGCop – Release 1.4.21
sources 1.4.21 – sgcop-src-1.4.21.tar.gz
update from 1.4.18 to 1.4.19 – sgcop-1.4.19-update.i686.tgz
update from 1.4.19 to 1.4.20 – sgcop-1.4.20-update.i686.tgz
avmdrv – 2.4.36-1 – sgcop-avmdrv-2.4.36-1.i686.tgz
install iso image 1.4.21 – sgcop-1.4.21-install-cd.i686.zip
install pxe image 1.4.21 – sgcop-1.4.21-install-pxe.i686.tgz
install usb fdd image – 1.4.21 – sgcop-1.4.21-install-usb-fdd.i686.img.gz
install usb hdd image – 1.4.21 – sgcop-1.4.21-install-usb-hdd.i686.img.gz
install usb zip image – 1.4.21 – sgcop-1.4.21-install-usb-zip.i686.img.gz
update from 1.4.20 to 1.4.21 – sgcop-1.4.21-update.i686.tgz

SGCop – Release 1.4.18
sources 1.4.18 – sgcop-src-1.4.18.tar.gz
update from 1.4.16 to 1.4.17 – sgcop-1.4.17-update.i686.tgz
avmdrv – 2.4.34-1 – sgcop-avmdrv-2.4.34-1.i686.tgz
install iso image 1.4.18 – sgcop-1.4.18-install-cd.i686.zip
install pxe image 1.4.18 – sgcop-1.4.18-install-pxe.i686.tgz
install usb fdd image – 1.4.18 – sgcop-1.4.18-install-usb-fdd.i686.img.gz
install usb hdd image – 1.4.18 – sgcop-1.4.18-install-usb-hdd.i686.img.gz
install usb zip image – 1.4.18 – sgcop-1.4.18-install-usb-zip.i686.img.gz
update from 1.4.17 to 1.4.18 – sgcop-1.4.18-update.i686.tgz

SGCop – Release 1.4.16
GnuPG Patch for SGCop 1.4.16 – sgcop-1.4.16-gnupg-patch.tar.gz
update from 1.4.15 to 1.4.16 – sgcop-1.4.16-update.i686.tgz
install usb zip image – 1.4.16 – sgcop-1.4.16-install-usb-zip.i686.img.gz
install usb hdd image – 1.4.16 – sgcop-1.4.16-install-usb-hdd.i686.img.gz
install usb fdd image – 1.4.16 – sgcop-1.4.16-install-usb-fdd.i686.img.gz
install pxe image – 1.4.16 – sgcop-1.4.16-install-pxe.i686.tgz
install iso image – 1.4.16 – sgcop-1.4.16-install-cd.i686.iso.zip
fcdsl drivers – 1.4.16 – sgcop-1.4.16-fcdsl.i686.tgz

SGCop ver 1.4.18

Ho appena finito di caricare sul sito tutti i files relativi alla nuova versione di SGCop.

Sostanzialmente non ci sono particolari modifiche al sistema operativo se non quelle indicate già nella release di IPCop 1.4.18.

Da parte mia ho solo aggiunto il certificato GPG al fine di rendere possibile gli upgrade direttamente dal frontend web come avviene per IPCop.
Poichè questa opzione è stata aggiunta solo adesso, chi volesse aggiornare il software già dalla versione 1.4.16 deve scaricare la patch sgcop-1.4.16-gnupg-patch.tar.gz disponibile su questo sito e copiarne il contenuto nella cartella /root.

Per quanto riguarda la release 1.4.17 tengo a precisare che non dovrebbero esserci problemi di spazio dato che non sono a conoscenza di Magnia multiprocessore. Il kernel smp non è disponibile in SGCop, dunque la directory /boot dovrebbe avere spazio sufficiente per fare l’aggiornamento alla versione 1.4.18 senza rimuovere alcun file.

Enjoy.

SGCop – The IPCop porting for Toshiba Magnia SG Series

Tempo fa ho attivato un contratto ADSL per connettermi ad Internet da casa. Quasi subito però mi sono accorto che i vari modem/router in circolazione non facevano al caso mio.
Io volevo una soluzione che mi consentisse di fare tante cose (VPN, Wi-Fi, DMZ, un piccolo server Web, …).
Sul mercato ho trovato tante alternative valide ma nessuna che mi lasciasse peinamente soddisfatto.
Così su Ebay ho comprato un Toshiba Magnia SG30.
Si tratta di un banalissimo PC di compatte dimensioni, senza monitor e tastiera ma con integrato due schede di rete ed uno switch.
Come soluzione era l’ideale, però il software che vi era montato non era più manutenuto da Toshiba e poi non era proprio quello che avevo in mente.
Come sistema operativo alternativo pensai subito a Linux, come distribuzione ad IPCop.
Unico problema e che IPCop non è fatto per essere installato su un pc senza mouse e tastiera, almeno non senza problemi. Del resto io volevo sfruttare tutte le potenzialità dell’hardware che avevo a disposizione.

Cos’è SGCop
SGCop nasce da una mia esigenza personale. In parole povere si tratta del porting di IPCop per i PC della serie Magnia SG (SG10,SG20 e SG30).

Le sostanziali differenze con IPCop sono:

- compilazione del codice ottimizzata per i686;
- supporto della console seriale (ttyS);
- supporto “grezzo” del display LCD.

Per quanto riguarda il resto, SGCop è al 100% compatibile con IPCop.

Poichè IPCop esegue codice compatibile con i sistemi i386, gli unici plug in che possono creare problemi sono quelli che installano moduli aggiuntivi nel kernel.

Purtroppo io non ho avuto molto tempo da dedicare al porting ed alcune cose non sono ancora completate.

Installare SGCop

Installare SGCop è facile come IPCop ed infatti è possibile seguire il manuale di IPCop per completare tutto il processo.

Tuttavia il processo di installazione originale prevede l’uso di una console virtuale (tty1,tty2,…) che non sul Magnia.
Poichè ho voluto lasciare la piena compatibilità con IPCop, per avviare l’installazione è necessario impartire il comando da console:

/bin/install [console]

Dove il parametro console puo essere /dev/tty2 se si dispone di un monitor ed una tastiera ovvero /dev/null in caso si stia utilizzando una console seriale (si perdono però i dettagli della installazione che IPCop invia su tty2).

OpenVPN ed IP routing

Ciao belli, questa volta parliamo di OpenVPN ed reti WAN.

In particolare vedremo come modificare la tabella di routing di una workstation che opera in una WAN che implementa OpenVPN.

Supponiamo di avere un pc connesso ad una rete locale (WAN o LAN non è rilevante adesso) e di voler raggiungere un’altra rete tramite VPN (utilizzando OpenVPN nello specifico).

Tutto quello che dovremo fare è impostare correttamente il nostro client.

Supponiamo inoltre che la rete agganciata in VPN non sia una semplice LAN bensì una WAN.

Come possiamo fare in modo che il nostro client possa navigare in tutta la rete remota?

Per comprendere meglio questa domanda, diamo un’occhiata alla figura riportata di seguito:



In questo esempio ci sono 3 reti differenti (Work LAN, LAN e DMZ) suddivise nel seguente modo:

Area Subnet Gateway
Work 10.0.0.0/8 10.0.0.1
LAN 192.168.0.0/8 192.168.0.1
DMZ 192.168.1.0/8 192.168.1.1

Sono presenti inoltre due connessioni ad Internet (una per B ed una per C).

Per comodità indichiamo le macchine con delle lettere (A, B, C, D) assumendo che abbiano i seguenti indirizzi IP:

Host Network Address
A Work LAN 10.0.0.238
A LAN (VPN) 192.168.0.6
B WorkLAN 10.0.0.1
B Internet 208.77.188.166
C LAN 192.168.0.1
C DMZ 192.168.1.1
C Internet 28.15.33.1
D DMZ 192.168.1.20

Nel momento in cui A porta a termine con successo la connessione VPN, i pacchetti verso la rete LAN seguono la linea tratteggiata.
Quello che noi vogliamo ottenere è di riuscire a far comunicare l’host A con l’host D.

In questo esempio utilizzeremo un client Windows ma sono sicuro che gli utenti di altre piattaforme non avranno problemi a riprodurre gli stessi comandi sul proprio sistema operativo.

Dopo aver installato e configurato Openvpn per la conenssione remota, possiamo eseguire il comando ipconfig /all. Il risultato dovrebbe essere simile a questo:

Configurazione IP di Windows

        Nome host . . . . . . . . . . . . . . : HOST_A

        Suffisso DNS primario  . . . . . . .  : worklan.local

        Tipo nodo . . . . . . . . . . . . . .  : Ibrido

        Routing IP abilitato. . . . . . . . . : No

        Proxy WINS abilitato . . . . . . . .  : No

        Elenco di ricerca suffissi DNS. . . . : worklan.local

Scheda Ethernet Connessione alla rete locale (LAN) 2:

        Suffisso DNS specifico per connessione: 

        Descrizione . . . . . . . . . . . . . : TAP-Win32 Adapter V8

        Indirizzo fisico. . . . . . . . . . . : FF-FD-4E-18-2F-07

        DHCP abilitato. . . . . . . . . . . . : Sì

        Configurazione automatica abilitata   : Sì

        Indirizzo IP. . . . . . . . . . . . . : 192.168.0.6

        Subnet mask . . . . . . . . . . . . . : 255.255.255.0

        Gateway predefinito . . . . . . . . . : 

        Server DHCP . . . . . . . . . . . . . : 192.168.0.1

        Lease ottenuto. . . . . . . . . . . . : mercoledì 13 giugno 2007 16.45.53

        Scadenza lease . . . . . . . . . . .  : giovedì 12 giugno 2008 16.45.53

Scheda Ethernet Connessione alla rete locale (LAN):

        Suffisso DNS specifico per connessione: worklan.local

        Descrizione . . . . . . . . . . . . . : Broadcom NetLink (TM) Gigabit Ethernet

        Indirizzo fisico. . . . . . . . . . . : FF-07-28-CB-55-B8

        DHCP abilitato. . . . . . . . . . . . : Sì

        Configurazione automatica abilitata   : Sì

        Indirizzo IP. . . . . . . . . . . . . : 10.0.0.238

        Subnet mask . . . . . . . . . . . . . : 255.255.255.0

        Gateway predefinito . . . . . . . . . : 10.0.0.1

        Server DHCP . . . . . . . . . . . . . : 10.0.0.13

        Server DNS . . . . . . . . . . . . .  : 10.0.0.12

        Lease ottenuto. . . . . . . . . . . . : mercoledì 13 giugno 2007 12.14.36

        Scadenza lease . . . . . . . . . . .  : giovedì 14 giugno 2007 12.14.36

A questo punto possiamo utilizzare il comando tracert per capire in che modo i pacchetti vengono instradati nella rete. Per fare questo partiamo cercando ad esempio un qualunque computer appartenente alla rete work lan:

tracert 10.0.0.5

La risposta dovrebbe essere simile a questa:

Tracing route to desktop5.worklan.local.0.0.10.in-addr.arpa [10.0.0.5]

over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms desktop5.work.local.0.0.10.in-addr.arpa [10.0.0.5]

Trace complete.

Come è possibile notare tra il punto 10.0.0.238 ed il punto 10.0.0.5 c’è un solo salto. Questo perchè i due computer appartengono alla stessa rete.

Ripetiamo lo stesso comando ma cambiamo indirizzo di destinazione:

tracert 192.168.0.44
Tracing route to [192.168.0.44]

over a maximum of 30 hops:

1 <130 ms <143 ms <172 ms [192.168.0.44]

Trace complete.

Anche in questo caso il salto è sempre uno poichè l’host A ha un indrizzo di rete appartenenete alla rete LAN (192.168.0.6).
Adesso è la volta di scoprire se l’host D è disponibile sulla rete. Come abbiamo fatto in precedenza, utilizziamo il comando tracert con l’indirizzo desiderato:

tracert 192.168.1.20

Tracing route to 192.168.1.20 over a maximum of 30 hops
1 <1 ms <1 ms <1 ms gateway1.worklan.local [10.0.0.1]
2 65 ms 52 ms 67 ms 208.77.188.166
3 gateway.my-isp-example.com [208.77.50.249]
reports: Destination net unreachable. Trace complete.

Come è possibile notare, qualcosa non è andato per il verso giusto.
L’instradamento dei pacchetti IP segue regole ben precise che è necessario conoscere se vogliamo riuscire nel nostro intento.

Eseguendo il comando ipconfig /all possiamo notare come l’host A sia dotato di due schede di rete che si connettono ad altrettante reti locali. Quando un pacchetto IP deve essere consegnato a destinazione, il protocollo IP esegue alcuni controlli:

Se esistono regole particolari specificati per l’indirizzo IP del destinatario, il pacchetto seguirà dette regole.
Altrimenti: se il pacchetto è destinato ad un indirizzo IP della rete locale verrà instradato tramite detta rete.
Altrimenti: se il pacchetto IP non è destinato alla rete locale, si demanda il compito della consegna al gateway di default.

Nel nostro caso, poichè non esistono regole particolari specificate per l’indirizzo 192.168.1.20 e poichè non si tratta di un indirizzo di rete locale (in entrambe le reti) il nostro pacchetto è stato instradato verlo l’host B (10.0.0.1).
L’host B a sua volta non sapendo come consegnare il pacchetto ne ha demandato la consegna al proprio gateway di default (208.77.50.249) con scarsi risultati dato che l’indirizzo 192.168.1.20 appartiene ad una classe di indirizzi LAN non instradabili su Internet.

Per tale motivo l’ultimo host ha risposto alla richiesta con un errore: “destinazione irraggiungibile”.
Anche nel caso in cui l’host B fosse stato in grado di instradare il pacchetto verso l’indirizzo 192.168.1.20, questi sicuramente non avrebbe raggiundo il nostro obbiettivo (host D) poichè per raggiungere questo computer, noi sappiamo che è necessario passare attraverso la nostra VPN.

Per farla breve, Default Gateway per noi vuol dire: “se non sei riuscito in altro modo, rivolgiti a lui”.

Le regole di instradamento di cui parlavamo prima sono visibili tramite il comando route. Eseguiamo il comando specificando il parametro print e cerchiamo di capirci qualcosa:

route print
===========================================================================
Elenco interfacce
0×1 ……………………… MS TCP Loopback interface

0×2 …ff fd 4e 18 2f 07 …… TAP-Win32 Adapter V8 – SecuRemote Miniport
0×10003 …ff 07 28 cb 55 b8 …… Broadcom NetLink (TM) Gigabit Ethernet
Connection
===========================================================================
===========================================================================
Route attive:
Indirizzo rete             Mask             Gateway       Interfac.  Metric

          0.0.0.0          0.0.0.0         10.0.0.1      10.0.0.238   20
         10.0.0.0    255.255.255.0       10.0.0.238      10.0.0.238   20
       10.0.0.238  255.255.255.255        127.0.0.1       127.0.0.1   20

   10.255.255.255  255.255.255.255       10.0.0.238      10.0.0.238   20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1   1
      192.168.0.0    255.255.255.0      192.168.0.1     192.168.0.6   1

      192.168.0.6  255.255.255.255        127.0.0.1       127.0.0.1   30
    192.168.0.255  255.255.255.255      192.168.0.6     192.168.0.6   30
        224.0.0.0        240.0.0.0       10.0.0.238      10.0.0.238   20

        224.0.0.0        240.0.0.0      192.168.0.6     192.168.0.6   30
  255.255.255.255  255.255.255.255       10.0.0.238      10.0.0.238   1
  255.255.255.255  255.255.255.255      192.168.0.6     192.168.0.6   1

Gateway predefinito:          10.0.0.1
===========================================================================

Tralasciamo la sezione delle interfacce e concentriamoci solo sulle route attive. In questa sede non ha senso spiegare il significato di tutte le rige; l’importante è comprendere come avviene il routing in base alla tabella sopra riportata.

La prima cosa che bisogna sapere è che per instradare un pacchetto, il protocollo calcola un AND logico bit per bit tra l’indirizzo del destinatario e la sottorete (Mask).
Se come risultato dell’operazione logica otteniamo l’indirizzo di rete (prima colonna), la regola è soddisfatta ed il pacchetto seguirà un percorso piuttosto che un altro.
Qualora più regole fossero soddisfatte contemporaneamente, la priorità verrà assegnata mediante la metrica (ultima colonna). In realtà quello che abbiamo appena asserito riguardo alla metrica non è corretto; essa serve a dare un peso alle connessioni. Più la metrica è alta e più è facile aspettarsi connessioni lente o con parecchi intermediari (hop).

Per capire come vengono testate le regole, facciamo un esempio con l’ indirizzo ip 10.0.0.5 utilizzato in precedenza rappresentando gli indirizzi ip in forma binaria:

Rapp. Decimale Rapp. Binaria
Indirizzo: 10.0.0.5 00001010.00000000.00000000.00000101
Mask: 255.255.255.0 11111111.11111111.11111111.00000000
AND: 10.0.0.0 00001010.00000000.00000000.00000000

Se adesso traduciamo il valore ottenuto dall’AND logico (00001010.00000000.00000000.00000000) in decimale otteniamo 10.0.0.0 che corrisponde all’indirizzo di rete appartenente all’interfaccia 10.0.0.238 (seconda regola nella tabella delle route attive).

Quando la regola è soddisfatta, il pacchetto viene instratato tramite il gateway specificato nella regola stessa.

Detto questo diamo uno sguardo ad alcune delle regole riportate nella tabella delle route attive.
La prima è quella relativa al gateway di default. In pratica viene adottatta quando nessuna altra regola può essere soddisfatta. Da notare che, nel nostro caso, il gateway predefinito è mappato sull’interfaccia (10.0.0.238) questo significa che tutto il traffico verso Internet passa tramite la scheda di rete e non tramite la VPN.
Impostare un gateway predefinito anche per la connessione VPN (vedi risultato del comando ipconfig/all) non ha senso dal momento in cui solo un gateway può instradare di default i pacchetti.

Le righe 2 e 6 indicano che se l’indirizzo fa parte della rete locale, il pacchetto può essere consegnato direttamente dall’host, senza dover richiedere la consegna ad altri gateway.

La riga 5 indica che l’indirizzo 127.0.0.1 è l’indirizzo di loopback (host locale). Nel caso dell’HOST_A l’indirizzo di loopback sta a significare proprio l’HOST_A.

La terza e la settima riga indicano che gli indirizzi dell’host sono equivalenti a quello di loopback mentre le righe che cominciano per “224.0.0.0″ indicano il broadcast.

Dopo questa sbrodolata di informazioni, come possiamo raggiungere il nostro scopo?

Basta parlare di teoria, torniamo alla pratica.
Per risolvere agevolmente il nostro problema, aggiungiamo una regola specifica tale per cui i pacchetti destinati alla rete 192.168.1.0/8 vengano instradati tramite un altro gateway.

Fondamentale per noi è conoscere l’host preposto ad instradare correttamente i nostri pacchetti verso la rete DMZ.

Una costrizione che non possiamo violare nella costruzione della regola è che detto gateway deve appartenede ad una rete locale (altrimenti l’instradamento avverrebbe tramite il gateway di default).

Nel nostro esempio, il gateway preposto ad instradare i pacchetti verso la rete DMZ è l’host C (192.168.0.1).

Il comando che consente l’inserimento di una nuova regola è sempre route questa volta abinato al parametro add.

route add 192.168.0.0 mask:255.255.255.0 192.168.0.1

L’essenziale per aggiungere una regola tramite il comando “route add” è:
- l’indirizzo della rete: 192.168.0.0
- la mask: 255.255.255.0
- il gateway: 192.168.0.1

Se volessimo conservare la validità della nostra regola al riavvio del pc, potremmo indicare anche il parametro -p (permanente).

Eseguendo nuovamente il comando route print la nuova regola dovrebbe comparire nell’elenco delle route attive.

A questo punto possiamo fare una prova per capire se la regola funziona correttamente o meno:

tracert 192.168.1.20

Rilevazione instradamento verso 192.168.1.20 su un massimo di 30 punti di passaggio

1 560 ms 507 ms 420 ms 192.168.0.1
2 474 ms 561 ms 443 ms 192.168.1.20

Rilevazione completata.

Come è possibile vedere, questa volta abbiamo colto nel segno.

Spero che questo articolo sia stato utile. Esistono diversi modi per raggiungere l’obbiettivo e questo solo uno dei tanti.

Per saperne di più:

La Homepage di OpenVPN
Il comando Route di Windows
Cenni preliminari sul routing
Un utile tutorial sul routing IP ed IPX