Archivi tag: ping

PMTUD e TCP MSS

Topologia di massima

Due filiali interconnesse mediante un tunnel GRE/IPSEC instaurato sfruttando le rispettive linee ADSL. In particolare, sul sito A sono presenti diversi client che hanno necessità di “dialogare” con un server Web posto nel sito B.

Problema

I client accedono al server Web remoto con estrema lentezza e molte delle richieste effettuate vanno in timeout. Nella fattispecie, trattasi di un problema legato alla MTU (Maximum Transmission Unit) configurata sulle interfacce dei router delle 2 filiali, che provoca la suddetta sintomatologia.

Un po’ di teoria

Ma cos’è l’MTU? Essa, molto semplicemente, definisce la dimensione massima (in byte) di un pacchetto (o di un frame) che può attraversare una determinata interfaccia di rete. Ad esempio, nel caso del protocollo IP (layer 3) parliamo generalmente di 1500 byte, mentre nel caso del protocollo Ethernet (layer 2) la MTU è pari a 1526 byte (1500 byte “ereditati” dal protocollo IP + 22 byte di instestazione Ethernet e 4 byte di CRC). Quest’ultima è sicuramente la più rognosa, in quanto molto spesso gli switch sono unmanaged e quindi non è possibile accorgersi immediatamente dei cosiddetti frame giant, che vegnono quindi scartati “silenziosamente” provocando una comunicazione “a singhiozzo” (vedi questo post per ulteriori dettagli).

Per quanto riguarda invece la MTU IP, si avranno sicuramente dei problemi nel caso in cui:

1) i valori configurati sulle interfacce del router A e del router B differiscono tra di loro (in gergo parliamo di MTU mismatch);

2) lungo il cammino tra router A e il router B esiste un segmento la cui MTU è inferiore rispetto a quella configurata sui 2 router.

Nel primo caso possiamo correre ai ripari molto velocemente, configurando un valore di MTU identico sulle interfacce dei router delle 2 filiali. Ad esempio, possiamo definire la MTU di una data interfaccia utilizzando il comando:

Router(config-if)# ip mtu <valore in byte>

Nel secondo caso, invece, occorre fare un po’ di diagnostica ed eventualmente utilizzare delle configurazioni ad hoc.

In entrambi i casi i pacchetti che superano la MTU più bassa verranno “frammentati” e ricostruiti in fase di ricezione. Ovviamente tale operazione, oltre a causare un overhead sui router coinvolti, provocherà dei seri problemi a livello 4 (TCP) e superiori, inficiando in modo notevole l’accesso al servizio da parte degli utenti.

PMTUD

Per evitare quindi che si verifichi un’eccessiva frammentazione è stato messo a punto un meccanismo tale per cui un router riuscirà ad accorgersi automaticamente della presenza di un valore di MTU inferiore rispetto a quello configurato sulla propria interfaccia, riducendo di conseguenza la dimensione dei pacchetti che intende inoltrare. Tale meccanismo prende il nome di Path MTU Discovery, abbreviato in PMTUD. Più in dettaglio, essa si basa sull’invio/ricezione di messaggi ICMP unreachable type 3 code 4 ( vedi qui per ulteriori dettagli): se la MTU dei pacchetti ricevuti da un router supera la dimensione massima definita sulla propria interfaccia in ricezione, esso procederà con l’inoltro del suddetto messaggio verso il router mittente. In tal modo, quest’ultimo si accorgerà di quanto sta avvenendo e ridurrà di conseguenza la MTU in modo da riuscire ad “attraversare” il router interessato.

PMTUDOra, occorre precisare che non è tutto oro ciò che luccica, nel senso che molto spesso i pacchetti ICMP unreachable vengono disabilitati sia in TX che in RX (in questo caso si parla di PMTUD blackhole). Ad esempio, nel caso dei dispositivi di casa Cisco, essi sono disabilitati di default:

Router#sh ip int dia0 | i ICMP
  ICMP redirects are never sent
  ICMP unreachables are never sent
  ICMP mask replies are never sent

Il perchè di tale configurazione è presto detto: per loro stessa natura, i messaggi ICMP consentono di ottenere informazioni “sensibili” sulla rete target e possono anche essere utilizzati per generare attacchi di tipo DoS/DDoS. Infatti, se un utente malevolo facesse in modo di “sollecitare” la generazione dei messaggi ICMP unreachable da parte del router oggetto dell’attacco, riuscirebbe certamente a sovraccaricarlo, poichè la generazione del suddetto tipo di messagistica avviene a livello di CPU. Come workaround è comunque possibile settare un rate limit specifico, ad esempio:

