OpenVPN – NTLM e quel proxy infame

Questo articolo è rivolto a coloro che hanno problemi a far dialogare OpenVPN con proxy che richiedono autenticazione NTLM.

Al momento della stesura di questo articolo, la versione di ovpn è la 2.1.3, versioni successive a questa potrebbero non soffrire dello stesso male.

Utilizzando l’autenticazione di tipo NTLM ho notato che la comunicazione si interrompe subito dopo l’invio del messaggio di tipo 1 da parte del client. In pratica il proxy non si degna di dare una risposta negativa o positiva che sia.

Per maggiori informazioni sulla comunicazione tipo NTLM potete visitare il sito:

http://davenport.sourceforge.net/ntlm.html

Dando uno sguardo al codice sorgente ho notato che la stringa inviata dal client al proxy è la seguente:

TlRMTVNTUAABAAAAAgIAAA==

ed è una costante definita nel file ntlm.c

Dopo aver portato a termine qualche prova con uno sniffer di rete mi sono accorto che altri prorammi come ad esempio firefox, funzionano perfettamente con il proxy così mi sono chiesto quali fossero le differenze. In effetti il messaggio di fase 1 inviato dal browser è sostanzialmente diverso:

TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==

e sembra essere più gradito.

A questo punto ho modificato il codice sorgente nell’unica riga necessaria:

const char *
ntlm_phase_1 (const struct http_proxy_info *p, struct gc_arena *gc)
{
  struct buffer out = alloc_buf_gc (96, gc);
  /* try a minimal NTLM handshake
   *
   * http://davenport.sourceforge.net/ntlm.html
   *
   * This message contains only the NTLMSSP signature,
   * the NTLM message type,
   * and the minimal set of flags (Negotiate NTLM and Negotiate OEM).
   *
   */
  // buf_printf (&out, "%s", "TlRMTVNTUAABAAAAAgIAAA==");
   buf_printf (&out, "%s", "TlRMTVNTUAABAAAAB4IIogAAAAAAAAAAAAAAAAAAAAAFASgKAAAADw==");
  return (BSTR (&out));
}

e dopo aver ricompilato l’eseguibile, tutto funziona correttamente.

Alla prossima.

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