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.

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”.

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.