Ritorno sulle impostazioni e parametri delle connessioni ADSL Telecom di tipo business per puntualizzare alcune cose.

I parametri della linea sono: VPI e VCI rispettivamente 8 e 35, encapsulation LLC, QoS UBR, protocollo RFC1483 routed. Per questo tipo di linea vengono forniti in genere almeno quattro IP fissi, ed il foglio che lascia l’omino Telecom contiene due classi di indirizzi chiamati IP LAN e IP punto-punto (o IP WAN).

Se avete un router di proprietà, ecco come impostarlo.

Intanto fatevi un’idea di come sono fatte le classi di indirizzi; nessuno fa i conti a mano, utilizzate l’ottimo Online IP calculator.

Facciamo un esempio pratico(*): sul foglio, spesso scritto a mano con pessima calligrafia e fotocopiato da una Xerox degli anni ‘50, ci sono:

IP LAN: 78.62.124.200 / 255.255.255.248. Il tool ci dice che abbiamo a disposizione una classe da 8 indirizzi (78.62.124.200 - 78.62.124.207), di cui possiamo utilizzarne 6, poiché il primo (.200) identifica la rete e l’ultimo (.207) il broadcast.

Punto-punto: 84.81.188.200 / 255.255.255.252    Stessa cosa: ma solo 4 indirizzi (84.81.188.200 - 84.81.188.203 ) con 2 utilizzabili.

A questo punto impostiamo IPoA (IP over ATM) e mettiamo nell’indirizzo IP della connessione (lato WAN) 84.81.188.202, subnet 255.255.255.252 e gateway 84.81.188.201. Questo perché il gateway di Telecom è sempre il primo indirizzo disponibile.

Nell’indirizzo LAN del router va inserito uno degli IP pubblici forniti. Scegliamo il primo, 78.62.124.201 con subnet 255.255.255.248. Questa configurazione è routing “puro”, e il NAT andrà disabilitato poiché nei modelli più semplici di router non è possibile assegnare due IP all’interfaccia LAN, oltretutto NATtandone uno solo; per questo siete praticamente obbligati ad installare un firewall con WAN 78.62.124.202, subnet 255.255.255.248 e gateway 78.62.124.201 (l’interfaccia LAN del router). IP LAN e NAT andranno configurati in conseguenza della classe di indirizzi privati che utilizzate nella vostra rete locale.

Naturalmente nessuno di Telecom vi dirà nulla di tutto questo, lo dovrete scoprire da soli.

(*) gli indirizzi sono assolutamente inventati.

Nota veloce su Wireshark: per filtrare la visualizzazione dei pacchetti che contengono l’indirizzo IP 192.168.0.1 si usa l’espressione:

ip.addr==192.168.0.1

per filtrare i pacchetti che non lo contengono, saresti tentato di usare:

ip.addr!=192.168.0.1

che però non funziona: l’espressione sarà comunque vera per pacchetti dove la sorgente o la destinazione sono uguali a 192.168.0.1, perché sarà comunque diverso rispettivamente l’IP destinazione o sorgente. L’espressione viene letta come: “i pacchetti che contengono un campo ip.addr con un valore diverso da 192.168.0.1″; dato che i campi sono due, sorgente e destinazione, e almeno uno dei due è diverso da 192.168.0.1, il filtro non si comporta come penseresti.

Per escludere tutti i pacchetti da e per l’host 192.168.0.1 devi usare la seguente espressione:

!(ip.addr == 192.168.0.1)

che viene letta come “mostrami tutti i pacchetti per i quali è falso che almeno uno dei due campi indirizzo sia uguale a 192.168.0.1″

A volte leggere la guida in linea serve. Buone sniffate.

Iperf è uno strumento per misurare l’ampiezza di banda su TCP, abbastanza flessibile, open source e disponibile per diversi sistemi operativi.

Ecco le caratteristiche:

• TCP
  • Measure bandwidth
  • Report MSS/MTU size and observed read sizes.
  • Support for TCP window size via socket buffers.
  • Multi-threaded if pthreads or Win32 threads are available. Client and server can have multiple simultaneous connections.
• UDP
  • Client can create UDP streams of specified bandwidth.
  • Measure packet loss
  • Measure delay jitter
  • Multicast capable
  • Multi-threaded if pthreads are available. Client and server can have multiple simultaneous connections. (This doesn’t work in Windows.)
• Where appropriate, options can be specified with K (kilo-) and M (mega-) suffices. So 128K instead of 131072 bytes.
• Can run for specified time, rather than a set amount of data to transfer.
• Picks the best units for the size of data being reported.
• Server handles multiple connections, rather than quitting after a single test.
• Print periodic, intermediate bandwidth, jitter, and loss reports at specified intervals.
• Run the server as a daemon.
• Run the server as a Windows NT Service
• Use representative streams to test out how link layer compression affects your achievable bandwidth.
• A library of useful functions and C++ classes.

Permette di controllare l’effetto della variazione di diversi parametri tipo la TCP windows size o l’MTU, supporta IPV6 e ha diverse opzioni per girare come demone o servizio.

Senza scendere in usi troppo esoterici è utile per controllare la banda a disposizione tra due siti connessi via WAN e/o VPN. L’uso più semplice è lanciare

iperf -s

sull’host “server” e

iperf -c IP_HOST_SERVER

