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