Giorgio (GrG) Bonfiglio
Cloud Evangelist, Systems/Network Engineer
Giornate storiche. Che qualcuno vorrebbe dimenticare.
01 month ago
“There cannot be mental atrophy in any person who continues to observe, to remember what he observes, and to seek answers for his unceasing hows and whys about things.” – A. Bell
Fermatevi un secondo. Chiudete gli occhi. Mettetevi per un attimo nei panni di Joel Stanley Engel. Corre l’anno 1973, siete a capo dei Bell Laboratories. Immaginate. Nel curriculum vantate parecchi successi, tra i quali la collaborazione alla progettazione dei sistemi di guida della navicella Apollo.
Sono passati quasi cento anni dalla prima telefonata della storia (era il 1876 quando Alexander Graham Bell disse al suo assistente le prime parole attraverso un telefono: “Mr. Watson — Come here — I want to see you.”) e vi state occupando di un colossale progetto: costruire un telefono senza fili, per liberarlo da quel cavo che lo rende così “statico”, così fisso, così poco pratico.
Non esistono ancora nemmeno i cordless, ma voi puntate molto più in alto, volete diventi possibile raggiungere qualunque persona, in ogni angolo di ogni città. Volete dare la possibilità di telefonare da qualunque punto della casa, dalla strada, da ogni luogo pubblico, usando un dispositivo personale: intendete rivoluzionare il concetto di telefonia, volete un numero di telefono che non identifichi più un luogo specifico, ma che si riferisca ad una persona. Una persona, ovunque essa sia.
Sono più di 130 anni che è possibile comunicare a lunga distanza, prima con il telegrafo e poi con il telefono, ma il limite è ancora quello: serve un cavo. I due terminali devono essere “fisicamente” collegati. Non esiste mobilità. Il compito è complesso, le sfide sono tante, troppe. I precedenti tentativi, come il telefono veicolare, non hanno avuto il successo sperato. Manca la tecnologia per costruire un terminale leggero, manca una rete a cui appoggiarsi, ma l’interesse è grande, gli investimenti effettuati sono importanti, e l’attenzione dei media è massima.
3 Aprile, un giorno come un altro. Vi svegliate e andate in ufficio per svolgere le vostre ordinarie mansioni. In un remoto angolino della vostra testa state pensando a quella conferenza che il vostro principale concorrente, Motorola, ha indetto per quello stesso giorno all’Hotel Hilton di New York, per presentare chissà quale nuova scoperta. “Sarà solo un altro piccolo passo in avanti”, pensate.
Poi vi squilla il telefono. Rispondete. Una voce: “Hi, Joel, it’s Marty, Marty Cooper. You remember me.”. Si, si, ve lo ricordate, capite subito chi stia parlando: è quel Marty Cooper che, alle dipendenze di John Mitchell, sta lavorando per Motorola ad un progetto simile a quello a cui dedicate le vostre giornate. La voce, poi, continua: “And I’m calling you from a cell phone, but a real cell phone, a personal, hand-held portable cell phone.”. Il cuore vi va a mille. Non riuscite più a parlare.
(Marty Cooper, nel 2007, con il prototipo DynaTAC originale. credits)
La persona dall’altro lato si ricorderà quel vostro silenzio per tutta la vita.
Non era uno scherzo. In quel 3 Aprile 1973, da una strada di Manhattan, tra gli occhi increduli dei passanti, Marty Cooper ha effettuato la prima telefonata della storia da un terminale mobile. Ha chiamato il suo concorrente, Joel Engel, per fargli sapere che aveva perso la sfida: non era riuscito ad arrivare primo.
La strada era ancora molto lunga e tortuosa. Quella telefonata era partita da un prototipo DynaTAC (Dynamic Adaptive Total Area Coverage): pesava 1200 grammi, era lungo 25 centimetri e la sua batteria gli garantiva un’autonomia, in telefonata, di 20 minuti. Dopo i quali doveva stare sotto carica per 10 ore. Cooper ribadì più volte scherzosamente che l’autonomia non era un problema, perchè quel telefono era così scomodo che nessuno avrebbe potuto tenerlo in mano per più di 20 minuti.
Ci vollero altri 10 anni per perfezionare la tecnologia e superare i vincoli normativi, ma nel 1983 vennero messi in commercio i primi telefoni cellulari. Era iniziata quella corsa che continua ancora oggi. Da quel momento, l’innovazione è stata continua, sempre più veloce.
Il resto della storia, lo conoscete.
Sysadmin SI NASCE.
53 months ago
Esiste un problema. Un problema che nel mio settore si fa ogni giorno più pressante. Si chiama “improvvisazione”. Noi definiamo “improvvisato” quella persona che, dopo aver installato un server seguendo un howto e copiaincollando i comandi senza averli minimamente capiti, si sente, alla pari di ben più skillati sistemisti, pronta a gestire sistemi in produzione. E si lancia a farlo.
I (veri) professionisti si trovano ogni giorno a dover combattere attacchi di vario genere, dallo spam ai DDoS, e nel 99.9% dei casi si scopre che provengono da macchine, appunto, in mano a persone che non hanno praticamente nessuna esperienza nella gestione di sistemi.
Non l’ho raccontato qui per pietà nei confronti degli interessati, ma qualche tempo fa alcuni siti su un server che gestisco, tutti facenti capo alla stessa persona, sono stati defacciati. Dopo una approfondita analisi dei log, ho concluso che chi è entrato via FTP aveva la password (probabilmente recuperata con un keylogger). Avendo trovato IP italiani nei log del deface, ho contattato i proprietari di due di quelle macchine, diventate sicuramente parte di una botnet ed usate da terzi per commettere illeciti. Il primo, dopo una risposta iniziale particolarmente sgarbata, confermando di non essersi accorto del fatto che il suo server veniva usato da terze persone per defacciare siti, ha preso le misure necessarie. Il secondo, no. Mi ha minacciato, dicendo che mi avrebbe denunciato per diffamazione, perchè quello che stavo dicendo era sicuramente inventato, e che se il provider, al cui abuse avevo segnalato la questione, gli avesse bloccato il server, mi avrebbe chiesto i danni. Perchè io mi stavo inventando tutto.
Inutile dirlo, dopo avergli spiegato come connettersi via SSH e come lanciare il comando “last”, sono venuti fuori login (root) da ogni parte del mondo sulla sua macchina. Login di cui lui, ovviamente, non sapeva niente.
Non sapeva bene cosa fosse SSH, ma il server lo aveva installato. I servizi erano up, il sito web era correttamente funzionante. Perchè, questo? Perchè siamo nel 2013. Perchè esistono pannelli di controllo e howto. Pannelli di controllo come Plesk e cPanel, che svolgono egregiamente tutte le operazioni di configurazione iniziale e di gestione ordinaria di una macchina. Questo è il punto. Il sistemista improvvisato, non fa niente che già non si possa fare con dei semplici click in un pannello di controllo. Non fa niente che non si possa fare cercando una guida su internet e copiaincollando i comandi indicati.
Considero infatti gli howto alla pari dei pannelli di controllo “tuttofare”. Guide passo a passo, che portano anche la persona più incapace a configurare un determinato servizio. I sistemisti improvvisati esistono perchè esistono le guide step by step, e queste guide esistono perchè vendono, perchè fanno views, e le fanno perchè esistono gli improvvisati. Il nocciolo della questione è che la guida spiega come installare qualcosa e come effettuare configurazioni basilari. Ma non spiega come gestire. Non spiega come affrontare i casi eccezionali. Perchè questo, forse, non può essere insegnato.
Chi usa una guida pronta, delega a terzi (cioè a chi quella guida l’ha scritta) tutta la fase preliminare di ricerca, di documentazione e di assemblaggio di diverse fonti, nonchè il testing. Si tratta invece di una componente fondamentale del nostro lavoro. Perchè è così che impariamo a muoverci senza usare guide, è questo il modo in cui impariamo ad affrontare situazioni non ordinarie. È così, e solo così, che impariamo a camminare (anzi, a correre) nel buio.
Partiamo dal presupposto che tutto quello che può essere spiegato in termini semplici ed in modo sequenziale a degli incapaci, può anche essere eseguito da una macchina. Anni e anni di howto su come installare un ambiente LAMP. Poi arriva cPanel. Si inventa EasyApache. E da quel momento con un comando si può fare in 3 secondi tutto quello che con la guida si faceva in 3 ore. A copiare righe di codice, sono capaci tutti. Le macchine sono bravissime ad eseguire comandi in sequenza prestabilita. Sono le migliori: le abbiamo inventate inventate noi, e le abbiamo inventate per fare proprio questo.
Se ne deduce che una persona che gestisca macchine in questo modo, non ha senso di esistere. Se l’amministrazione di un sistema consistesse solo in queste semplici e sequenziali operazioni, le macchine stesse saprebbero autogestirsi. Anzi, lo fanno già: ci sono strutture che svolgono il 90% delle operazioni di routine senza supervisione umana.
Ma gestire server è molto, molto altro. Le situazioni ordinarie durano ben poco, e ci si trova spessissimo a dover gestire casistiche eccezionali, a dover svolgere operazioni impossibili da eseguire attraverso un pannello di controllo. A dover svolgere operazioni per le quali non si trova da nessuna parte una guida pronta all’uso, perchè magari prima di noi nessuno si è trovato incastrato nella situazione in cui noi invece ci troviamo. Interventi per cui serve una mente umana, un cervello. Un cervello che funzioni, non un cervello che sappia solo usare i comandi cut&paste.
Si, è vero, molte operazioni sono state automatizzate negli ultimi anni, prima le svolgeva un uomo e adesso le svolge una macchina. Ma, state attenti: sono stati automatizzati quei processi che già il sistemista svolgeva in modo “automatico”, comportandosi come una macchina. Solo quelli: tutto il resto non potrà mai essere automatizzato. Forse si, un giorno succederà. Ma non a breve/medio termine.
Alcuni sostengono che stia proprio in questo l’abilità innata dei sysadmin. Saper affrontare situazioni, saper gestire casistiche eccezionali, saper gestire (e risolvere) i problemi. Saper cercare soluzioni, conoscere e saper usare gli strumenti a disposizione. Avere la tendenza che ti porta ogni giorno, senza nessuna spinta, a trovare nuovi strumenti e a scoprire nuove cose. Le capacità tecniche si possono acquisire, il resto no: si imparano i comandi da utilizzare, ma non si impara il modo in cui affrontare le situazioni critiche. Ed è questo che conta, è questo a fare la differenza.
Spesso, infatti, quando consiglio ad un improvvisato di cambiare professione, non lo faccio perchè abbia dimostrato di non conoscere semplici comandi o di non sapere il significato di alcuni termini tecnici, ma perchè noto la mancanza di abilità e tendenze ben più importanti. A volte vengo ricoperto di domande, domande la cui risposta è contenuta nell’anteprima del primo risultato di ricerca su Google. Questo, a mio parere, è un chiaro segno. Se l’istinto ti porta a chiedere a qualcuno che già sa piuttosto che a cercare da solo una risposta, sarai un perfetto studente, un perfetto schiavo del metodo educativo moderno. Ma, tranquillo, non farai mai il sistemista. Non giriamoci intorno. È così.
C’è chi nasce particolarmente portato al gioco di squadra e fisicamente agile, e diventa calciatore. Ci sono ragazze che nascono particolarmente belle, fini e portate alla cura della persona, e diventano modelle. Non si capisce perchè si sia invece diffusa la convinzione che chiunque possa diventare sistemista. Non si capisce come mai chiunque voglia diventarlo, e come mai sia così difficile difendere la professionalità in un mestiere che sta diventando sempre più critico e importante.
Non vorreste mai volare su un aereo pilotato da una persona con in mano una guida step by step. Non vi fareste mai trapiantare il cuore da qualcuno che, forte di 20 anni di esperienza in macelleria e con l’aiuto di un video su Youtube, vi garantisce di saperlo fare. Perchè, per risparmiare qualche euro, date in mano i vostri siti, i vostri gestionali e i vostri strumenti di comunicazione a persone che non fanno niente di più di quanto già le macchine stesse non facciano?
E tu. Si, tu, sistemista improvvisato che stai leggendo. Fai un favore a tutti noi: lascia che le tue 40 ore di lavoro settimanali diventino 2 ore di un vero professionista, anche se queste sue due ore costeranno al cliente come le tue 40. Sarà meglio per tutti.
Per oggi ho finito.
Giorgio
#freeandopen – Sul futuro di Internet
05 months ago
Chiudete gli occhi, per un attimo. Pensate alle persone che hanno inventato quell’oscenità che è la Posta Elettronica Certificata. Pensate a quelle persone convinte che basti impedire la risoluzione DNS di un dominio per “censurare” un sito malevolo. Pensate a queste persone, completamente incompetenti in termini di internet e tecnologia, da noi elette e spedite al governo con il potere di legiferare, in Italia, anche per quanto riguarda la rete.
Mi seguite, vero? Bene. Adesso facciamo insieme un passo avanti. Immaginate che disastro succederebbe se queste persone si riunissero con tutti i loro simili delle altre nazioni del mondo, a porte chiuse, per decidere il futuro di Internet, davanti a un tavolo in cui chi ha progettato e sviluppa la rete, o anche chi la usa, non ha nessun diritto di voto.
Sarebbe un disastro, vero?
Ma è quello che sta per succedere. Dal 3 al 14 Dicembre l’International Telecommunication Union (cos’è?) si riunirà a Dubai nella “World Conference on International Telecommunications” (WCIT-12) allo scopo di ridiscutere i trattati che regolano le telecomunicazioni a livello internazionale (che risalgono ormai all’88).
Si discuterà di varie cose. Si va da questioni come la censura e il controllo delle informazioni presenti sulla rete, spinte da governi che vorrebbero poter controllare Internet come controllano gli altri tipi di media, a questioni “trite e ritrite” degli ultimi anni, portate da alcuni fornitori di accesso alla rete (come Telecom Italia), che vogliono a tutti i costi appropriarsi di una fetta dei guadagni dei cosidetti “Over The Top” (Google, Facebook, Youtube, etc), a costo di stravolgere i principi e meccanismi sui quali la rete si è basata negli ultimi 30 anni. Si parlerà quindi anche di Net Neutrality, di abbandono dei principi best-effort nella rete, di free-riding e concetti simili.
Il problema, fondamentalmente, è uno: l’ITU. La rete è un mondo collaborativo, dove ognuno “mette del suo”, e un l’imposizione di un controllo / regolamentazione dall’alto può solo rovinarlo. Molti credono quindi che l’ITU non sia il posto adatto per fare simili discussioni. Organi simili all’ITU ma più aperti, in cui tutti hanno diritto di partecipazione, esistono. Un esempio è l’Internet Governance Forum. Alle assemblee dell’IGF chiunque può partecipare e votare, e la trasparenza è assoluta.
Rischiamo di ritrovarci da un giorno all’altro con una rete più controllata, molto meno libera, nonchè di qualità inferiore, sia in termini di contenuti che in termini prestazionali. Non si tratta quindi di materia tecnica, ma di questioni che toccano chiunque utilizzi internet. Tutti noi. Dobbiamo difendere i principi di apertura, trasparenza e libertà che la Internet Society professa da 20 anni.
Come possiamo agire, quindi? Google non si è fermata a guardare. Ha avviato un movimento, denominato “Take Action“, allo scopo di aiutare le persone a capire di cosa si sta parlando e ad esprimersi (attraverso una specie di raccolta di firme) contro questo incontro a porte chiuse, chiedendo maggiore trasparenza. A capo di questa iniziativa c’è lo stesso Vinton Cerf, uno dei padri di internet, oggi “Chief Internet Evangelist” per Google stessa.
Hashtag ufficiale, #freeandopen (su Twitter e Google+).
Firmate, quindi, firmate e diffondete. Perchè, alla fine, la rete siamo noi, e siamo noi i primi a rimetterci.
Ehi, c’è il World IPv6 Launch!
211 months ago
Me ne stavo dimenticando: domani, 6 Giugno 2012 è il World IPv6 Launch.
Un anno fa, l’8 Giugno 2011, ci son state le “prove generali” dell’implementazione globale di IPv6 (RFC 2460). Quel giorno più di 1000 grandi siti web (Google, Facebook, Yahoo, Akamai, Limelight e altri) hanno attivato il supporto IPv6 sui servizi principali per 24 ore, nell’ambito di un grande test coordinato su scala mondiale, allo scopo di far saltar fuori bug e/o errori a livello di implementazione e dare a tutti i players il tempo di correggerli e di adeguarsi.
Il test è stato un grande successo, ed è stata fissata, per domani appunto, la data dell’adozione definitiva di questa tecnologia (ai tecnici fa un pò ridere il chiamare IPv6 “tecnologia”, perchè esiste da 14 anni). “The Future is Forever” è il motto dell’iniziativa: da domani, il futuro è per sempre. Centinaia di siti, ISP e produttori di hardware adotteranno definitivamente IPv6. La lista completa dei partecipanti è qui.
D’ora in poi sarà supportato, ovunque: sui più grandi siti, sui più grandi CDN, sui router casalinghi, dagli ISP (in tunnel, quantomeno). Il mercato farà il resto del lavoro: finalmente, chi non si è svegliato e non si è aggiornato, inizierà a rimanere indietro e a perder colpi (e soldi).
Da domani, magicamente, un server dedicato con supporto IPv6 avrà più valore di uno che non ce l’ha. Un hosting con supporto IPv6, avrà più valore di un prodotto simile, in tutto e per tutto, ma senza IPv6. Una ADSL con supporto IPv6 nativo probabilmente avrà più valore di una concorrente forse un pochino più veloce, ma senza IPv6. Spendereste poi 150 € per comprare un nuovo router ADSL IPv4-only sapendo di doverlo buttare via tra un anno?
IPv6 diventerà un must, ovunque. Chi offre IPv6 corre, gli altri partono già doppiati. Bisogna muoversi, fare in fretta, perchè il rischio è quello di trovarsi con non una ma due internet prima di fine anno. Due reti separate, una v4 e una v6, non completamente connesse tra loro. Non è un bello scenario, per niente.
Non vorrei ritrovarmi a dover spedire pacchetti IP usando i piccioni (RFC 1149, che ci crediate o meno).
Per verificare lo stato del supporto IPv6 del vostro dispositivo / connessione, c’è un simpatico e utile tool qui. Se state cercando un Tunnel Broker decente e semplice da usare, consiglio Gogo6. Se invece avete un sito web con supporto IPv6, potete registrarlo al Launch Day qui.
Due curiosità: lo sapevate che chi ha progettato IPv4 (attuale RFC 791, Settembre 1981) negli anni ’70 si era reso perfettamente conto dei problemi legati allo scarso numero di indirizzi disponibili? Il problema è stato ignorato, perchè si trattava di un test e non si pensava ad una diffusione su scala mondiale in breve tempo. Il PIL mondiale di quegli anni non sarebbe bastato a comprare (ehm, costruire/creare) i 2^32 dispositivi che avrebbero potuto esaurire il numero di indirizzi disponibili.
Questo “casino” è “colpa” di chi ha sfruttato e diffuso una tecnologia che i suoi stessi creatori non ritenevano pronta ad uno sfruttamento e diffusione su larga scala, non si tratta di errori di progettazione o solamente di naturale crescita, come molti credono.
E la seconda curiosità: solo il 70% dei siti registrati al World IPv6 Launch sono globalmente raggiungibili via IPv6. Carina come cosa. Io, ovviamente, sono pronto da un pezzo (ma mi ero dimenticato di registrare questo blog).
Google ha pubblicato delle pagine informative, che puntano a spiegare in modo semplice e chiaro. Interessante il video in cui uno dei “fathers of the Internet”, Vint Cerf, spiega il problema dell’esaurimento di indirizzi, con l’aiuto di immediata grafica. Da diffondere.
Correte, il conto alla rovescia è iniziato (e potete seguirlo anche su Twitter)!
Ps: Si, domani sarà anche un giorno importante, ma volete mettere con il mio compleanno, il 12 Giugno? Chi prepara il sito ed i badge?
Giorgio
RFC Ignorate: La fine del mondo inizia con Fastweb
51 year ago
Internet si basa su standard aperti, che vengono definiti attraverso discussioni “pubbliche” tra tecnici. Il meccanismo è semplice: per prima cosa, un gruppo di persone studia, disegna uno “standard”: decide che qualcosa debba essere fatto in un certo modo perchè pensa quella sia la soluzione migliore.
La seconda fase consiste nel pubblicare una RFC, Request for Comments, in modo che gli altri interessati possano leggerla e come il fantasioso nome suggerisce, commentarla. La proposta viene modificata per coprire le necessità di tutti e correggere eventuali errori e poi diventa “standard de facto”. Standard non imposti, che tutti rispettano perchè altrimenti sarebbe il caos più totale. E’ così che si va avanti da 30 anni, senza che mai il meccanismo abbia mostrato debolezze. E’ un pò lo stesso funzionamento dei semafori, niente impedisce a me di decidere che io passo quando è rosso e mi fermo quando è verde, ma non posso farlo perchè so che se anche uno solo si comportasse così tutto il sistema anrebbbe in panico.
Una importante Request for Comments, la RFC 1918, datata Febbraio ’96, ha stabilito che le classi di IP utilizzabili liberamente (senza richiederne l’assegnazione da parte dell’autorità) nelle reti private fossero:
192.168.0.0/16
172.16.0.0/12
10.0.0.0/8
Nell’Aprile 2012 a queste è stata aggiunta la classe 100.64.0.0/10, per i “Carrier Grade NAT” (RFC 6598).
Diverse entità, probabilmente allergiche agli standard, si sono appropriate di classi di IP senza averne titolo. A memoria, ricordo Fastweb, che usava (usa?) le classi 1.0.0.0/8, 2.0.0.0/8, 5.0.0.0/8 (and counting) per l’indirizzamento interno, H3G che ad oggi usa la 1.0.0.0/8, Hamachi e OpenVPN (nella versione a pagamento) che assegnano IP interni ai client dalla classe 5.0.0.0/8, Remobo, software simile ai precedenti che si è appropriato della classe 7.0.0.0/8 e così via.
L’ICANN, sapendo che queste classi erano di fatto utilizzate, pur non avendo intenzione di regolarizzarle (erano e sono utilizzate in modo assurdo, senza motivazione tecnica, sarebbe stato solo un enorme spreco di risorse) ha ritardato fino all’ultimo momento la loro assegnazione. Adesso però gli IP stanno finendo, e l’autorità per l’assegnazione è costretta ad utilizzarli.
Se un determinato ISP usa una classe in modo irregolare e questa viene assegnata, si ritroverà con un conflitto nel routing della sua rete interna: dovrebbe far “uscire” i pacchetti dalla sua rete per raggiungere il reale proprietario di quegli IP ma se lo facesse renderebbe irraggiungibili i suoi host interni che utilizzano (in modo, ci tengo a ricordarlo, illecito) tali indirizzi IP, creando disservizi. La questione è spiegata (anche) qui, in inglese.
A questo si aggiunge il problema del “Bogon Filtering“. Il bogon filtering è un semplice quanto effettivo metodo per filtrare pacchetti spoofed (attacchi, in altre parole): questa tecnica consiste nel filtrare direttamente alla frontiera della rete i pacchetti provenienti da IP non pubblici o da classi di IP non assegnate. Il motivo è chiaro: se gli IP che inviano quei pacchetti non sono stati assegnati a nessuno, la sorgente indicata non è quella reale e quindi si tratta di pacchetti “maligni” o di errori di configurazione. La logica conseguenza è che se una classe viene assegnata e l’ISP non aggiorna i suoi filtri continuerà a bloccarla credendola inutilizzata, rendendo ai suoi utenti impossibile raggiungere gli host remoti appartenenti a quella classe.
Alcuni ISP usano o hanno usato inoltre le classi non allocate per delle prove tecniche, annunciandole nelle tabelle di routing mondiali. Qualche annuncio “residuo”, al suo sovrapporsi con quelli nuovi e “leciti”, potrebbe quindi creare ulteriori conflitti nel routing delle nuove classi.
L’autorità per la registrazione si impegna a segnalare con adeguato anticipo le classi che stanno per essere assegnate, ma non tutti sembrano leggere queste pagine, come mostra questo grafico:
Si nota infatti che quasi il 10% degli AS mondiali non è in grado di raggiungere le classi indicate. Un grandissimo problema.
Temevo che qualcosa prima o poi sarebbe successo, e un messaggio di Marco questa notte me l’ha confermato: da rete Fastweb non si riescono a raggiungere IP della classe 5.0.0.0/8, assegnata in queste settimane a grossi ISP come Softlayer, Hetzner, OVH. Ne parlano qui, su HostingTalk.it. Leggendo poi questo topic su WebHostingTalk, scopro che il problema non è limitato a Fastweb, ma si verifica anche da altri ISP.
Ecco un traceroute da rete Fastweb verso un IP di Softlayer:
C:\Users\User>tracert 5.10.64.1 Traccia instradamento verso 5.10.64.1-static.reverse.softlayer.com [5.10.64.1] su un massimo di 30 punti di passaggio: 1 <1 ms <1 ms <1 ms 192.168.1.1 2 226 ms 17 ms 17 ms EDIT 3 17 ms 16 ms 17 ms EDIT 4 492 ms 35 ms 17 ms 10.251.149.201 5 122 ms 16 ms 16 ms 10.251.144.25 6 47 ms 112 ms 164 ms 10.251.145.1 7 537 ms 477 ms 250 ms 10.251.149.186 8 351 ms 17 ms 17 ms 10.3.136.189 9 41 ms 17 ms 20 ms 10.3.128.41 10 135 ms 16 ms 471 ms 10.254.9.230 11 69 ms 20 ms 21 ms 10.254.12.21 12 150 ms 20 ms 20 ms 10.254.12.6 13 125 ms 24 ms 417 ms 89.97.200.66 14 * * * Request timed out. 15 * * * Request timed out. C:\Users\User>
Carino. Ecco cosa succede quando un grande ISP non rispetta gli standard che dovrebbero essere la base del suo lavoro. Crea un danno sia ai suoi utenti, che non riescono a raggiungere una parte di internet, sia alle entità a cui sono stati assegnati gli IP che lui usa in modo illecito.
Cosa fare quindi se vi trovate in una situazione simile, cioè se non riuscite a raggiungere alcuni IP (e quindi server)? Sarebbe totalmente sbagliato e inutile contattare il proprietario di quel nodo (server), perchè non ne ha colpa nè ha modo di risolvere il problema. La soluzione è chiamare il call center di Fastweb, bombardarlo, intasarlo giorno e notte ripetendo la segnalazione, perchè è una loro mancanza: offrono un servizio incompleto e non rispettano le RFC. Si tratta, a tutti gli effetti di un disservizio, quindi non esitate e soprattutto non accettate risposte che non contengano una promessa di immediata risoluzione del problema.
La parte più bella sta nel fatto che l’autorità (ICANN/RIPE) ha la possibilità di revocare le assegnazioni fatte a LIR (provider) che utilizzano senza averne titolo classi assegnate ad altri, come Fastweb sta facendo in questo momento. Se le segnalazioni all’autorità diventassero consistenti, Fastweb potrebbe rimanere completamente in mutande, senza più nemmeno un IP per far uscire i suoi utenti su internet. Meglio. Più IP disponibili per chi rispetta le regole.
E se invece siete voi proprietari di un server non raggiungibile da alcuni ISP? Anche qui, deve esser chiaro che non avrebbe senso (e non sempre sarebbe fattibile) richiedere a chi ve lo ha assegnato un nuovo IP “pulito”, o ritenere il vostro provider responsabile del problema.
Segnalate a ICANN/RIPE (tramite questo form) la violazione, perchè, come dicevo poco fa, Fastweb potrebbe pagarla davvero molto cara. Contattate voi stessi Fastweb, sia attraverso i canali di supporto ufficiali sia attraverso i contatti tecnici (reperibili tramite il RIPE), e, per finire, chiedete ai vostri utenti che stanno subendo un disservizio di fare lo stesso, chiedete che riportino il problema e che pretendano sia risolto in tempo reale. E’ davvero importante muoversi, perchè Fastweb sta danneggiando tutti.
Non sono un avvocato, ma immagino che sia i clienti Fastweb tagliati fuori da internet sia i proprietari dei server irraggiungibili possano chiedere pesanti risarcimenti al provider. E chissà che non si muova anche il CODACONS, che farebbe una delle prime mosse giuste e tecnicamente sensate della sua vita.
I LIR / AS a cui fossero stati assegnati gli IP “sfortunati”, potrebbero poi “convincere” gli ISP che creano loro tali problemi di raggiungibilità in diversi modi, più o meno leciti ma tutti visti negli anni: bloccando i peering, rendendo le loro reti completamente inaccessibili dagli ISP incriminati, droppando pacchetti a destra e a manca, in modo che i clienti di questi ultimi, imbestialiti, aumentino la pressione.
Lo so, da tecnico non dovrei consigliare di “spammare” un call center e ripetere le segnalazioni, di solito non si fa così. Ma quando degli standard vengono violati tutto diventa lecito. “L’hai violato? Adesso assumi 250 persone per non far crollare il call center sotto le segnalazioni, e PEDALI, perchè non è così che si lavora.”.
Concedetemi un commento altamente tecnico nei confronti di Fastweb: “AHAHAHAHAHAHAHAHAHAHAHAHAH”.
Ricordatevi quindi: seppellite di segnalazioni chi ha sbagliato e chi vi sta veramente creando questo disservizio, non prendetevela con chi ha rispettato le regole e non ha nessuna colpa. Telefonate, telefonate e telefonate ancora, e quando siete stanchi fate chiamare anche i vostri parenti dalle altre stanze della casa. E il giorno dopo richiamateli, per chiedere aggiornamenti o anche solo per salutarli.
Se volete che il problema venga risolto, insomma, sostituite per i prossimi giorni il numero della vostra ragazza in rubrica con il numero del loro callcenter.
Concludo con un meritato #EPIC FAIL per Fastweb. Ovviamente non sono loro cliente. Non vorrei diventarlo neanche se mi pagassero loro stessi per usare i servizi che offrono. Però, ho ordinato ieri un server da Softlayer e rischio di ritrovarmi un IP appartenente alle classi di cui abbiamo parlato fino ad ora. Con le conseguenze di cui abbiamo parlato fino ad ora.
UPDATE: E’ quasi l’una di notte, del 19 Maggio, e ho appena visto il primo traceroute andare correttamente a destinazione da rete Fastweb. Tutti gli IP di test che avevo usato, Softlayer, OVH, Hetzner, vengono ora correttamente ruotati. Un traceroute in memoriam:
Traccia instradamento verso 5.10.64.1-static.reverse.softlayer.com [5.10.64.1]: 1 <1 ms <1 ms <1 ms 39.235.148.254 2 30 ms 49 ms 27 ms 10.128.96.1 3 49 ms 29 ms 29 ms 10.3.231.210 4 32 ms 32 ms 34 ms 10.251.143.209 5 30 ms 27 ms 28 ms 10.251.138.27 6 25 ms 27 ms 29 ms 10.251.139.1 7 32 ms 27 ms 29 ms 10.251.143.194 8 37 ms 32 ms 27 ms 10.3.134.241 9 32 ms 27 ms 28 ms 10.3.128.46 10 33 ms 28 ms 29 ms 10.254.11.69 11 36 ms 29 ms 35 ms 10.254.1.77 12 33 ms 95 ms 41 ms 89.97.200.62 13 28 ms 29 ms 38 ms 26.26.127.54 14 31 ms 37 ms 39 ms 93.55.241.54 15 37 ms 28 ms 29 ms 26.26.127.69 16 38 ms 39 ms 38 ms 93.57.68.21 17 30 ms 38 ms 39 ms 93.57.68.5 18 35 ms 36 ms 29 ms if-5-0-0.core1.RCT-Rome.as6453.net [195.219.163.9] 19 59 ms 58 ms 59 ms if-11-0-0-0.tcore1.PYE-Paris.as6453.net [80.231.154.41] 20 56 ms 59 ms 75 ms if-2-2.tcore1.PVU-Paris.as6453.net [80.231.154.17] 21 57 ms 63 ms 76 ms xe-6-3.r03.parsfr01.fr.bb.gin.ntt.net [129.250.8.177] 22 84 ms 58 ms 59 ms ae-1.r21.parsfr01.fr.bb.gin.ntt.net [129.250.2.224] 23 79 ms 62 ms 75 ms as-4.r22.amstnl02.nl.bb.gin.ntt.net [129.250.3.84] 24 64 ms 67 ms 69 ms po-1.r01.amstnl02.nl.bb.gin.ntt.net [129.250.4.71] 25 64 ms 115 ms 62 ms ae11.bbr01.eq01.ams02.networklayer.com.64.20.81.in-addr.arpa [81.20.64.50] 26 88 ms 61 ms 58 ms ae5.dar01.sr01.ams01.networklayer.com [50.97.18.237] 27 65 ms 58 ms 65 ms po1.fcr01.sr01.ams01.networklayer.com [159.253.158.131] 28 72 ms 62 ms 58 ms 5.10.64.1-static.reverse.softlayer.com [5.10.64.1]
Notate gli hop numero 1, 13 e 15. Il primo usa un IP appartenente ad una classe assegnata ad APNIC, che potrebbe entrare in uso a breve creando nuovi problemi di raggiungibilità. Il 13 e il 15 fanno parte di una classe assegnata al Dipartimento della Difesa americano. Inutile ripeterlo, Fastweb non ha titolo per usare nessuna di queste classi.
Com’è che si diceva del lupo?
Giorgio