sul client, e dopo qualche secondo apparirà il responso. La porta di default su cui deve poter essere raggiunto il server è la 5001/TCP. Ripetere in senso inverso per valutare le performance nei due sensi della connessione. (Vi ricordo che la “A” di ADSL sta per “Asymmetric”).

Dopo la teoria, facciamo una prova pratica sull’MTU, visto che l’unico strumento che serve è il comando ping.
Per comodità mia utilizzo il terminale di un server Ubuntu, ma si può utilizzare tranquillamente il prompt dei comandi di Windows, sebbene con sintassi diversa.
Anzitutto controlliamo il valore dell’MTU della scheda di rete(*):

root@ginger:~$ ifconfig eth0 | grep MTU

         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

Ok, è 1500 per default. (Per Windows possiamo utilizzare l’utility gratuita DrTCP.)

Controlliamo che un host esterno risponda al ping:
root@ginger:~# ping www.google.com -c3
PING www.l.google.com (216.239.59.147) 56(84) bytes of data.
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=1 ttl=243 time=48.5 ms
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=2 ttl=243 time=47.1 ms
64 bytes from gv-in-f147.google.com (216.239.59.147): icmp_seq=3 ttl=243 time=50.2 ms
--- www.l.google.com ping statistics ---

3 packets transmitted, 3 received, 0% packet loss, time 2004msrtt min/avg/max/mdev = 47.140/48.647/50.295/1.304 ms

Il ping funziona tramite ICMP, che vi ricordo essere un “…protocollo di servizio che si preoccupa di trasmettere informazioni riguardanti malfunzionamenti, informazioni di controllo o messaggi tra i vari componenti di una rete di calcolatori.”

Come si può vedere, per impostazione predefinita il comando ping manda un pacchetto di 56 byte, a cui vanno aggiunti 20 byte di intestazione IP e 8 byte relativi al messaggio ICMP_REQUEST; infatti il manuale del comando ping (man ping) riporta: “ICMP PACKET DETAILS - An IP header without options is 20 bytes. An ICMP ECHO_REQUEST packet contains an additional 8 bytes worth of ICMP header followed by an arbitrary amount of data. When a packetsize is given, this indicated the size of this extra piece of data (the default is 56). Thus the amount of data received inside of an IP packet of type ICMP ECHO_REPLY will always be 8 bytes more than the requested data space (the ICMP header).”
Quindi ping ci informa che sta mandando fuori un pacchetto di 56+28=84 byte.

Adesso proviamo a pingare con pacchetti appena sopra l’MTU della scheda, cioè 1501 byte. Facciamo due calcoli: 1501 meno 28 (tra intestazione IP e messaggio ICMP) = 1473 byte:

root@ginger:~# ping www.google.com -c3 -s1473
PING www.l.google.com (216.239.59.99) 1473(1501) bytes of data.

--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2006ms

Adesso si comincia a vedere qualcosa di interessante: il pacchetto è troppo grosso e quindi evidentemente non esce dalla scheda di rete, che avendo MTU a 1500 non riesce a “sparare” pacchetti da 1501 byte.

Proviamo all’esatto valore di MTU, quindi 1500-28=1472:

root@ginger:~# ping www.google.com -c3 -s1472
PING www.l.google.com (216.239.59.99) 1472(1500) bytes of data.
From 192.168.254.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2006ms

Sempre meglio: adesso il pacchetto è uscito, ma l’host 192.168.254.1, che è il mio router, mi comunica che la sua interfaccia è impostata con un MTU di 1492 byte e non può frammentare i pacchetti (DF set), quindi il pacchetto viene droppato ed il ping non funziona. Proviamo a impostare il flag DF sull’interfaccia locale e vediamo che succede:

root@ginger:~# ping www.google.com -c3 -s1472 -M do
PING www.l.google.com (216.239.59.147) 1472(1500) bytes of data.
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)
From ginger (192.168.254.2) icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.l.google.com ping statistics ---
0 packets transmitted, 0 received, +3 errors

Come ci si aspettava, adesso è l’host locale (ginger - 192.168.254.2) che risponde lamentandosi che per far uscire il pacchetto avrebbe bisogno di frammentarlo, ma il flag DF è settato quindi non se ne fa nulla. Ma adesso sappiamo che l’MTU è settato a 1492 byte, quindi 1492-28=1464

root@ginger:~# ping www.google.com -c3 -s1464
PING www.l.google.com (216.239.59.104) 1464(1492) bytes of data.
64 bytes from 216.239.59.104: icmp_seq=1 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=2 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=3 ttl=243 (truncated)

--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms

Fatto, il pacchetto passa, e passa anche con il flag DF settato localmente:

root@ginger:~# ping www.google.com -c3 -s1464 -M do
PING www.l.google.com (216.239.59.104) 1464(1492) bytes of data.
64 bytes from 216.239.59.104: icmp_seq=1 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=2 ttl=243 (truncated)
64 bytes from 216.239.59.104: icmp_seq=3 ttl=243 (truncated)

--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2001ms
rtt min/avg/max/mdev = 68.888/69.473/70.187/0.618 ms

Come controprova, aumentiamo di 1 byte:

root@ginger:~# ping www.google.com -c3 -s1465
PING www.l.google.com (216.239.59.99) 1465(1493) bytes of data.
From 192.168.254.1 icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.l.google.com ping statistics ---
3 packets transmitted, 0 received, +1 errors, 100% packet loss, time 2006ms