Router(config)# ip icmp rate-limit unreachable df 500

dove 500 rappresenta il numero di millisecondi che deve intercorrere tra la generazione di un messaggio ICMP unreachable e quello successivo.

A titolo di cronaca, per abilitare i suddetti messaggi su una data interfaccia è sufficiente digitare il comando:

Router(config-if)# ip unreachable

Identificare il valore di MTU corretto: metodo trial and error

Occorre precisare che esiste un modo empirico per determinare la dimensione della MTU più piccola presente lungo il percorso tra il router A ed il router B. Esso si basa sull’utilizzo del comando ping dotato delle flag -f (che imposta a 1 il bit do not fragment nell’header IP) e -l (che imposta la dimensione del solo payload). Se ad esempio la MTU configurata sulla scheda di rete del nostro PC (con Windows 7 a bordo) fosse pari a 1500 byte, potremmo utilizzare il comando:

C:\Users\pippo> ping 192.168.1.1 -f -l 1472

dove 1472 è il massimo payload definibile senza che vi sia frammentazione, poichè ad esso verranno sommati i 20 byte di intestazione IP e gli 8 byte di instestazione ICMP (per un totale di 1500 byte). Utilizzando un payload di 1473 byte, la nostra scheda ci indicherà che abbiamo superato la MTU attraverso il seguente output:

C:\Users\pippo>ping 192.168.1.1 -l 1473 -f

Esecuzione di Ping 192.168.1.1 con 1473 byte di dati:
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.
E' necessario frammentare il pacchetto ma DF è attivo.

Tale metodo può essere utilizzato per identificare la MTU di interesse, abbassando di volta in volta la dimensione del payload fino a quando al posto del suddetto messaggio verranno visualizzati dei semplici ICMP echo reply.

Una piccola nota a margine: nel caso in cui si volesse utilizzare questa metodologia direttamente dalla CLI del router Cisco, è possibile utilizzare il seguente comando:

ping 192.168.1.1 source fa0/0 df-bit size 1500

dove 1500, in questo caso, rappresenta la dimensione totale del messaggio ICMP echo request (e non del solo payload come avveniva nel caso di Windows 7).

TCP MSS

L’acronimo MSS sta per Maximum Segment Size e rappresenta la dimensione massima (in byte) che può avere il payload (e solo il payload) di un segmento TCP. Il valore di default è 1460, ovvero 1500 byte di MTU meno i 20 byte di instestazione TCP ed i 20 byte di intestazione IP. Nel caso in cui la MTU più piccola relativa al percorso tra A a B fosse inferiore a quella di default, è possibile “forzare” il valore di MSS (in gergo parliamo di MSS clamping). Ad esempio, per i router Cisco potremo utilizzare il comando:

Router(config-if)# ip tcp adjust-mss <byte>

dove i byte da utilizzare sono dati dalla MTU più piccola meno 40 byte.

Un caso pratico (e molto diffuso tra gli end user) in cui l’MSS clamping torna davvero utile riguarda il protocollo PPPoE, che usa una MTU pari a 1492 byte (a differenza del PPPoA la cui MTU è quella classica, ovvero 1500 byte). In tal caso si può procedere con questa configurazione sull’interfaccia dia0:

Router(config-if)# ip mtu 1492
Router(config-if)# ip tcp adjust-mss 1452

Spero di aver fatto un minimo di chiarezza sul concetto di MTU e su quanto esso sia importante nell’ambito della comunicazione client/server basata sul protocollo TCP e superiori.

Alla prossima.

Gli IP Plan non aggiornati

In un ambiente enterprise mantenere un IP plan aggiornato è un’operazione alquanto ardua (soprattutto se coloro che devono gestire l’infrastruttura IT sono dislocati su sedi diverse).

 

networking.jpg

Quello che mi è capitato di recente mi ha fatto capire quanto un IP plan attendibile possa essere importante. Nello specifico, dopo aver installato e configurato un nuovo server, ho richiesto un indirizzo IP privato da poter assegnare alla suddetta macchina, senza creare eventuali conflitti con gli altri apparati già in produzione.

La prima cosa che ho fatto è stata quella di consultare l’IP Plan, scegliendo un indirizzo libero. Successivamente ho comunicato l’indirizzo in questione al sistemista network, il quale mi ha confermato la disponibilità dello stesso.

