A pensarci bene, sono sicuro che disporre di una VPN basata su SSL è una gran cosa, prima di tutto perchè può essere utilizzata in ambienti dove i firewall sono restittivi. Mi riferisco in particolare ai firewall aziendalli che controllano il traffico uscente dei dipendenti per mezzo di ACL (access control list).
In molte aziende che ho visitato, il collegamento ad Internet avviene tramite un http proxy. Connessioni ad Internet di questo tipo non consentono l'impiego di protocolli diversi dall'HTTP. (niente SMTP, POP3, streaming UDP ecc.ecc.).
Per tale motivo, quando mi capita di fare assistenza in posti di questo genere la domande più frequente è:
Ma non c'è un modo per arginare il proxy?
Come dice la parola stessa, un HTTP proxy mastica solo il protocollo HTTP.
Potete immaginare quante persone ho visto accanirsi nel tentativo di instradare traffico di varia natura verso questi poveri proxy?
C'è una considerazione aggiuntiva da fare; nelle grandi organizzazioni, spesso oltre al limite del protocollo si aggiunge quello imposto dalle ACL. In alcuni casi quindi non è possibile visitare pagine web dal contenuto morale dubbio, siti di hacking, casinò e via dicendo.
A dire il vero non ho mai visto ACL implementate veramente bene. Spesso il sito non è raggiungibile mediante l'URL ma lo è se viene specificato l'indirizzo IP del server. Tranne in rari casi questo non è necessariamente un problema dal momento che l'url è indispensabile se sullo stesso server vengono ospitati più siti web (host virtuali).
Ma è veramente impossibile utilizzare i proxy HTTP senza queste limitazioni?
Direi proprio di no; esistono diversi tools che consentono di fare http tunneling. Il principio su cui si basano questi arnesi è veramente semplice. Si tratta di convertire tutto il traffico generato da un punto A in HTML e di dirigerlo verso un altro punto B passando attraverso il proxy. Nel punto B il traffico viene riportato allo stato originale ed instradato regolarmente.
Costruire un tunnel HTTP è relativamente semplice; basta avere un host oltre il proxy in grado di ricevere il traffico http e di smistarlo correttaemnte secondo le necessità.
Ci sono addirittura dei siti su Internet che offrono, più o meno gratuitamente, un tunnel HTTP anche per il traffico P2P.
Programmi dediti allo scopo ce ne sono veramente tanti, basta fare un giretto su Internet.
A volte però le ACL inibiscono pesantemente l'uso di questi software perchè con la scusa di voler restare anonimi, in realtà vengo utilizzati per navigare apertamente senza i limiti imposti dal proxy.
In questi casi non resta che costruire un sistema ad-hoc in grado di ricevere i pacchetti http da instradare. Questo vuol dire che è necessario disporre di almeno un host apero su Internet dotato di un IP pubblico.
Se invece la necessità si ferma all'invio e recezione di posta elettronica, esistono strumenti come html2pop3 che sono visti con meno astio da parte degli amministratori di sistema.
02 luglio 2007
22 maggio 2007
OpenVPN e 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:
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:
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 comandoipconfig /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:
La risposta dovrebbe essere simile a questa:
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:
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:
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:
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:
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.
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 consenrare 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:
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
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
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.
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.
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.
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
0x1 ........................... MS TCP Loopback interface
0x2 ...ff fd 4e 18 2f 07 ...... TAP-Win32 Adapter V8 - SecuRemote Miniport
0x10003 ...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.Elenco interfacce
0x1 ........................... MS TCP Loopback interface
0x2 ...ff fd 4e 18 2f 07 ...... TAP-Win32 Adapter V8 - SecuRemote Miniport
0x10003 ...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
===========================================================================
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 consenrare 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.
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
17 maggio 2007
Freeradius Wi-Fi and TLS on Fedora Core
If like me you are a fedora user and you have to deploy a WPA security in your WLAN you will find some useful information in the welldone article about freeradius called:Securing Your WLAN with WPA and FreeRADIUS.
The article does some useful exaples but uses a generic linux distribution so some changes must be done for fedora.
In particular when i made the CA for my machine, that CA simply didn't work for me. This because the article assumes that the "openssl.cnf" config file is well-formed.
By my experience you have to change the line:
x509_extensions = usr_cert
with:
x509_extensions = v3_ca
I don't know if other linux distros have a different value for the "x509_extensions" parameter.
As usual, if i'm wrong please, let me know.
EFMBE
I don't know if other linux distros have a different value for the "x509_extensions" parameter.
As usual, if i'm wrong please, let me know.
EFMBE
Iscriviti a:
Commenti (Atom)