Come volevasi dimostrare. Abbiamo scoperto che l’MTU path della connessione è 1492. Ed infatti sul mio router:

Con Windows è meno immediato, poichè non restituisce tutti i messaggi ICMP, quindi il valore dell’MTU path va trovato per tentativi.

In realtà questi esercizi non sono che una diagnostica grossolana, specie in ambienti complessi con molti salti e architetture complicate, ma uniti ad un po’ di pazienza, uno sniffer e un po’ di fortuna permettono di risolvere problemi apparentemente complicatissimi. Inoltre non sottovalutate il fatto che potete fare parecchio “cinema” con queste manovre.

(*)vale anche per l’interfaccia verso un modem ADSL

Tutte le comunicazioni basate su TCP/IP implicano il passaggio di pacchetti che vengono confezionati dagli host partendo dai dati creati dai programmi applicativi e aggiungendo strati su strati durante la discesa del pacchetto verso il livello fisico. Il processo viene descritto tramite il modello a strati del TCP/IP, di cui avevo esposto le linee generali qui.

L’ultimo strato che un pacchetto raggiunge prima di uscire da un host è il network layer, gestito direttamente dall’interfaccia di rete. Mentre gli strati più alti sono sostanzialmente indipendenti dall’hardware e dipendono dal sistema operativo e dalle applicazioni, lo strato della rete è per forza di cose legato all’hardware e al mezzo di trasmissione che utilizza l’host per comunicare, sia esso una rete ethernet, una connessione ADSL PPoE, o un piccione.

La voce italiana di Wikipedia è sufficientemente esaustiva per gli scopi di questo post:

“Maximum Transmission Unit (MTU) indica le dimensioni massime in byte di un pacchetto dati che può essere inviato attraverso un protocollo di comunicazione. Tale parametro è di solito associato alle interfacce di comunicazione quali schede di rete o porte seriali. Se un router deve trasmettere un pacchetto su una interfaccia che ha un MTU inferiore alla dimensione del pacchetto, il protocollo Internet effettua automaticamente la frammentazione, ovvero divide il pacchetto in due o più pacchetti più piccoli. I frammenti del pacchetto originale sono contrassegnati, così il protocollo IP di destinazione è in grado di riassemblare i pacchetti nell’originale. Un qualsiasi router lungo il cammino potrebbe dover frammentare un pacchetto, e l’host di destinazione dovrà ricostruire il pacchetto originale dai frammenti. … La frammentazione consente a IP di lavorare correttamente su una rete composta di collegamenti con MTU eterogenea, ma è una operazione onerosa per i router e per l’host che riceve i pacchetti frammentati, quindi si cerca di evitarla quando possibile.”

In soldoni: nel caso di una rete ethernet, ad esempio, l’MTU è 1500 byte, ed è la dimensione massima di un “pezzo” coerente di dati che l’interfaccia riesce a immettere sul cavo di rete.

Ciascun tipo di inferfaccia ha il proprio MTU, quindi ne consegue che lungo il cammino che separa due host il valore massimo dell’MTU prima di frammentare un pacchetto, sarà quello dell’interfaccia con MTU più basso. Mi spiego meglio con un esempio: se in una strada che separa due città ci sono tre gallerie che permettono rispettivamente il passaggio di mezzi alti 4, 3 e 5 metri, il carico più alto che posso portare su un camion prima di doverlo dividere, misura 3 metri di altezza. Questo valore massimo è detto MTU path, e se tutte le interfacce coinvolte nel trasferimento dei dati contengono la dimensione dei loro pacchetti sotto questa soglia, si evita la frammentazione. La determinazione di questo valore (MTU path discovery) avviene per mezzo di messaggi ICMP; purtroppo, per limitare gli attacchi di tipo DoS, alcuni router bloccano il traffico ICMP.

“L’RFC 1191 descrive l’MTU path discovery, una tecnica per determinare il cammino MTU tra due host, così che quella frammentazione possa essere evitata. Un host invia pacchetti IP di dimensioni che aumentano gradualmente, con il bit DF (Don’t Fragment — Non Frammentare) settato a “1″. Se un router lungo il cammino ha bisogno di frammentare il pacchetto, ma esso ha il bit DF settato a “1″, il router lo abbandona, e manda un pacchetto ICMP di tipo “datagramma troppo grosso” all’indirizzo sorgente per segnalare il problema. L’host sorgente in questo modo “impara” il più grosso MTU che può passare attraverso quel cammino senza frammentarsi.”

L’MTU è un valore chiave nel tuning della velocità della rete, ma va maneggiato con attenzione: pacchetti grandi aumentano l’efficenza poiché l’overhead diminuisce, ma interfacce non particolarmente veloci potrebbero avere problemi con MTU elevati. Wikipedia inglese fa l’esempio di un pacchetto ethernet con un normale MTU a 1500 byte, il quale impiega circa un secondo (!) a passare per una interfaccia modem a 14,4k.