Per scrupolo ho effettuato un ping, il quale non ha fornito alcuna risposta, ergo tutti gli indizi mi lasciavano pensare che l’indirizzo scelto fosse effettivamente disponibile.

Fast forward di 30 minuti: una volta patchata la porta del server ed attestata sulla porta dello switch appartenente alla VLAN di riferimento, ho iniziato a ricevere degli ICMP echo reply a singhiozzo.

Tentando di connettermi via RDP alla suddetta macchina, con mio enorme stupore, ho notato che l’hostname del server su cui ero atterrato era differente da quello da me configurato, ergo vi era già una macchina che utilizzava l’indirizzo IP che credevo libero.

Nuovo giro di telefonate, altri check al volo e finalmente sono riuscito ad individuare un indirizzo IP effettivamente disponibile.

Contromisure

Per non incappare in una simile problematica è necessario aggiungere altri check al semplice ping ed alla consultazione dell’IP plan. Infatti, alcuni SO, quali Windows Server 2008 R2, hanno il firewall embedded configurato in modo da droppare le richieste ICMP. Quindi, per sincerarsi dell’effettiva disponibilità di un indirizzo, occorre dapprima consultare l’arp table dello switch su cui sono attestati i server della farm (generalmente trattasi di un core switch). Tale check va fatto a server disconnesso e partendo dal presupposto che non vi siano degli switch intermedi.

Per i Cisco, il comando da lanciare è il seguente:

Switch# sh arp | i <indirizzo IP>

Se l’arp table non restituisce alcun risultato significa che l’indirizzo IP scelto è libero. Ovviamente, se il server è stato disconnesso immediatamente prima di effettuare il suddetto controllo, è necessario aspettare che scada il cosiddetto aging time delle entry relative alla arp table (che varia in base alla tipologia ed al vendor dello switch, sempre che i valori impostati siano quelli di default).

Successivamente, a server connesso, si potrebbe individuare il MAC address della sua scheda di rete e controllare se l’associazione IP-MAC presente nella tabella ARP contiene il suddetto indirizzo fisico.

Infine, controllando le entry della CAM, ci si può sincerare che il MAC individuato sia stato letto sulla porta dello switch sul quale il server è effettivamente attestato.

Per i Cisco il comando da utilizzare è questo:

Switch# sh mac-address-table | i <indirizzo MAC>

Da notare che il MAC dovrà essere digitato nella forma aaaa.bbbb.cccc

In alternativa a tale procedura (che richiede comunque una certa familiarità con il networking), si potrebbe utilizzare un port scanner, ad esempio nmap.

Esiste anche una versione per Windows, scaricabile da qui, ed il comando da lanciare è il seguente:

nmap -P0 <indirizzo IP>

In particolare, con la flag -P0 sto imponendo al software di non lanciare dei ping preliminari per testare l’effettiva raggiungibilità dell’IP (evitando quindi i falsi negativi), procedendo immediatamente con la scansione delle porte.

State tranquilli, il port scan non è reato se non è seguito da dei tentativi di accesso non autorizzati (verificate comunque le policy aziendali prima di lanciarlo).

E’ tutto. Alla prossima.

Solaris 10 ed il ping bacato

Qualche giorno fa sono praticamente impazzito nel cercare di individuare un problema che credevo fosse sulla rete. In particolare, una macchina specifica (con addosso Solaris 10) che doveva occuparsi di controllare l’effettiva raggiungibilità di determinati network element (mediante dei semplici ping), ad intervalli di tempo pseudorandomici inviava al default gateway dei frame Ethernet con MAC sorgente 00:00:00:00:00:00.

sol10logo.png

A questo punto, il default gateway memorizzava il suddetto MAC address all’interno della propria tabella ARP e l’unico modo per far ripartire i check consisteva nell’eliminare manualmente tale entry. A cancellazione avvenuta tutto tornava a funzionare correttamente, salvo poi reincartarsi nuovamente.

La soluzione più semplice sarebbe stata quella di inserire una entry statica all’interno della tabella ARP relativa al default gateway, che però si è rivelata inpraticabile dato che il SO di tale macchina non permetteva l’aggiunta della suddetta entry. Quindi il problema andava ricercato all’origine, ovvero sulla macchina Solaris.