L’MTU è spesso fonte di problemi in reti complesse e host con parecchie interfacce; non è semplicissimo diagnosticare questi problemi e spesso si procede per via empirica, anche perché l’MTU non è la prima cosa a cui si pensa. Connessioni lente, a “strappi”, velocità non omogenee per diversi applicativi, connessioni che si instaurano con difficoltà a ricevere i dati di ritorno, sono tutti sintomi di un valore MTU non adeguato. Per controllare e modificare l’MTU in ambiente Windows si può usare l’utility gratuita DrTCP , semplicissima da usare: basta selezionare un’interfaccia di rete e impostare l’MTU desierato, ricordandosi di riavviare il computer. (Segnatevi il valore che modificate per ripristinare le cose in caso di malfunzionamenti ancora peggiori.) In Linux si usa il solito ifconfig, ed eventulmente il file /etc/networks/interfaces.

In un prossimo post un esercizio pratico: un MTU discovery fatto “a mano”.

E’ già da un po’ di tempo che non mi imbatto più nei famigerati router “disco volante” forniti da Telekoma; ultimamente l’offerta che va per la maggiore è Alice Business, che prevede la fornitura di un altro tipo di apparato: Alice Gate 2 Plus.

Si tratta di un router ADSL dotato di due porte ethernet, una porta USB ed una porta RJ-11 per la linea telefonica. L’indirizzo IP di default dell’interfaccia LAN è 192.168.1.1, DHCP e NAT sono abilitati. Una caratteristica degna di nota è il fatto che il router si configura automagicamente una volta connesso alla linea telefonica. Dopo un paio di minuti dalla prima accensione l’apparato si resetta e il collegamento ad internet funziona perfettamente. Anche se può far storcere il naso a qualcuno, per uno studio professionale o una piccola azienda mi sembra una mossa azzeccata: non si è più costretti a mendicare dall’installatore un foglio scarabocchiato a mano con gli indirizzi IP ed i parametri di configurazione, spesso sbagliati.

Quelli incontrati finora hanno funzionato tutti molto bene fin da subito, e sembrano sufficientemente stabili. L’interfaccia di gestione è minimale e permette di modificare l’indirizzo IP LAN e i parametri del demone DHCP, ma soprattutto di configurare molto facilmente il NATP, cioè il port forwarding, sia per TCP che per UDP.

L’utilizzo di un firewall da installare tra il router e la propria rete è sempre consigliabile, e l’operazione è agevole perché finalmente è possibile impostare un default virtual server a cui inoltrare tutto il traffico in ingresso (la WAN del firewall).

L’unica cosa che mi lascia perplesso è l’assenza di autenticazione: per modificare le configurazione non viene richiesta alcuna password, e ciò non è affatto un bene. E’ consigliabile, pertanto, restringere l’accesso HTTP alla LAN del router tramite opportune regole sul firewall, in modo che la gestione possa essere effettuata solo dagli host decisi dall’amministratore di rete.

Update. A scanso di equivoci: della versione dotata di WiFi non parlo perché non ho avuto occasione di provarla. Il post si riferisce solo ed esclusivamente alla versione “base”, senza Aladino VoIP.

Le esigenze di connessione tra le sedi remote di un’azienda e l’aumento costante del lavoro in mobilità sono cresciute di pari passo con la qualità e la velocità dei collegamenti a banda larga. La conseguenza logica dei questo scenario è l’utilizzo sempre più capillare dei collegamenti VPN. Questo acronimo significa: Virtual Private Network, rete privata virtuale. Generalizzando: l’utilizzo di infrastrutture “pubbliche” fuori dal proprio controllo (e gestione) per implementare un collegamento sicuro tra le diverse sedi di una azienda o tra un “road warrior” e la propria sede.

La trattazione tecnica dell’argomento è vasta e complessa, le voci di Wikipedia inglese ed italiana offrono estese spiegazioni e parecchi link di approfondimento. Cercherò qui di dare un quadro generale sulle VPN, con i concetti fondamentali e un accenno ai più comuni metodi di implementazione.

Una VPN permette di collegare in modo sicuro i due estremi della connessione tramite una rete non dedicata, tipicamente utilizzando internet, abbattendo i costi delle linee CDN, che un tempo erano l’unica opzione. Tutto ciò porta diversi benefici: i principali sono:

• Economicità: si abbatte il costo delle infrastrutture. La scelta dell’implementazione adeguata in fase di progetto permette di scegliere la soluzione più adeguata al miglior costo sostenibile.
• Semplicità: la tecnologia è molto matura e non richiede skill esoterici.
• Sicurezza: si basa su standard perlopiù aperti e universalmente riconosciuti come sicuri. Con pochi accorgimenti si riescono ad ottenere buoni compromessi tra semplicità di accesso e ragionevole sicurezza.

Il concetto è abbastanza semplice, e adotta il paradigma “hub and spoke“: una sede centrale dalla quale si dipanano i collegamenti verso le sedi remote. (E’ evidente come il modello “mesh” non sia sostenibile nel caso particolare delle VPN). Utilizzando regole opportune si può decidere che ciascuna sede remota acceda esclusivamente al nodo centrale, oppure di abilitare anche il traffico tra le periferie. Nel caso particolare del collegamento tra due sole sedi, il modello è semplificato.

Le soluzioni che si possono adottare sono molteplici e vanno dal semplice server equipaggiato con software open source, a costose appliance ridondate in HA: la scelta dipende dai costi, dall’integrazione con le infrastrutture esistenti, dalla banda necessaria, dal carico di lavoro e dalla criticità del collegamento, tanto per citare alcuni fattori che condizionano la scelta del sistema a cui affidarsi.

In alcuni casi la realizzazione di una VPN site-to-site può essere delegata interamente al fornitore di connettività. E’ una scelta fatta prevalentemente da aziende piccole e medie, spesso senza un reparto IT. In Italia ho incontrato prevalentemente soluzioni di Telecom, che usa le capacità VPN dei router Cisco (credo, correggetemi nei commenti), e di Fastweb, che implementa reti MPLS sulla propria infrastruttura in fibra.

Ci sono molti motivi per utilizzare una VPN, uno dei più comuni è l’accesso remoto ad applicazioni non adatte ad essere pubblicate nativamente. Ad esempio: condivisione di file e applicativi verticali, magari su piattaforme proprietarie. I candidati ideali per l’accesso VPN sono le risorse prive di strumenti nativi per garantire la sicurezza al di là del perimetro aziendale. A seconda del livello di protezione richiesto, sarà cura del sistemista perimetrale decidere, quando possibile, se le risorse vadano posizionate in DMZ oppure se l’accesso debba avvenire direttamente in LAN.

L’implementazione non è esente da problemi: spesso il traffico VPN è sensibile ai router che ne trattano i pacchetti con troppa disinvoltura, oppure va incontro a difficoltà dovute all’impostazione dell’MTU. LA diagnostica non è per nulla agevole: i messaggi syslog sono difficili da interpretare e spesso mostrano solo l’effetto ma non la causa. Per fortuna i casi complicati sono una frazione del totale: molto spesso l’installazione non presenta particolari problemi.

Nel caso di una connessione site-to-site oppure hub and spoke, non è necessario toccare gli host della rete locale, è sufficiente assicurarsi che le sedi distinte abbiano piani di indirizzamento che non si sovrappongano, per evitare problemi di routing e complicate manovre di subnetting. (Fatevi un grosso favore: reti diverse, sempre). La VPN è realizzata tramite software oppure appliance che dialogano con la loro controparte remota, rappresentando l’endpoint della VPN, cioè il luogo in cui i pacchetti in ingresso vengono decrittati ed instradati in chiaro verso l’host di destinazione, ed i pacchetti in uscita vengono criptati, incapsulati ed inviati al gateway remoto.

Nelle implementazioni più semplici, l’endpoint di una VPN è lo stesso firewall che controlla il traffico da e per l’esterno; se invece le due entità non coincidono si renderà necessaria la definizione di una rotta statica sul default gateway, in modo da instradare correttamente il traffico.

Nel caso di utenti mobili o uffici piccolissimi (uno o due host), si utilizza una componente client che connette il nodo direttamente alla rete remota. Generalmente si tratta di software proprietari forniti dai produttori di appliance, che creano una scheda di rete virtuale sulla quale far viaggiare il traffico VPN. In questi casi entrano in gioco meccanismi di ARP proxying e non più di routing. Nella maggior parte dei casi si potrebbero utilizzare gli strumenti nativi che i diversi sistemi operativi mettono a disposizione, ma l’operazione si rivela talmente complicata (almeno nel caso di Windows) che l’uso di questi driver virtuali è universalmente diffuso. In realtà per l’accesso a risorse limitate da parte di pochi client, si potrebbe prendere in considerazione un tunnel SSH, di implementazione ancora più semplice.

Io utilizzo OpenVPN da parecchio tempo e mi trovo molto bene. Non richiede risorse particolari e mi permette di accedere a tutta la mia rete pubblicando una sola porta TCP e senza disporre di un IP pubblico statico.

In linea di principio le diverse appliance sono interoperabili, ma spesso con qualche difficoltà. Scegliendo unità simili molto spesso ci si deve limitare a compilare una o due finestre con gli stessi dati in posizioni complementari.

Per utenti che devono poter lavorare da computer pubblici, chioschi e computer condivisi, le soluzioni basate su SSL-VPN offrono la comodità di poter accedere alla rete remota tramite un browser e un po’ di componenti java, e presentano il vantaggio di funzionare in ambienti fortemente controllati: è sufficiente che passi il traffico SSL su https (TCP/443). Lo svantaggio è la minore integrazione con il sistema e la necessità di dover comunque installare un componente “invasivo” qualora si volesse accedere in modo completo alla rete.

In definitiva le VPN offrono una quantità di vantaggi che le rendono sicuramente interessanti; in cambio è necessaria un po’ di cura nel progetto e un po’ di attenzione alla gestione della sicurezza: i meccanismi di one time password, i token, il controllo attento degli accessi e della gestione degli account (RADIUS), sono alcuni dei metodi da adottare per garantirsi sonni (abbastanza) tranquilli.

Il caso tipico è quello di una rete che usa un router per uscire su internet ed uno per una connessione VPN verso una sede remota. Ne avevo parlato anche qui. Per semplificare le cose in quel post assumo che sia il default gateway a inoltrare il traffico verso l’altro router, in realtà tutto il meccanismo viene gestito tramite messaggi ICMP.

Come l’acronimo lascia intendere (Internet Control Message Protocol), questo protocollo non viene utilizzato per trasmettere dati, anzi non viene proprio impiegato dalle applicazioni (tranne ping e traceroute, ma sono comunque diagnostiche), bensì per trasmettere errori e segnali di controllo per il traffico TCP.