Mi armo di pazienza e di sniffer (aka snoop) ed inizio ad analizzare il traffico ICMP. Dopo un po’ di tempo mi accorgo che il ping si incartava nel momento in cui provava a testare la raggiungibilità di due IP ben precisi (mentre funzionava con tutti gli altri).

Controllo la configurazione di rete e mi accorgo che sono presenti delle ACL (posizionate vicino alla destinazione) che bloccano i suddetti ping, provocando (molto probabilmente) un dump dell’applicativo. Tale dump porterà successivamente all’invio di frame con il MAC address anomalo riportato in precedenza.

Poichè stentavo a credere che una macchina robusta come Solaris 10 potesse essere afflitta da un bug di simile fattezza ed entità ho deciso di documentarmi un po’ e di effettuare qualche ricerca su Internet, che mi ha portato su questo link:

http://wesunsolve.net/bugid/id/1219682

Per la serie non considerare mai come impossibile un evento poco probabile.

Alla prossima.

Script bash per verificare la raggiungibilità dei Domain Controller

Supponiamo che nella vostra rete venga utilizzato Squid come proxy, sul quale è stata abilitata l’autenticazione NTLM. In questo modo, mediante Active Direcetory ed ai Domain Controller di casa Microsoft, sarà possibile fare in modo che, in base ai gruppi di appartenenza, i vari utenti della LAN possano visualizzare soltanto alcune tipologie di siti.

Però, occorre precisare che Squid, di per sè, non è in grado di gestire alcun tipo di content filtering, ma per fare ciò è necessario utilizzare alcuni add-on, quali DansGuardian o squidGuard.

Saranno proprio questi ultimi, mediante delle query ldap dirette al Domain Controller, a suddividere l’utenza in base ai siti che può visitare.

Nel caso in cui il primo Domain Controller di riferimento non sia più raggiungibile, si potrebbe operare direttamente sul file hosts, posizionato nella directory /etc, in modo da modificare il contenuto della entry relativa all’hostname del DC (ad esempio ldap.vostrodominio.org), associandolo all’indirizzo IP dell’altro Domain Controller.


bash.jpg

 

 

Il seguente scrip serve proprio a mettere in pratica quanto appena detto:

#!/bin/bash

DC1=192.168.1.1

DC2=192.168.1.2

destinatario=<vostroindirizzo>@<vistrodominio.org>

logfile=/var/log/ping.log

count_1=0

count_2=0

tmp=/var/log/tmp.log

var=`cat $tmp`

while [ $count_1 -lt 2 ]

do

echo "Pinging DC1..."

if ping -c 1 $DC1

then

if grep -q "$DC2" "/etc/hosts"

then

/bin/sed -i 's/192.168.1.2/192.168.1.1/g' /etc/hosts

echo "0" > $tmp

exit 0

else

exit 0

fi

else

let count_1=count_1+1

if [ $count_1 -eq 1 ]

then

echo "$(date) Primary Domain Controller Unreachable, trying again..." >> $logfile

else

echo "$(date) Primary Domain Controller Unreachable, trying to switch over DC2..." >> $logfile

if [ "$var" = "0" ]

then

echo "$(date) Primary Domain Controller Unreachable, trying to switch over DC2." | mail -iv -s "Alert: DC1 unreachable" $destinatario;

echo "1" > $tmp

fi

fi

fi
done

if [ $count_1 -eq 2 ]

then

while [ $count_2 -lt 2 ]

do

echo "Pinging DC2..."

if ping -c 1 $DC2

then

/bin/sed -i 's/192.168.1.1/192.168.1.2/g' /etc/hosts

exit 0

else

let count_2=count_2+1

if [ $count_2 -eq 1 ]

then

echo "$(date) Secondary Domain Controller Unreachable, trying again..." >> $logfile

else

echo "$(date) Unable To Contact Any Domain Controller" >> $logfile

if [ "$var" = "1" ]

then

echo "$(date) Unable To Contact Any Domain Controller." | mail -iv -s "Alert: DC1 and DC2 unreachable" $destinatario;

echo "2" > $tmp

fi

fi

fi

done

fi

exit 0

Rendiamo eseguibile lo scrip appena creato:

nightfly@nightbox:~$ sudo chmod +x ping.sh

Creiamo infine una entry per crontab, schedulando l’esecuzione di tale scrip ogni minuto:

* * * * *   root     ping.sh > /dev/null 2>&1

Ovviamente, nel caso in cui abbiate bisogno di alcuni chiarimenti sul codice, non esitate a contattarmi.

A presto.