Tornando al caso in questione, sul router che rappresenta il default gateway c’è una static route che reindirizza il traffico destinato alla rete della sede remota verso il router che gestisce la VPN. In realtà il router invia un messaggio ICMP Redirect che induce gli host ad aggiornare la loro tabella di routing per indirizzare il traffico al gateway corretto.

Come prescrive la RFC 1122(*), i messaggi ICMP Redirect sono di pertinenza dei gateway e non devono mai essere inviati dagli host. Inoltre, tutti gli host sono tenuti a onorare tali messaggi utilizzando a tale scopo una “route cache” dinamica. Il primo pacchetto viene inoltrato direttamente dal default gateway al router “secondario” e nel contempo viene inviato all’host origine un ICMP Redirect, che aggiorna la route cache e fa sì che da quel momento in poi il traffico interessato transiti direttamente per il secondo router.

Tutto molto bello, pratico e funzionante. Tranne che per gli IBM AS/400. Malgrado la RFC sia categorica (“A host receiving a Redirect message MUST update its routing information accordingly.”), lo stack TCP/IP degli AS/400 non obbedisce ai messaggi ICMP Redirect e gli ignora bellamente. Nel caso in oggetto quindi, oltre alla rotta statica sul default gateway, che fa funzionare gli host “obbedienti” senza doverli neppure toccare, è necessario inserire una entry direttamente nella tabella di routing dell”AS, altrimenti i pacchetti di ritorno agli host della sede remota non giungerebbero a destinazione.

(*) …che è interessantissima e spiega un fottìo di cose su come funzionano le comunicazioni tra gli host di una rete.

Affrontiamo una annosa qestione: il Nat e la regola di loopback. Anche se non sapete cos’è, molto probabilmente vi ha causato problemi se accedete ad internet tramite un router.

La regola di loopback è la risposta ad una delle domande più frequenti, quando si parla di NAT e inoltro delle porte TCP: “Il mio indirizzo privato è 192.168.1.0, quello pubblico 85.38.119.122 (invento). Ho una webradio/voglio controllare il PC via UltraVNC/ho un webserver in casa ecc ecc: se utilizzo l’IP privato funziona tutto, se provo con l’IP pubblico non funziona. Perché?”.

La risposta breve è: “Sul tuo router/firewall manca la regola di loopback”.

Il funzionamento del NAT è illustrato nel post linkato qui sopra; in breve possiamo dire che serve per far “uscire” su internet tutta la vostra rete locale con un unico IP pubblico, e si occupa anche del corretto inoltro delle porte. Finché un pacchetto destinato all’IP pubblico arriva dall’esterno non ci sono problemi: si trova dalla parte “giusta” dell’interfaccia e le regole fanno il loro lavoro, inoltrando il traffico all’host locale designato per ascoltare su quella particolare porta. Quando il pacchetto viene generato dall’interno, esso arriva al router che in mancanza della regola di loopback può comportarsi in due modi diversi (dipende dal firmware):

• Decide che il pacchetto è spoofato, e lo scarta senza tanti complimenti.
• Oppure lo inoltra alla sua WAN, battezzata con l’IP pubblico per definizione. Se sulla particolare porta è in ascolto un demone, esso risponde, altrimenti la connessione va in timeout.

In entrambi i casi non abbiamo ottenuto il risultato sperato: anche se nel secondo caso otteniamo una risposta, essa arriva da un server che non è quello che ci interessava.

Per poter raggiungere dall’interno un server locale (pubblicato) tramite il suo IP pubblico (nattato), serve una regola di loopback fatta in questo modo:

Spiega:

• IP Source: è l’IP dal quale proviene la richiesta, tipicamente si tratta dell’host che stiamo utilizzando per interrogare il server. Il suo indirizzo locale (come tutti quelli della Local subnet) viene sostituito con l’IP pubblico (WAN IP).
• IP Destination: è l’IP pubblico sul quale sappiamo essere in ascolto il nostro server. Lo sappiamo perché esiste una regola di NAT “normale” che fa esattamente questo. L’IP pubblico viene sostituito con l’IP privato, quindi il pacchetto non esce dalla LAN.
• Service: in casi più sofisticati si può decidere di tradurre anche la porta TCP su cui ascolta il server, ma questa sezione è meno usata.

Alcuni firewall più sofisticati hanno un ulteriore campo che permette di specificare le porte fisiche inbound e outbound. E’ utile nei casi in cui si disponga di più sottoreti attestate su diverse interfacce.

Naturalmente la regola viene applicata solo nel caso in cui IP Source, IP Destination e Service siano quelli indicati nei campi Original della tabella. Per ciascuna singola regola di NAT “diretto” è necessaria una corrispondente regola di loopback.

Non ho mai trovato un router/firewall di classe SOHO (casa e piccoli uffici), che supportasse esplicitamente la regola di loopback: il mio Netgear DG834 è sufficentemente furbo da creare automagicamente la regola ogni volta che si pubblica un server, quindi non è necessario alcun intervento manuale di configurazione. Altri dispositivi, ad esempio gli ZyXel, aggiungono la regola solo se essa viene abilitata tramite un comando da impartire dalla interfaccia a riga di comando (CLI).
La maggior parte dei router casalinghi, purtroppo, non supporta in alcun modo la regola di loopback. In questo caso dovremo rassegnarci ad interrogare il server solo tramite il suo IP locale.

Da Wikipedia: “Una LAN virtuale, comunemente detta VLAN, è un gruppo di host che comunicano tra di loro come se fossero collegati allo stesso cablaggio, a prescindere dalla loro posizione fisica. una VLAN ha le stesse caratteristiche di una LAN fisica, ma consente di raggruppare le workstation come se fossero attestate sullo stesso segmento di rete. Invece di spostare gli host, la configurazione della rete si fa tramite strumenti software.”

Uno dei termini impiegati per definire una LAN, è “dominio di broadcast”(*): un segmento della rete all’interno del quale diversi host di uno stesso subnet comunicano tra di loro senza dover “passare” da un router, appartenendo alla stessa VLAN.

L’utilizzo delle VLAN porta diversi benefici, tra i quali:

• Facilità di gestione delle infrastrutture di rete: invece di spostare cavi, riposizionare uplink, aggiungere dispositivi e ricablare intere zone, si gestiscono le VLAN tramite strumenti software.
• Ottimizzazione dell’uso delle infrastrutture: se desidero isolare una subnet non devo aggiungere uno switch e/o un router, ma mi sarà sufficiente riassegnare alcune porte.
• Forte scalabilità: in pochi minuti si riassegna una porta e si sposta una patch, e le VLAN si possono estendere su diversi switch, rendendo semplice e relativamente economica l’espansione della rete.
• Possibilità di estensione oltre i limiti fisici di un singolo switch: oltre alla scalabilità, c’è il vantaggio di poter estendere una LAN su (ad esempio) piani diversi, utilizzando una unica dorsale di collegamento.
• Economicità: con uno switch livello 3, si può fare routing tra le VLAN.
• Diminuzione del traffico di rete: tramite VLAN si confina facilmente il broadcast.

L’assegnazione di un host ad una VLAN può seguire diversi criteri, tra cui: MAC address, indirizzo IP e porta dello switch; la maggior parte degli switch moderni con un adeguato numero di porte sono in grado di gestire le VLAN.

Le VLAN riguardano il livello 2, mentre le subnet interessano il livello 3, ma molto spesso ad una VLAN corrisponde una sola sottorete, completando il metodo di assegnazione basato sulla porta dello switch, che è il modello sicuramente più diffuso.

Se lo switch gestisce il livello 3, le VLAN possono comunicare tra di loro tramite routing, senza dover introdurre un elevato numero di router sulla rete.

Facciamo un esempio pratico: su uno switch a 48 porte, si potrebbero assegnare le porte da 1 a 30 per la VLAN principale, con i client ed i server di dominio, da 31 a 35 una VLAN per le stampanti, su una subnet diversa e routing da e verso la LAN, sulle porte restanti si potrebbe attestare una VLAN completamente separata per ospitare una rete di test che non si vuole condividere con il resto delle attività. A questo punto è semplicissimo riassegnare le porte e/o gli host, semplicemente riconfigurando lo switch e spostando un cavo. Alcune porte potrebbero essere usate per isolare (con una blanda sicurezza) il traffico WiFi da quello cablato.

Le VLAN possono estendersi al di là dei limiti fisici dei singoli switch, tramite il VLAN tagging. Il protocollo 802.1Q, che regola le VLAN, prevede che ciascun frame ethernet venga “etichettato” con le informazioni relative alla VLAN di appartenenza. In questo modo, host lontani fisicamente possono appartenere alla stessa VLAN: è sufficiente che gli switch interessati al trasporto dei frame siano collegati tra di loro (tramite “trunk”, un collegamento in grado di trasportare diverse VLAN) con porte opportunamente “taggate”.

La gestione della VLAN, nei casi più semplici si effettua collegandosi con un browser all’indirizzo IP dello switch, oppure via seriale direttamente connessi alla porta console del dispositivo.

E’ buona norma non utilizzare le VLAN per isolare le diverse zone della rete, ad esempio per ospitare una DMZ, perché il traffico tra le VLAN è spoofabile. E’ sempre meglio affidarsi ad un firewall per isolare le zone tra le quali la sicurezza del traffico è un fattore critico.

(*) Prima della diffusione capillare degli switch si usava “dominio di collisione”. Dato che uno switch per definizione elimina le collisioni, l’attenzione si è spostata sul traffico broadcast.

(La trattazione è semplificata in alcuni aspetti, ma l’argomento è abbastanza vasto ed è facilissimo trovare materiale di approfondimento.)

In questi giorni ho giocato ancora un po’ con OpenVPN; in particolare cercavo un modo veloce, efficiente e sicuro per connettermi alla rete di casa quando sono fuori.

Ingredienti:
Un server Debian di modestissime prestazioni che funge da gateway VPN (con poche modifiche a questa procedura va bene qualunque server).
Un client con qualunque sistema operativo(*).

Preparazione del server:

• Verificare l’esistenza di /dev/net/tun, se non esistesse va creato con mkdir /dev/net && mknod /dev/net/tun c 10 200, caricato con modprobe tun, va impostato il suo caricamento all’avvio: echo "tun" >>/etc/modules, e va abilitato il forwarding: echo 1 > /proc/sys/net/ipv4/ip_forward
• Installare OpenVPN sul server: apt-get update && apt-get install openvpn
• Generare una chiave simmetrica con il comando: openvpn --genkey --secret nome_chiave.key
• Creare il file di configurazione /etc/openvpn/server.conf con un contenuto simile a questo:

dev tap
proto tcp-server
lport 5000
ifconfig 10.0.0.1 255.255.255.0
secret /etc/openvpn/nome_chiave.key
verb 3

Ecco la spiega:
dev tap: non toccare
proto tcp-server: usiamo il TCP; OpenVPN va di default su UDP, che a volte è problematico nelle connessioni casalinghe, e non rutti i router sono in grado di gestirne il NATP
lport 5000: in particolare usiamo la 5000/TCP (potete usare la porta che preferite)
ifconfig 10.0.0.1 255.255.255.0: IP e subnet dell’adattatore virtuale: deve essere di una sottorete diversa dalla rete di casa e del client (inventatelo; non va impostato da nessuna altra parte).
secret /etc/openvpn/nome_chiave.key: la chiave simmetrica
verb 3: il livello di logging; 3 va bene quando funge tutto, potete alzare fino a 9 per avere più informazioni nel caso incontraste problemi.

A questo punto manca una cosa: se il vostro server è anche il default gateway della rete locale di casa, dovete creare le regole del firewall in modo da accettare le connessioni in ingresso:
iptables -A INPUT -p tcp –dport 5000 -s 10.0.0.0/24 -m state –state NEW,ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -s 10.0.0.0/24 -j ACCEPT
iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT
Se invece vi affidate ad un firewall diverso, dovrete creare le regole su quest’ultimo ed inoltre dovrete creare una route statica che permetta al traffico in uscita dalla rete locale e destinato al tunnel VPN di essere instradato correttamente. Una cosa così:
route add 10.0.0.2 255.255.255.0 192.168.1.2 dove 10.0.0.2 è l’IP che assegneremo all’interfaccia virtuale del client (vedi dopo), e 192.168.1.2 è l’IP (reale e privato) del server VPN.

Preparazione del client:

• Installare OpenVPN
• Copiare sul client (con un mezzo sicuro!) la chiave generata sul server, e metterla nella cartella di configurazione di OpenVPN.
• Creare il file di configurazione, la cui posizione dipende dal sistema operativo:

remote server.dnsalias.net
dev tap
proto tcp-client
rport 5000
ifconfig 10.0.0.2 255.255.255.0
route 192.168.1.0 255.255.255.0 10.0.0.1
secret nome_chiave.key
verb 3

Ecco la spiega:
remote server.dnsalias.net: l’indirizzo del server; potete usare l’IP oppure il nome FQDN. Se non avete un IP statico potete utilizzare dynDNS, come in questo caso.
dev tap: non toccare
proto tcp-client: usiamo il TCP perché bla bla bla (vedi sopra)
rport 5000: la porta su cui ascolta il server
ifconfig 10.0.0.2 255.255.255.0: l’IP dell’adattatore virtuale; inventatelo, della stessa sottorete di quello del server, non va impostato da nessuna altra parte.
route 192.168.1.0 255.255.255.0 10.0.0.1: la rotta statica che permette di raggiungere tutti gli host della rete remota
secret nome_chiave.key: la chiave simmetrica
verb 3: logging a livello 3 (vedi sopra).

Adesso sul server lanciamo: openvpn --config /etc/openvpn/server.conf e sul client il corrispondente: openvpn --config client.conf (o come avete chiamato il file).
Se tutto va a buon fine, dopo qualche istante vedrete apparire sul server:
Peer Connection Initiated with xxx.yyy.zzz.kkk:nnn
Initialization Sequence Completed
e sul client:
TCP connection established with zzz.ttt.vvv.rrr:5000
TCPv4_CLIENT link local: [undef]
TCPv4_CLIENT link remote: zzz.ttt.vvv.rrr:5000
Peer Connection Initiated with zzz.ttt.vvv.rrr:5000
TEST ROUTES: 1/1 succeeded len=1 ret=1 a=0 u/d=up
route ADD 192.168.1.0 MASK 255.255.255.0 10.0.0.1
Route addition via IPAPI succeeded
Initialization Sequence Completed

La connessione VPN tra il client e la rete remota è stabilita, avete accesso alla rete di casa come se foste fisicamente collegati ad essa.

(*)Il client per Mac OS/X è qui.
Ho trovato una buona guida per tutto il processo su Debianizzati.org. Tra l’altro viene anche spiegato come demonizzare e lanciare al boot il server OpenVPN; inoltre vengono descritti altri metodi di autenticazione oltre alla shared-key che usiamo qui.

I più smaliziati potranno utilizzare OpenVPN anche dietro ad un proxy: Fede, che ne sa, ci spiega.

Può capitare per diverse ragioni, di dover spostare il servizio DHCP da un server ad un altro (Microsoft). Se la configurazione non ha reservation, oppure ne ha un numero trascurabile, il consiglio è di copiare a mano le impostazioni, fermare e disabilitare il servizio sul vecchio server, e autorizzarlo sul nuovo. Tempo impiegato: 5 minuti.

Se il database, invece, ha molte reservation, copiarsele tutte a mano con il rischio di sbagliare un MAC address, non è molto divertente.
In questo caso quello che state cercando si trova nell’articolo KB325473.