P.S: Scusatemi se non sono stato molto preciso in alcuni dettagli ma non sono proprio espertissimo, eventualmente mandatemi un feedback che aggiusto l’articolo.

Gli indirizzi IPv4 sono scarsi. Agli albori di internet 2^32 indirizzi possibili sembravano una infinità. Ad oggi la ICANN (la società no-profit che si occupa di gestire indirizzi e regole ufficiali di Internet) ha esaurito tutti i “blocchi” di indirizzi IP assegnabili alle autorità “regionali” delle varie zone del pianeta. Questo ed altri motivi hanno condotto alla creazione di un nuovo standard, IPv6, che permette l’utilizzo di 2^128 indirizzi, che per svariati motivi sono stati calcolati come sufficienti per parecchio tempo.
Il processo di migrazione, già iniziato ufficialmente nel 2008, proseguirà per alcuni anni probabilmente e già da tanti anni si utilizzano due tecniche per ovviare al problema che alcune persone ritengono comode, ma io voglio mostrarvi quanto siano brutte, intefficenti e contro gli standard.

Già dagli anni 90′ però molte persone si erano accorte di questo problema ed è stato inventato il NAT (Network Address Translation).

Il NAT puro consiste nella semplice traduzione di indirizzi IPv4 da una classe di indirizzi privati a una classe di indirizzi pubblici e viceversa.
Supponiamo ad esempio di avere un gateway/router con due interfacce: una verso Internet e una verso una rete locale LAN che utilizza indirizzi IPv4 privati. Supponiamo di avere 10 computer nella LAN e 10 indirizzi IP disponibili sul router. Il NAT ci permette di fare un assegnamento IP Pubblico <-> IP privato. Quindi modificando la configurazione del router (e non dei computer) possiamo cambiare gli indirizzi pubblici di ciascun computer.
Questo può essere utile in qualche caso, ad esempio se abbiamo molti computer, pochi dei quali sono però accesi contemporaneamente. Allora possiamo tenere meno indirizzi IP pubblici rispetto al numero di computer nella LAN e utilizzare gli indirizzi a rotazione. Utile ma neanche tanto.

Quello che oramai da anni e anni va invece molto più di moda è il NAPT (Network Address and Port  Translation).

Il NAPT funziona in questo modo: supponiamo di avere una rete sempre con un router centrale che da un lato ha Internet e dall’altro una rete locale. Supponiamo adesso di avere un solo IP pubblico sul router e 10 computer nella rete locale. Come facciamo a far uscire i 10 computer su internet? Ammettiamo che ciascun computer vuole inviare/ricevere pacchetti TCP e UDP. Ciascun pacchetto TCP e UDP è caratterizzato da due numeri di “porta”, una porta sorgente ed una porta destinazione. La porta sorgente è un identificatore per capire da quale applicazione della macchina che invia il pacchetto si è originata la connessione, mentre la porta destinazione identifica il processo da contattare sulla macchina di destinazione, che provvederà a mandare le risposte alla porta sorgente del mittente.
Per riuscire a far funzionare tutto, il NAPT guarda la porta sorgente del pacchetto TCP che vuole instaurare la connessione verso un host di Internet e controlla le porte sorgenti libere relative all’indirizzo IP pubblico che ha a disposizione. Il router sceglie quindi una porta sorgente libera per il suo ip pubblico e in una tabella si segna: “il computer della rete locale con indirizzo ip privato x.y.z.w ha stabilito una connessione verso un host remoto e tutti i pacchetti con porta sorgente X che mi arrivano da lui devo sostituirli con la mia porta sorgente Y”. Ovviamente questo procedimento verrà fatto anche al contrario quando il router riceverà dei pacchetti di risposta. In questo modo l’accrocchio funziona e si riesce a utilizzare un solo indirizzo IPv4 per far collegare molti host in rete.
Il NAPT può anche essere effettuato mettendo più di un indirizzo IP sul router che utilizzamo, di modo da aumentare il numero di connessioni contemporanee, come vedremo dopo.

Sebbene questo sistema permetta in un certo senso di risolvere il problema della scarsità di indirizzi IPv4, molti nella comunità di Internet lo considerano un vero e proprio abominio. Ecco alcune delle obiezioni:

8 Motivi per cui il NAPT non andrebbe utilizzato:

  1. NAPT viola la più importante regola di stratificazione dei protocolli, secondo la quale un protocollo di livello k non dovrebbe fare nessuna assunzione riguardo a protocolli di livello k+1. Un router normalmente dovrebbe solo prendere i pacchetti IP che arrivano ed instradarli, invece con il NAPT deve anche andare a controllare il carico del pacchetto IP per verificare il numero di porta, cosa che non dovrebbe fare per le regole sulla stratificazione dei protocolli. Questo causa inoltre overhead non previsto su un apparato che dovrebbe solo instradare e invece deve iniziare anche a tenere traccia di tutte le connessioni che lo attraversano
  2. NAPT viola il modello gerarchico di IP, che afferma che ogni macchina collegata in rete è identificata in modo univoco a livello mondiale da un indirizzo IP. In certi casi questo può essere un vantaggio per il nostro anonimato, ma se stiamo parlando di rintracciabilità non è certamente una garanzia.
  3. I processi su Internet non sono obbligati ad utilizzare TCP e UDP. Se un utente dietro ad una NAT decide di utilizzare un diverso protocollo di livello 4 non potrà funzionare, perchè il NAPT si basa sull’idea di controllare i numeri di porta, che in alcuni protocolli di livello 4 potrebbero non esistere. ICMP, il protocollo per il controllo del funzionamento di IP e per la diagnostica di rete, non utilizza numeri di porta ed è stato necessario implementare nei router che fanno il NAPT dei particolari workaround per permettere di inviare e ricevere i pacchetti correttamente. Questo ovviamente è tutto altro carico sulle spalle del router. Non dimentichiamoci che ogni volta che aggiungiamo qualcosa da fare ai router, aumenta il carico di lavoro per ogni pacchetto e le linee potrebbero subire leggeri ritardi che aumentano la frequenza di congestioni. Questo potrebbe richiedere hardware più potente e quindi costi più alti! È un ragionamento tirato abbastanza per gli estremi, ma se il traffico è molto elevato questo è un overhead che pesa.
  4. Il numero di connessioni contemporanee diminuisce. Poichè il router del NAPT deve allocare una delle sue porte sorgente per ciascuna connessione, essendo le porte utilizzabili 2^16 (in realtà le prime 4096 sono riservate ad usi speciali), non possiamo avere più di 61440 connessioni contemporanee per ogni indirizzo IP pubblico utilizzato dal router. Possono sembrare una valanga ma se usiamo un solo ip per la rete di una azienda o una università e magari qualcuno inizia a fare port-scanning o altre brutte cose che consumano un sacco di connessioni, il router satura subito le porte libere. Se abbiamo 614 computer dietro il nat, ciascuno potrà fare circa 100 connessioni contemporanee, dopo di che il NAPT non ha più numeri di porta liberi. Allora dobbiamo tenerci un pool di indirizzi IP al posto di uno unico… Ma a questo punto aveva veramente senso fare il NAT se avevamo degli indirizzi? Se parliamo della rete di un ateneo sì, ma se parliamo di piccoli uffici forse no.
  5. NAPT trasforma Internet da una rete ad assenza di connessione, in un tipo di rete orientata alle connessioni, perchè il dispositivo NAPT deve conservare le informazioni relative ad ogni connessione che lo attraversa. Se un dispositivo NAPT si blocca e la sua tabella di mappatura si perde, tutte le sue connessioni TCP/UDP verranno distrutte. In assenza di NAPT, i guasti ai router non hanno effetto su TCP/UDP, perchè il processo di ritrasmissione si attiva dopo il timeout di alcuni secondi. State scaricando un file e qualcuno riavvia il router che effettua il NAPT per manutenzione? La connessione verrà persa perché il router dopo il riavvio non è in grado di effettuare di nuovo le traduzioni di porta e né il mittente né il destinatario si accorgeranno del problema, la connessione resta in uno stato di zombie… Con un normale router senza NAPT e una connessione TCP si sarebbe notato solo un lag di pochi secondi (il tempo di riavvio del router).
  6. Solitamente ogni host collegato su internet può effettuare delle connessioni a dei server, oppure esporre dei propri servizi alla rete e permettere ad altri di collegarvisi. Purtroppo con l’introduzione del NAPT, se ad esempio nella rete locale ci sono due host con server web sulla porta 80, non è possibile esporre entrambi quei servizi sullo stesso indirizzo sulla stessa porta 80, quindi l’unica soluzione possibile (quando viene manualmente abilitata con il così detto Port Forwarding), è di assegnare due porte distinte dell’indirizzo pubblico ai due servizi dietro al NAPT, quindi ad esempio la porta 80 per uno dei due server web e la porta 81 per l’altro. Così facendo ovviamente il servizi che i vari host della rete locale possono esporre si riduce notevolemente. Se poi teniamo conto che gli stessi numeri di porta devono anche essere usati come porte sorgenti per le connessioni in uscita, la situazione è sempre peggiore. (Anche) per colpa del NAPT, Internet sta diventando sempre più una rete quasi esclusivamente per “scaricare” contenuti, questo sarà un problema più “filosofico” che tecnico, ma secondo me il bello di Internet, fin dai primi giorni in cui esiste, è proprio la possibilità per chiunque di esporre un suo servizio a tutti, in qualunque parte del mondo, senza dover dipendere obbligatoriamente da terze parti per farne “hosting”.
  7. Molti protocolli a livello applicativo, tra cui DCC e il notissimo FTP (in modalità attiva) fanno uso degli indirizzi IP degli host da cui si originano le connessioni all’interno dei messaggi scambiati a livello applicativo per avvertire il server a cui si collegano di inviare i dati da scaricare su una certa porta del client. Il NAPT non sa nulla di tutto questo e il risultato è che questi protocolli non sono più in grado di funzionare perché i server FTP tentano di inviare i dati a porte sul router NAPT che non è a conoscenza di questa operazione in corso e non permette il passaggio. Su alcuni router sono stati implementati dei meccanismi per intercettare il traffico a livello applicativo di questi protocolli e sbloccare le porte in ingresso per mettergli di funzionare. Questo è ancora più grave del primo punto perché con questo problema il router non deve solo andare a vedere il livello protocollare 4, ma addirittura anche i dati sul livello 7. Questo genera un overhead esagerato sulle operazioni di cui deve tenere traccia il povero router. Se questo non vi basta ancora, forse dovreste leggere dei magheggi che si sono dovuti inventare i realizzatori di IPsec per riuscire a farlo funzionare con il NAPT. IPsec infatti si basa sull’idea di “firmare” o cifrare il contenuto di pacchetti IP in modo da renderli sicuri e con sorgente affidabile. Per raggiungere questo scopo viene preso tutto il contenuto del pacchetto IP e firmato digitalmente ad esempio. Peccato che con il NAPT dei campi che dovrebbero essere fissi (aka porte TCP e/o UDP) diventano mutabili e quindi la firma non sarà più valida. Per poi non parlare dei pacchetti cifrati con IPsec, che ovviamente non potranno normalmente varcare il NAPT dato che non c’è modo di leggerli per fare la traduzione di porte.
  8. Il NAPT non permette di mantenere connessioni aperte in stato idle. Spesso può capitare di dover tenere una connessione aperta dove non passa neanche un bit per ore o settimane. TCP supporta questa cosa senza problemi ma il NAPT avendo pochi numeri di porta sorgente a disposizione non può permettersi di “sprecarli” per connessioni che non fanno nulla, quindi quando non viene rilevata attività per un po’ di tempo in molte implementazioni di NAPT si è obbligati a cancellare dalla tabella del NAPT la connessione. La cosa peggiore di questa cosa è che (in alcune implementazioni) i due host credono di essere ancora collegati tra loro, perché il NAPT non avvisa nè mittente nè destinatario che ha cancellato la riga nella tabella, quindi il client che ha aperto la connessione non vedrà nessun dato arrivargli anche se il server ha tentato di inviarli senza ricevere risposta. Invece una connessione TCP sopra IP inattiva, senza un NAT di mezzo, può resistere a qualunque problema di rete. Possiamo spegnere router, cambiare linee di collegamento, cambiare instradamento per arrivare il router, possiamo mettere in standby l’host, tagliare le fibre ottiche nell’atlantico e ricollegarci via saltellite. Possiamo fare quel cavolo che ci pare, quando torneremo nella nostra connessione, se gli indirizzi IP degli endpoint non sono cambiati saremo ancora collegati e potremo ancora mandare dati nella stessa connessione, tutto grazie a TCP/IP. Viene spontaneo chiedersi: come si fa allora con il NAT a tenere aperte connessioni persistenti? Ci sono tanti metodi. Quello più ovvio è di inviare dei messaggi di ping, e relative risposte (pong) a livello applicativo “ogni tanto” (come fa IRC, websocket etc etc…). In alternativa è possibile utilizzare un workaround (TCP-Keepalive) per inviare dei pacchetti TCP vuoti ogni tanto all’interno della connessione, come segno di “attività” e per evitare che il NAPT cancelli la regola di traduzione.

Il mito del NAT come firewall

Non dobbiamo nascondere che molto spesso, il NAPT, per come funziona, viene sfruttato impropriamente come meccanismo di firewalling. Ad esempio immaginiamo una rete di una università. Vogliamo evitare che la gente accenda server SMTP per iniziare attività di spamming o altre cose simili, come evitare che gente possa esporre servizi su internet ma possa allo stesso tempo collegarsi? Beh facciamo un bel NAPT. Questa è una porcheria bella e buona, specialmente quando viene fatta su reti relativamente piccole dove ci possono essere abbastanza indirizzi pubblici per tutti senza problemi. Il NAPT non serve a quello, per bloccare le connessioni in ingresso si possono utilizzare regole di firewalling sui router per non permettere a host di Internet di stabilire connessioni verso la rete locale con una cosa del genere con iptables:

echo 1 > /proc/sys/net/ipv4/ip_forward

iptables -P FORWARD DROP

iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT #Permettiamo a tutto di uscire dalla interfaccia della rete locale ad internet

iptables -A FORWARD -i eth0 -o eth1 -m state –state RELATED,ESTABLISHED -j ACCEPT

Con queste 4 righe in realtà comunque il router deve andare a tenere conto di alcuni dettagli sul livello 4, ma è sempre meglio di usare il NAPT, per gli altri motivi sopra citati.

Alcune persone provano una falsa sensazione di sicurezza stando dietro al proprio NAPT, pensando di essere al sicuro. In realtà si sbagliano di grosso.

  • Su alcuni router “casalinghi” molto economici, dove viene implementato il NAPT, può succedere per vari motivi che quando arriva un pacchetto da internet, con IP sorgente spoofato (modificato da un attaccante) per essere nella classe degli indirizzi privati (ad esempio arriva un pacchetto UDP con sorgente 192.168.0.1), il router non si interessa del fatto che il pacchetto arriva dall’interfaccia “sbagliata” (cioè quella verso Internet e non quella della rete locale), ma invece lo guarda e lo instrada nella rete locale. Ovviamente poi le risposte non torneranno indietro all’attaccante, ma con questo metodo si può già iniziare a tentare qualche attacco. Se non sbaglio diversi anni fa con questo metodo si riusciva ad attaccare un sistema di RPC su Windows e quindi con una serie di meccanismi ad ottenere anche delle risposte e quindi attaccare completamente la macchina bucando il NAT.
  • Su altri router, vengono abilitati dei moduli particolari (presenti anche come moduli di iptables per il kernel Linux) per permettere a FTP, DCC e altri protcolli citati prima di funzionare. Questo è certamente un bene ma espone anche dei problemi di sicurezza perché con attacchi particolari è possibile sfruttuare questi meccanismi per aprire arbitrariamente delle porte del NAPT verso una porta di un host della rete locale. Ad esempio preparando una particolare pagina web e facendola visitare ad un utente ignaro, è possibile instaurare una finta connessione IRC sopra HTTP e quindi fare una richiesta DCC e sbloccare una porta in ingresso. Questo metodo viene mostrato tra altre cose in questo video.


Talk su Nginx

25Ott11

In occasione del Linux Day 2011 a Milano, ho tenuto un breve talk sul server web Nginx. Nel caso qualcuno stesse cercando le slides, le ho caricate anche qua:
https://otacon22.files.wordpress.com/2011/10/nginx.pdf


Giappone 2011

24Ago11

Ed eccomi tornato dalla terra del sol levante. Avevo promesso un aggiornamento periodico durante il viaggio, ma non ho mai avuto tempo e voglia per prepararlo. Avevo semplicemente iniziato la stesura di questo articolo e poi l’ho lasciato in bozza per un po’.
Anche riguardo alle foto ne ho fatte pochissime, perché ho pensato di vivere la vacanza con un po’ più di relax, dopo la sessione d’esami mostruosa che ho passato 🙂

L’arrivo

Il viaggio aereo è stato molto stancante questa volta perché ho dormito veramente poco.
Sono atterrato Sabato 30 Luglio di prima mattina a Narita (成田), da dove mi sono spostato in direzione del mio appartamento a Kameido (亀戸). Appena arrivato mi sono procurato la carta ricaricabile Suica all’ufficio JR dell’aereoporto. Ho tentato di spiegare che volevo un abbonamento Okachimachi <-> Kameido ma mi hanno fatto una normale ricaricabile senza abbonamento.
Da Narita non ho preso il Narita express perché risultava più costoso e scomodo. Sono invece andato in direzione di Chiba con la linea Sobu rapida e poi ho proseguito per  Kinshicho (a seconda degli orari ci sono treni che necessitano di scendere a Chiba per cambiare o altri che proseguono). Da kinshicho sono “tornato indietro” di una fermata con la linea Sobu local ed ero a Kameido. In totale ho impiegato circa 1 ora e ho speso intorno ai 1500-2000¥ se non mi ricordo male. Tuttavia devo dire che girare con il valigione su quel tipo di treno non è proprio il massimo e ho dovuto farmi da parte e continuare a spostare la valigia.

C’è stato un po’ di casino all’hotel dove alloggio perché il check-in era alle 15 e io alle 9:00 ero già arrivato. Allora ho lasciato la valigia e sono andato a fare un giro (anche per mangiare) a Shinjuku. Ero molto stanco e non vedevo l’ora di andare a letto nella mia stanza, alle 15 infatti sono tornato subito per riposarmi. Più tardi dopo cena sono andato a letto presto (stanchissimo ancora dal volo) e mi sono svegliato intorno alle 3 di mattina.

I terremoti

Intorno alle 3:50 di Domenica 31 Luglio c’è stato un terremoto (chiaramente avvertibile, anche perché ero al 9° piano). Niente di tragico fortunatamente. Si trattava di un terremoto con epicentro al largo della prefettura di Fukushima di intensità 6.4 all’epicentro. Qua è stato avvertito ad una intensità 4 circa (vi ricordo che la scala è logaritmica). Ha oscillato parecchio il lampadario e ho subito acceso la tv dove sulla NHK (tv di stato giapponese) c’era già l’allerta e le notizie in diretta mentre ancora stavo sentendo il terremoto. Anche nei giorni seguenti ci sono stati dei leggeri terremoti (sempre con epicentro a nord di Tokyo) ma sempre nessun grosso pericolo. Da allora e nei giorni successivi ho sempre fatto riferimento al sito web della Japan Meteorological Agency per informazioni.

Molti mi hanno chiesto “Ma non sei preoccupato per i terremoti? Non ci sono segni visibili del terremoto dell’ 11 Marzo a Tokyo?” La risposta ad entrambe queste domande è no.

I terremoti sono pericolosi però nell’aera urbana di Tokyo e anche altrove gli edifici sono tutti a norma e non ho saputo di nessun edificio crollato a Tokyo l’11 Marzo ma solo di danni parziali. Ho sentito invece di tanta gente (che magari abitava molto in alto) a cui si sono rotti tutti i piatti, alcuni mobili, televisori, monitor del pc e altro durante l’11 Marzo. Uno dei pochi segni chiaramente evidenti dell’11 Marzo a Tokyo penso sia l’antenna della Tokyo Tower che si è lievemente stortata. La situazione in altre prefetture a nord più colpite è diversa ovviamente.
Il Giappone del resto è sempre stato caratterizzato da una intensa attività sismica per motivi geologici. In un museo qua a Ryogoku avevo visto di come Tokyo fosse stata molto tempo fa completamente distrutta a causa di terremoti e conseguenti incendi. Questo è “servito” a sensibilizzare i giapponesi al problema sismico già dall’antichità fino ad oggi, motivo per cui gli edifici vengono rigorosamente costruiti a norma antisismica.
C’è anche da dire però che fino ad adesso non ci sono stati terremoti forti con epicentro molto vicino a Tokyo. In quel caso anche gli edifici a norma potrebbero non essere sufficienti.

Qualcosa di nuovo

Tornando al mio viaggio: nei primi giorni ho fatto pochi giri e sempre in posti più o meno già visti, più che altro perché ancora stanchissimo dal volo aereo.
Uno dei posti nuovi dove sono stato è l’Ebisu Garden Place. Si tratta di una piccola zona di negozi tra alcuni grattacieli. Ci si arriva facilmente seguendo delle indicazioni partendo dalla stazione di Ebisu (Yamanote line).È una sorta di città nella città, un’area con una piazza e dei negozi tra due grattacieli. Un punto che mi sono preoccupato di fotografare è la “Marionette Clock Square”, famosa piazza che si vede nel drama Hana yori dango, punto dove i due protagonisti Tsukushi e Doumyouji si incontrano. Vicino a questa piazza c’è anche un museo e la sede della birra Ebisu della Sapporo.
Nella mia guida turistica ho letto che Ebisu dovrebbe essere una zona famosa anche per la cucina, però non ho visto molti ristoranti, probabilmente ho guardato nella zona sbagliata.

Un weekend sono anche passato a Nikko, posto abbastanza famoso a Nord di Tokyo, con magnifici templi e paesaggi. Trovate qualche foto sul mio album picasa.

Il 13-14 Agosto sono andato a Kyoto in treno (shinkansen) per incontrare degli amici e poi sono andato a Nagoya per incontrare degli amici della mia famiglia.
Lo shinkansen è stato parecchio costoso, ma decisamente comodo; senza contare che l’incontro con gli amici a Kyoto è valso decisamente il viaggio ^^
Ogni volta che si va fuori Tokyo si respira sempre un’aria diversa e c’è una atmosfera più tranquilla. È stato un peccato non passare qualche giorno fuori Tokyo.

Sono passato un paio di volte ad Akihabara anche. Qualche nuovo negozio ma niente di straordinario.
Come forse avrete letto, l’edificio di Radio Kaikan è stato chiuso per essere ristrutturato (non era a norma antisismica) ed è chiuso da alcune settimane se ho capito bene. Comunque quasi tutti i negozi che c’erano dentro sono stati spostati (temporaneamente?) nell’edificio a fianco, che era già stato preparato l’anno scorso apposta a quanto pare.

Il clima è stato parecchio fresco quando sono arrivato gli ultimi due giorni di Agosto. Poi però ha gradualmente iniziato il tipico caldo estivo nel giro di una settimana. I condizionatori nei negozi sono già accesi come al solito.

Riguardo ai consumi energetici

Come certamente saprete, in seguito all’arresto della centrale di Fukushima ci sono stati diversi problemi, tra cui quello della mancanza di energia elettrica. Infatti la centrale di Fukushima è una di quelle che serviva buona parte dell’energia utilizzata nell’area urbana di Tokyo. Vi ricordo in proposito che Tokyo è una delle aree metropolitane più vaste del mondo, di consumi energetici ce ne sono parecchi.
Subito dopo l’arresto della centrale la società che la gestisce, la TEPCO (Tokyo Electric Power Company) ha iniziato una serie di blackout a rotazione di diverse aree della prefettura di Tokyo (e anche altrove) per tentare di non arrestare del tutto la fornitura di energia elettrica. In seguito il governo ha iniziato una grande compagna chiedendo aiuto a tutti i cittadini per ridurre i consumi per aiutare a risolvere il problema e intanto TEPCO si è organizzata per deviare corrente da altre centrali e incrementarne l’attività.
Grazie allo sforzo di tutti i blackout sono cessati e le attività quotidiane (almeno qui) sono tornate alla normalità.
In moltissime stazioni (se non in tutte), alcune macchinette automatiche dei biglietti, alcune scale mobili e alcuni tornelli di uscita elettronici sono stati spenti per aiutare a ridurre i consumi. Anche in treno a volte durante le giornate di sole vengono spente le luci al neon all’interno che sono superflue.
Gli impiegati in molti uffici governativi e non,  hanno iniziato a venire vestiti più “casual” senza la solita giacca e cravatta, di modo da poter tenere i condizionatori a temperatura un po’ più alta e risparmiare energia.
Penso sia molto interessante vedere come il popolo (a dispetto di quello che potrebbe accadere altrove) si sia subito adattato al problema e abbia iniziato a prendere le contromisure. Poche settimane dopo gli annunci sul risparmio energetico erano già in commercio condizionatori appositamente studiati per ridurre i consumi, macchinette delle bibite per le stazioni a basso consumo, alcune scale mobili di centri commerciali spente e così via.
La TEPCO dovrebbe completare a giorni una nuova centrale fotovoltaica che aiuterà (seppur poco) a risolvere il problema energetico.
Ogni giorno in televisione, anche più volte al giorno, compare un grafico che mostra i consumi attuali in watt e quelli dell’anno scorso e si vede chiaramente che c’è un po’ di risparmio, che evita di saturare la potenza massima erogabile. Compare anche una percentuale che indica quanta potenza è attualmente consumata rispetto al massimo disponibile. Intorno a ferragosto, a causa del grande caldo, abbiamo superato il 90%. Se si dovesse superare il 100% sarà necessario riniziare i blackout a rotazione.
Oltre a questo, ogni tanto si sente passare delle camionette (non so se della polizia o altro) che con un megafono annunciano in tutti i quartieri di alzare i condizionatori e ridurre i consumi.

Comunque secondo me il risparmio energetico anche se sta funzionando, potrebbe essere incrementato: ho visto alcune scale mobili inutili accese all’interno di centri commerciali. In molti posti continua ad esserci aria condizionata esageratamente bassa e ancora troppe luci accese all’esterno di alcuni locali la sera. Molti negozi di grandi catene hanno tutta una serie di interessi per attirare clienti e se ne fregano un po’ del risparmio energetico.

Radiazioni e cibo contaminato

Essere qua nonostante la tragedia dell’11 Marzo e la centrale di Fukushima è un po’ dura ma gli effetti non si fanno sentire ancora a Tokyo. Una della cose che veramente preoccupa è la contaminazione del cibo. Nonostante tutti gli sforzi che la TEPCO fa ogni giorno per tentare di ridurre i problemi alla centrale, parecchio materiale radioattivo si continua a liberare.
Restando ad almeno ~80 Km dalla centrale non si subisce nessun effetto di possibili radiazioni. Tokyo è a ~300 Km da Fukushima e attualmente i livelli di radioattività di Tokyo sono inferiori a quelli di Roma.. I livelli di radioattività vengono monitorati da tantissimi privati che li pubblicano su internet (ad esempio ci sono diversi stream su ustream.tv), poi c’è anche la via “ufficiale” per verificare i livelli di radioattività che è questo sito (sito web dell’istituto per la salute pubblica). Tuttavia vicino al limite dell’area “pericolosa” di Fukushima e anche in altri punti ci sono allevamenti e campi coltivati. Inutile dire che molti sono contaminati.
Non molti giorni fa il governo ha iniziato una campagna in cui ha messo al bando tutta la carne proveniente da quella zona, procedendo con accurati controlli ai mercati della carne. Le misure prese dal governo sono state così rigide che anche allevamenti probabilmente non contaminati sono forse stati inclusi nel bando e per questo ci sono state delle lamentele.
Anche il riso e la soia potrebbero essere a rischio. Diversi giorni fa qualcuno ha messo su youtube un video che mostra livelli di radioattività anomali in semi di soia comprati in un negozio specializzato. Anche questo ha generato lunghe discussioni e ha contribuito ad aumentare ancora di più i controlli del governo. Ogni giorno in televisione si vedono video di ispezioni in fabbriche dove viene impacchettata frutta e verdura, campi di riso etc etc..
Del mare non si è ancora parlato molto a quanto pare, ho letto che nonostante le contaminazioni l’oceano ha una fortissima capacità di assorbire e “diluire” abbastanza le sostanze radioattive. Controlli anche sul pesce sono comunque attivi.
In questi giorni la TEPCO ha iniziato a costruire una struttura per isolare la centrale ed evitare ulteriori contaminazioni del mare e dell’aria.

Turisti

Mi è stato chiesto da diverse persone com’è la situazione turisti: ce ne sono?
Sì, certamente, ma neanche poi tanto. Girando ad Akihabara, Ueno, Shinjuku, Asakusa etc lo si nota che c’è un po’ meno attività turistica. Nella mia scuola di giapponese per stranieri alcune classi sono meno piene del solito penso. Sono l’unico italiano della scuola, gli americani che di solito sono parecchi, quest’anno sono meno. I taiwanesi non sembrano essere diminuiti molto. Comunque da qui a dire che l’attività turistica è drasticamente diminuita c’è di mezzo il mare.

Non mi viene in mente di altre cose nello specifico da raccontare, lasciatemi delle domande nei commenti se volete e risponderò volentieri. Eventualmente farò un altro post.


Hehe, vi aspettavate un post tecnico eh? E invece sorpresina! Anche quest’estate torno a Tokyo per tre settimane!
Sarò ancora come l’anno scorso in una scuola per stranieri a studiare giapponese.
Avendo proseguito lo studio della lingua giapponese dall’estate scorsa fino ad ora, penso che questa volta vivrò meglio le lezioni e imparerò ancora di più.

Ci sono poi diverse persone che ho conosciuto su internet che non vedo l’ora di incontrare, anche per fare pratica di quello che studio!

Metterò come al solito dei post riassuntivi, magari ogni 2-3 giorni al posto che ogni giorno come l’anno scorso!

Se doveste avere richieste particolari riguardo a video di qualche zona di Tokyo (o anche Kyoto dato che forse ci passerò) o altro, avvertitemi!

さよなら!


Mi è capitato spesso di avere una macchina  che deve esporre dei servizi in rete su alcune porte tcp/udp che però volevo evitare di mostrare al “mondo”.
Ad esempio può essere che voglio aprire un server ssh. Indipendentemente dal servizio e dalla porta, può essere poco raccomandabile lasciarlo lì aperto “a tutti”.
Potremmo allora pensare di aggiungere una regola sul firewall (iptables) per abilitare l’accesso solo da daterminati ip sorgenti. Peccato che molto spesso gli indirizzi sorgente possono cambiare (indirizzi ip dinamici e altro).

Il port-knocking permette di risolvere queste ed altre situazioni.

Supponiamo appunto di avere la porta del servizio ssh (la 22) che vogliamo aprire solo per certe persone, però non sappiamo i loro indirizzi ip. Con la tecnica del port-knocking possiamo avviare un demone che resta “in ascolto” sulle interfacce di rete per tutte le richieste di connessione a basso livello. Quando questo demone vede delle richieste di connessione ad alcune porte (anche “chiuse”) in successione con una certa sequenza, lancia un comando.

Richieste a porte in successione alla fine è una sorta di codice segreto per sbloccare una porta “bussando” su altre ben definite.

Un caso tipico potrebbe essere questo: diciamo al demone che quando vede delle richieste di connessione alle porte  77,98,1044,1066 (esattamente in quest’ordine e fatte entro un certo tempo massimo l’una dall’altra), decide di guardare l’indirizzo ip di chi ha “bussato” e sbloccare solo per lui la porta di ingresso sulla 22 (lanciando una regola di iptables).
Altra cosa molto utile è richiudere la porta appena aperta dopo alcuni secondi. In questo modo l’utente remoto che deve collegarsi “bussa” e si collega, poi richiudendo la porta la connessione oramai stabilita con ftp non cadrà (dato che supponiamo che sul server ci sia una regola iptables per mantenere sempre attive le connessioni stabilite) e altre persone, anche con lo stesso indirizzo sorgente (dentro la stessa NAT dell’utente magari) non potranno collegarsi.

Per prima cosa dobbiamo procurarci il demone, che si chiama knockd. Nelle maggiori distribuzioni lo trovate facilmente nei repository. Lo stesso pacchetto comprende al suo interno anche il “client”, anche se per client potreste usare normalmente netcat o altro (basta solo “bussare” alla fine :D).

Il file di configurazione si trova in /etc/knockd.conf

La configurazione di default dovrebbe essere qualcosa di simile:

[openSSH]
	sequence    = 7000,8000,9000
	seq_timeout = 5
	command     = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
	tcpflags    = syn

[closeSSH]
	sequence    = 9000,8000,7000
	seq_timeout = 5
	command     = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
	tcpflags    = syn

Questa configurazione significa che quando knockd vede dei pacchetti syn (richiesta di connessione) sulle porte 7000,8000,9000 (in questo preciso ordine), “bussando” in un massimo di 5 secondi, allora viene lanciato il comando “command”.
Quel comando iptables specifica che vengano accettate tutte le connessioni provenienti dall’indirizzo IP di chi ha “bussato” e dirette alla porta tcp 22 (solitamente adibita al protocollo SSH).

Nella sezione seguente, chiamata “[closeSSH]” viene fatto esattamente l’opposto in corrispondenza della sequenza di porte 9000,8000,7000.

Di default il demone knockd non si avvierà se non modificate prima il file /etc/default/knockd impostando:

START_KNOCKD=0

Sempre nello stesso file possiamo specificare su quale interfaccia di rete dovrà lavorare knockd (di default penso le utilizzi tutte):

KNOCKD_OPTS="-i eth0"

Per “bussare” sulle porte utilizzando il client apposito incluso nel pacchetto di knockd ci basterà lanciare un comando tipo questo:

knock 1.2.3.4 7000 8000 9000

Ma usare knock non è obbligatorio. Se siamo su un pc dove non lo abbiamo a portata di mano possiamo anche optare per una soluzione del genere:

 for i in 7000 8000 9000; do nc 1.2.3.4 $i & done;

In questo modo vengono lanciate in background varie istanze di netcat in successione.

Una volta collegati ad ssh si suppone che il firewall iptables sulla macchina che configuriamo sia già impostato per accettare in ingresso connessioni stabilite, di modo che quando la porta viene chiusa la connessione non cade.
Solitamente questo lo si fa con una regola tipo (che comunque dovreste già avere se avete la policy di iptables in DROP):

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

Nella configurazione che abbiamo visto prima la porta viene aperta e chiusa con una combinazione. Una soluzione più furba potrebbe essere di farla chiudere “automaticamente” qualche secondo dopo che la sequenza è stata lanciata e si è aperta

Un esempio di config per fare cio è il seguente:

[openBITS]
        sequence = 9132,4367,8371,1321,5239
        seq_timeout = 30
        tcpflags = syn
        start_command = /sbin/iptables -A INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
        cmd_timeout = 60
        stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

In questo modo avremo 30 secondi per “bussare” ed una volta aperta la porta, lo resterà per soli 60 secondi.

Per debugging e controllare altro potete sempre visionare il file di log di knockd su /var/log/knockd.log

Come altri spunti interessanti vi avverto che è possibile anche specificare se la porta su cui bussare sia TCP o UDP (per complicare la sequenza) ed è anche possibile verificare la presenza/assenza di determinati flag tcp. In ogni caso trovate altre informazioni sulla pagina ufficiale o nella documentazione.


Disclaimer: L’autore non si assume nessuna responsabilità in merito all’utilizzo illecito delle istruzioni tecniche riportate qui di seguito.

Navigare ed essere collegati, al giorno d’oggi, diventa sempre più importante e si discute di rendere la connessione ad Internet un diritto fondamentale umano. Essere collegati ad una rete unica che collega l’intero pianeta e permette a miliardi di persone di comunicare in ogni momento è semplicemente fantastico, tuttavia a livello utente il discorso “banda” si fa spesso sentire, specie a “livello programmatore” direi 🙂 ..

Bonding di rete

Navigare in rete con 1Mbit/s (125kB/s) può essere ancora accettabile, quando andiamo intorno ai 50kB/s la faccenda inizia a diventare fastidiosa, specialmente se dobbiamo fare una videochiamata o scaricare degli aggiornamenti.
Un caso poco frequente ma che aiuta a far comprendere il seguito è questo:
Immaginiamo di avere un computer con due schede di rete da 10Mb/s ed un router/switch/hub con tante porte da 100Mb/s. Trasmettere e ricevere con un ordine di grandezza in meno per la velocità potrebbe rivelarsi alquanto fastidioso. In alcune situazioni potrebbe dover servire giusto poco più di 10Mb/s e sarebbe alquanto triste non poterli avere.

Fortunatamente all’interno dei moduli di Linux, ne esiste uno chiamato bonding, che permette di ovviare a problemi come questo.

Con il modulo del kernel bonding, è infatti possibile riunire più interfacce di rete in un gruppo, trattandole astrattamente come se fossero una interfaccia unica con un nuovo nome, come ad esempio bond0. Tutto il traffico diretto a bond0 verrà inviato al modulo bonding, che deciderà come dividerlo sulle interfacce del gruppo, idem il viceversa. Una delle politiche per “dividere” il traffico più comuni (e che utilizzerò qua nel seguito) è quella di round-robin, cioè la equa suddivisione del traffico inviando e ricevendo un equo numero di pacchetti da ogni interfaccia. In realtà il modulo bonding permette anche altre configurazioni, che risultano molto utili per server di produzione, dove anche se una interfaccia si guasta o è in sovraccarico, il modulo bonding decide autonomamente di utilizzare una interfaccia di “backup” per risolvere il problema. Quest’ultimo aspetto non sarà comunque di nostro interesse ora.
Dal punto di vista di protocollo di rete, quando più schede vengono unite in una unica bond0, l’indirizzo mac e ip che prima erano diversi per ogni interfaccia, diventano uno solo, associato a bond0. Le interfacce che mettiamo in bonding cessano di avere ip o mac address associati.
Dal punto di vista “teorico” e poi in base a quanto appena detto nella “pratica”, risulta evidente che non sarà possibile utilizzare il bonding con schede collegate a due reti diverse, cioè a reti che utilizzano indirizzi diversi, o comunque in generale dove gli stessi pacchetti non possono arrivare su entrambe le interfacce indistintamente. Vedremo in seguito che questo problema può essere comunque aggirato con un po’ di “fatica”.
Supponiamo ad esempio che le due schede sul nostro computer siano eth0 e eth1; con le poche righe di codice seguenti sarà possibile riunirle in una unica interfaccia bond0 che avrà dunque il doppio della banda: 20Mb/s

modprobe bonding mode=0 miimon=100

ifconfig eth0 down
ifconfig eth1 down

ifconfig bond0 hw ether 00:11:22:33:44:55
ifconfig bond0 192.168.55.55 up

ifenslave bond0 eth0
ifenslave bond0 eth1

Rivediamo i passi: nel modprobe viene abilitato il modulo di bonding, specificando il mode, cioè la politica per dividere i pacchetti. In questo caso 0 è la mode per abilitare il round-robin sopra citato. Dopo aver caricato il modulo, la prima cosa da fare è disattivare le due interfacce di rete eth0  e eth1. A questo punto possiamo configurare la nostra interfaccia bond0, che è stata creata nel momento in cui abbiamo abilitato il modulo di bonding. Come primo passo impostiamo il suo mac address e poi il suo indirizzo IP. Come abbiamo detto prima infatti, le schede unite con bonding cessano di avere ip e mac address e solo la scheda virtuale che le riunisce avrà un indirizzo IP ed un mac address. Assicuriamoci che gli indirizzi impostati siano validi per la nostra rete.
A questo punto l’interfaccia di bonding è pronta, resta solo da dirgli quali interfacce riunire. Questo viene fatto mediante il comando ifenslave, il cui nome richiama il fatto che vengono aggiunte interfacce “schiave”.

Una cosa divertente che si nota da questo esempio, è che l’aggiunta di interfacce da mettere in bonding può essere fatta in tempo reale utilizzando il comando ifenslave! Può sembrare banale, ma la cosa è invece molto interessante. Pensate all’esempio precedente e supponiamo di collegare una scheda di rete usb da 10Mb/s al computer mentre sta lavorando con eth0 e eth1 in bonding. Posto che il kernel riconosca la scheda usb ci basterà collegarla e digitare:

 ifenslave bond0

per vedere subito la velocità delle nostre connessioni aumentare, ed il tutto senza interrompere nessuna connessione in corso!

È sottointeso che tutti i comandi precedenti vanno eseguiti da utente root.

Attenzione! Tutte le volte che facciamo bonding dobbiamo assicurarci di non avere l’opzione rp_filter attivata sul kernel. Se attivata, questa opzione fa sì che il kernel tracci le connessioni in ingresso e rifiuti connessioni dirette ad un indirzzo diverso da quello dell’interfaccia su cui viene ricevuta la connessione. Su alcune distribuzioni (ad esempio ArchLinux) l’rp_filter è disattivato di default, su altre (ad esempio Ubuntu) è attivato di default.. quindi ci conviene controllare.
Possiamo disabilitare l’rp_filter per tutto il sistema con:

echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter

Oppure possiamo disabilitarlo sulle singole interfacce, facendo riferimento all’esempio di prima:

echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

Interfacce virtuali wireless

Passiamo a parlare d’altro ora.

Vi è mai capitato di avere a disposizione due o più reti wireless, ad esempio da 10Mb/s ciascuna e avere la copertura di entrambe dal punto in cui vi trovate con il vostro pc/portatile?
Sarebbe bello riunirle insieme in qualche modo per ottenere il doppio della banda come prima!
Iniziamo con questo esempio: dal vostro portatile riuscite a connettervi a due access point che però hanno appunto un “collo di bottiglia” da 10Mb/s nella banda a disposizione ciascuno. La rete a cui sono collegati questi due access point ha però una ampiezza di banda molto più elevata!

Ok, le reti wireless sono due, però alla fine la rete è la stessa: ci verranno dati indirizzi IP nella stessa sottorete e tutto il resto. Allora ci serve solo capire come collegarci ad entrambe.

Avete mai visto che ci sono access points in grado di mostrarvi due reti wireless anche se in realtà la scheda fisica è la stessa (ad esempio questo accade con la fonera, per chi la conosce)? Beh, anche il contrario è possibile, cioè sostanzialmente è possibile suddividere una interfaccia wireless in un insieme di schede wireless virtuali e far collegare ciascuna di esse ad una rete diversa.

Per fare questo avete bisogno di due cose: una scheda wireless che supporta le “virtual interfaces” (VLANs o VIF) ed un kernel linux 2.6.37 (la cosa dovrebbe funzionare anche da kernel precedenti ma c’era qualche dettaglio ancora non funzionante).
Per quanto riguarda la scheda wireless che supporta le VLANs, questo è vero per praticamente tutte le schede Atheros (quelle che utilizzano i driver ath5k e ath9k) e forse anche per altre schede (in via teorica controllando con il comando “iw list” si dovrebbe riuscire a capire se una scheda può farlo).
C’è un piccolo prezzo da pagare per avere queste VLANs: se ci stiamo collegando a reti protette (come nella maggior parte dei casi), sarà necessario caricare il modulo ath5k o ath9k con un parametro nohwcrypt=1. Perché? Il discorso è che la scheda wireless effettua “in hardware” la cifratura dei dati trasmessi e ricevuti. Questo inizia a diventare un problema se deve farlo per due reti,che quasi sicuramente devono cifrare i dati in modo diverso. Dunque il prezzo da pagare è che le cifrature non potranno essere fatte sulla scheda ma dal nostro processore.

Supponiamo di avere una scheda che usa driver ath5k, vediamo quali passi seguire (sono gli stessi anche per le schede con driver ath9k):

modprobe -r ath5k

modprobe ath5k nohwcrypt=1

Così abbiamo disattivato il driver della scheda e lo abbiamo riabilitato con l’opzione per disabilitare la cifratura hardware.

iw phy phy0 interface add wlan1 type station

In questo modo abbiamo aggiunto un’altra interfaccia oltre alla già presente wlan0. Il mac address della interfaccia generata wlan1 sarà uguale a quello dell’altra. La cosa non ci piace ovviamente e vogliamo che le due schede abbiano due mac address differenti, di modo da apparire esattamente come se fossero due schede di due computer diversi. Per ovviare al problema possiamo usare ifconfig come prima:

ifconfig wlan1 hw ether 00:11:22:33:44:55

Oppure se vogliamo evitare di doverci inventare un mac address al volo possiamo usare macchanger (non è incluso di default in quasi nessuna distribuzione Linux):

macchanger -A wlan1

In questo modo il mac address impostato sarà casuale (ma non così casuale da rendere evidente che si tratti di un mac address falso).

Ok, abbiamo le nostre due interfacce virtuali wireless. Supponiamo che le reti necessitino autenticazione WPA.

iwconfig wlan0 essid “Rete1”
wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant_rete1.conf &
dhclient wlan0
iwconfig wlan1 essid “Rete2”
wpa_supplicant -Dwext -iwlan1 -c/etc/wpa_supplicant_rete2.conf  &
dhclient wlan1

Ora saremo collegati ad entrambe le reti. Nota: su altre distribuzioni potrebbe essere necessario utilizzare dhcpcd al posto di dhclient.

Ed ora come prima procediamo al bonding delle interfacce:

modprobe bonding mode=0 miimon=100

ifconfig wlan0 down
ifconfig wlan1 down

ifconfig bond0 hw ether 00:11:22:33:44:55
ifconfig bond0 192.168.55.55 up

ifenslave bond0 wlan0
ifenslave bond0 wlan1

Esattamente come prima.

Questo esempio non l’ho provato personalmente e potrebbe esserci qualche problema con wpa_supplicant quando le interfacce vengono spente. Tuttavia ho voluto comunque mostrarlo giusto per dare un’idea di quello che bisogna fare e per introdurre al prossimo passo.

Ricordiamoci sempre:

echo 0 > /proc/sys/net/ipv4/conf/wlan0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/wlan1/rp_filter

Reti wireless completamente separate o rete unica limitata

Come detto prima, il fatto di avere una linea a monte veloce e solo “colli di bottiglia” sugli access points è una cosa abbastanza rara. Solitamente se siamo in una situazione del genere è perché dal nostro computer possiamo collegarci a due reti wireless diverse, collegate a due linee completamente separate tra loro e con indirizzi diversi (magari nella stessa sottorete locale 192.168.0.x, però comunque i dati dell’una non transitano sull’altra e viceversa).
Situazione leggermente diversa ma completamente analoga dal punto di vista tecnico è invece quando siamo collegati ad un unico access point che ci immette in una rete dove la banda è limitata per ogni indirizzo ip o mac address e non possiamo ricevere i pacchetti degli altri host. In una rete del genere, a differenza del caso precedente, non possiamo fare bonding perché comunque riunendo le interfacce in una unica l’ip e il mac address sarebbero unici, rendendo vana l’operazione di bonding (permane la limitazione di banda).

Un modo leggermente complicato ma funzionante che ho personalmente escogitato a seguito di una serie di tentativi è quello che vi spiegherò qui di seguito.

L’idea principale è: ok, non possiamo in nessun modo fare bonding sulla rete perché sono separate tra di loro e hanno indirizzi diversi etc.., però se io in qualche modo riesco a collegarmi ad entrambe e quindi ad aprire una VPN su ciascuna delle due, e la VPN è di tipo TAP (simula completamente il protocollo ethernet), ed è unificata come indirzzi etc.. Posso in linea teorica mettere in bonding non le interfacce wireless ma le interfacce TAP della VPN e aumentare la banda. Ovviamente questo ha il “costo” di dover avere un server OpenVPN raggiungibile da entrambe le reti. Se le reti sono collegate entrambe ad Internet ci basta avere un server OpenVpn accessibile direttamente da Internet.

Riprendiamo l’esempio di prima e supponiamo che le reti “Rete1” e “Rete2”  siano totalmente scorrelatte tra loro. Se troviamo un modo per aprire un processo di openvpn su wlan0 (che si collega a “Rete1”) e un altro processo di openvpn (che si collega a “Rete2”) avremo due interfacce di tipo TAP chiamate ad esempio tap0 e tap1.
Le vpn avviate sono due istanze della stessa.

Il fatto di mettere in bonding tap0 e tap1 implica che esse perderanno il proprio ip della vpn (ad esempio 10.0.0.2 e 10.0.0.3) per conferire un unico indirizzo a bond0 (ad esempio 10.0.0.4) ed un unico mac address. Questo non è un problema dal momento che stiamo usando interfacce di tipo TAP, infatti TAP simula ethernet e dunque la situazione dal punto di vista del bonding sarà esattamente la stessa del primo esempio che abbiamo visto con la rete cablata!

Come detto prima lo stesso esempio è valido anche per reti a banda limitata. Supponiamo ci sia una rete chiamata “Rete1” a cui ci colleghiamo con entrambe le interfacce wifi. La limitazione ci viene applicata in base all’ip e/o mac address oppure anche a livello di certificato/password di autenticazione. Nessun problema:in ogni caso ci colleghiamo due volte con le due interfacce alla stessa rete ed abbiamo due ip e due mac address distinti (chi controlla la rete wireless non riuscirà a capire che la connessione avviene dallo stesso computer) e apriamo due VPN, poi mettiamo in bonding le interfacce della VPN e abbiamo raddoppiato la banda! Magari la rete ci limita tanto ma ha grande banda in realtà.. Dunque nessuno ci vieta di creare 30 interfacce wireless virtuali e 30 vpn, una per ciascuna interfaccia wireless virtuale, e poi mettere in bonding le 30 vpn. In linea teorica possiamo proseguire all’infinito, supposto che il server della VPN abbia ovviamente più banda di quella che ci viene limitata.. Se il serve della vpn è collegato ad internet con una linea da 1Mb/s, sicuramente in ogni caso con questo metodo non potremo superare quella velocità. Comunque dimenticando questo piccolo dettaglio (se come server VPN usiamo un server hostato in qualche serverfarm avremo probabilmente una linea da 100Mb/s) il numero di interfacce wifi virtuali è potenzialmente illimitato!
Ovviamente dopo un certo numero di interfacce inizieremo ad avere un carico del sistema esagerato e forse non riusciremo più ad aumentare la banda a causa del casino di pacchetti in gioco.. Però non ho dati per confermarlo.

È vero: sembra tutto molto facile, però c’è un dettaglio su cui ho puntato poco l’attenzione. Abbiamo detto che per poter fare tutta questa bellezza è necessario avviare diversi processi di openvpn che “escano” ciascuno su una interfaccia wireless diversa. La cosa non è per niente banale, infatti nella configurazione di OpenVpn non è possibile specificare una interfaccia di rete da cui collegarsi (come in nessun altro programma, a meno che utilizzi socket raw), inoltre per come sono strutturate le tabelle di routing, esiste sempre una ed una sola regola per decidere come indirizzare il traffico, la così detta “route default”, quindi tutti gli openvpn andrebbero ad uscire dalla stessa scheda, lasciando inutilizzate le altre. Non è quello che vogliamo noi!

Ma non disperate, c’è un hack anche per questo!

In iptables, il gestore delle tabelle di netfilter (il modulo del kernel Linux che si occupa della rete, firewalling etc..), esiste una “tabella” chiamata “mangle” che permette di applicare dei marcatori a dei pacchetti sotto alcune condizioni. Inoltre tramite il comando “ip”, che gestisce il routing del sistema, è possibile creare delle tabelle di routing “alternative” se il pacchetto in arrivo è stato marcato dalla tabella mangle.
Uno dei metodi che supporta iptables per marcare i pacchetti è quello di guardare il GID (Group ID), cioè il gruppo a cui appartiene il processo che ha originato il pacchetto.

Beh ma allora è fatta! I passi che dovremo seguire sono questi: avviamo ogni processo di OpenVpn con un gruppo diverso (il comando sg cioè “Set Group” permette di impostare il gruppo a cui appartiene un certo processo da eseguire), poi impostiamo iptables mangle di modo che quando vede un pacchetto in uscita proveniente da un certo gruppo assegna un certo marcatore. Infine facciamo in modo (mediante il comando ip per gestire le tabelle di routing), che quando c’è un pacchetto in uscita con un certo marcatore applicato, venga utilizzata una certa regola di routing e che esca quindi su una certa interfaccia di rete specifica! È fatta! Possiamo far uscire ogni processo di OpenVpn da una interfaccia virtuale diversa! Ricordiamoci alla fine di tutto di impostare il gateway di default nuovo che sarà il server della vpn (che deve essere abilitato per fare masquerading). Ovviamente ci sono tanti altri piccoli dettagli in più, li vediamo ora.

Riassumiamo i vari comandi principali da eseguire nel caso di due interfacce virtuali, due gruppi wifi0 e wifi1 esistenti nel sistema:

modprobe -r ath5k
modprobe ath5k nohwcrypt=1

iw phy phy0 interface add wlan1 type station

echo 0 > /proc/sys/net/ipv4/wlan0/rp_filter
echo 0 > /proc/sys/net/ipv4/wlan1/rp_filter

macchanger -A wlan1

ifconfig wlan0 up
iwconfig wlan0 essid “Rete”
wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf &
dhcpcd -p wlan0
killall dhcpcd

ifconfig wlan1 up
iwconfig wlan1 essid “Rete”
wpa_supplicant -Dwext -iwlan1 -c/etc/wpa_supplicant.conf &
dhcpcd -p wlan1
killall dhcpcd

iptables -t mangle -A OUTPUT -m owner –gid-owner wifi0 -j MARK –set-mark 1
iptables -t mangle -A OUTPUT -m owner –gid-owner wifi1 -j MARK –set-mark 2

iptables -t nat -A POSTROUTING -o wlan0 -m mark –mark 01 -j SNAT –to-source  IP_DI_WLAN0
iptables -t nat -A POSTROUTING -o wlan1 -m mark –mark 02 -j SNAT –to-source  IP_DI_WLAN1

ip rule add fwmark 1 table 1
ip rule add fwmark 2 table 2

ip route add default via GATEWAY__DEFAULT_DI_WLAN0 dev wlan0 table 1
ip route add default via GATEWAY__DEFAULT_DI_WLAN1 dev wlan1 table 2

sg wifi0 -c “openvpn –config /etc/openvpn/client.conf” –ifconfig 10.0.0.2 255.255.255.0″
sg wifi0 -c “openvpn –config /etc/openvpn/client.conf” –ifconfig 10.0.0.3 255.255.255.0″

modprobe bonding miimon=100 mode=0

ifconfig tap0 down
ifconfig tap1 down

ifconfig bond0 hw ether 00:22:13:72:A1:5A
ifconfig bond0 10.0.0.4 up

ifenslave bond0 tap0
ifenslave bond0 tap1

route del default dev wlan0
route del default dev wlan1

route add default gw 10.0.0.1 dev bond0
echo “nameserver 208.67.222.222” > /etc/resolv.conf

Ancora come prima sorridiamo all’idea che utilizzando questa configurazione non solo aumentiamo la banda, ma possiamo garantirci sempre la connettività se una delle due reti dovesse “cadere” e possiamo inoltre aggiungere altre in tempo reale con relativamente poche operazioni!

Per altri dettagli sul modulo bonding vi rimando a questa pagina di documentazione.


DNS tunneling

05Feb11

Qualche volta può capitare di trovarsi, per vari motivi, collegati ad una rete wifi o cablata che è in qualche modo connessa ad Internet, ma non ci potete accedere direttamente.

Se sulla stessa rete c’è un server DNS, oppure vi è permesso in generale effettuare connessioni su Internet ma solo verso server DNS, iodine potrebbe fare al caso vostro. Iodine è infatti un programma, composto da una parte server-side e una parte client-side che vi permette di stabilire un tunnel di scambio dati, basato sull’invio e la recezione di richieste DNS. Le possibilità sono due:

Rete che permette connessioni verso server DNS arbitrari

Cioè stiamo parlando di una rete in cui i dati che voi mandate su internet vengono filtrati e accettati solo se sono diretti alla porta UDP 53 di qualche server, oppure se una volta analizzati risultano richieste di tipo DNS.

In questo caso la questione è abbastanza semplice. Andiamo su un nostro server con indirizzo pubblico e lanciamo

iodined -f 10.0.0.1 dominio.test

Ci sarà richiesta una password, che sarà poi utilizzata per autenticarci nel tunnel (è una protezione molto blanda, non fateci troppo affidamento); il “dominio.test” in questo caso non ha rilevanza e può essere qualunque cosa (purché poi lo si usi uguale sul client), vederemo nel prossimo esempio a cosa serve.
Sul server sarà creata una interfaccia di tipo TUN con nome “dns0”, che avrà indirizzo 10.0.0.1 come specificato dal parametro passato

A questo punto andiamo sul client e lanciamo il programma che si collegherà a iodoned sul nostro serve e farà viaggiare i pacchetti sulle richieste DNS

iodine -f 123.456.789.10 dominio.test

Dove 123.456.789.10 è l’ip del nostro server, che in questo caso farà da “finto” server dns. Ci sarà richiesta la password e inseriamo la stessa di prima. Il programma procederà poi a calcolare la dimensione dei pacchetti da utilizzare per la comunicazione andando a tentativi.
Ovviamente anche sul client avremo una interfaccia “dns0” con il relativo ip, probabilmente successivo a quello del server, quindi 10.0.0.2

Io in diversi test la rete 10.0.0.0 l’avevo già occupata, e per non fare confusione ho utilizzato la 172.16.0.0

Rete che permette connessioni verso un unico server DNS

Siete in una rete da cui non potete in nessun modo accedere ad internet, però con qualche colpo di nslookup vi accorgete che il DNS della rete locale/DNS predefinito assegnato dal dhcp, vi risolve qualunque indirizzo.
Anche qui iodine vi da una comoda mano, ma questa volta bisogna aggiungere alcuni dettagli.

Questa volta il tunnel funzionerà in modo diverso: non vi collegherete infatti direttamente all’altro capo, ma dovrete passare sempre per l’intermediario che è il server DNS della rete locale.

Supponiamo di avere un dominio mydomain.com , possiamo andare nel pannello di amministrazione del nostro dominio impostiamo che ad esempio tutte le richieste dirette a test.mydomain.com  e i relativi sottodomini vadano inoltrate a un certo server, che le gestirà.
Questo è possibile realizzarlo mediante un record di tipo “NS” nella tabella dei record del nostro dominio.

Magari abbiamo due record di questo tipo:

myserver       A       123.456.789.10
test       NS       myserver.mydomain.com.

In questo modo, se chiediamo al server DNS nella nostra rete locale di risolvere l’indirizzo aaaaaa.test.mydomain.com, lui andrà a vedere i record del dominio mydomain.com e noterà che test.mydomain.com viene affidato tramite NS ad un altro server, quindi contatta infine il server myserver.mydomain.com per richiedergli quale sia l’indirizzo associato a aaaaaa.test.mydomain.com .
Ovviamente nelle risposte il server potrà inserire tante informazioni, e dentro lì “nasconderà” i dati da inviare al client dall’altra parte del tunnel.

Supponiamo allora di aver impostato i nostri record del dns come mostrato sopra. A questo puto ci basterà rifare lo stesso comando dato prima sul server, con l’opportuno dominio:

iodined -f 10.0.0.1 test.mydomain.com

E allo stesso modo sul client:

iodine -f 123.456.789.10 test.mydomain.com

È importante in questo caso ricordare che appena possibile il DNS della nostra rete locale tenterà di fare la cache di quello che può, quindi se sbagliamo a impostare i record DNS e glieli facciamo risolvere, anche se poi li sistemiamo lui probabilmente avrà in cache ancora quelli errati.

Qualche volta non si capisce niente se sta funzionando o meno il tunnel, quindi i creatori di iodine hanno messo a punto una comoda pagina, in cui se inserite il vostro dominio di tunnel, loro tenteranno di collegarvisi e comparirà sulla pagina stessa se è funzionante o no. Eccola: http://code.kryo.se/iodine/check-it/

Suggerimenti

Uscire su Internet

“Sì, ok ho fatto tutto, ma ora? Posso solo fare il ping del mio host remoto, non posso uscire su Internet!”

Beh, poco ci vuole, basta che sul server preparate una NAT:

echo “1” > /proc/sys/net/ipv4/ip_forward

iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -j MASQUERADE

Se avete la policy DROP sulla chain FORWARD di iptables dovete aggiungere anche:

iptables -A FORWARD -s 10.0.0.0/24 -j ACCEPT

iptables -A FORWARD -d 10.0.0.0/24 -j ACCEPT

Mentre invece sul client dovremo prima aggiungere una regola statica di routing per il DNS della rete locale (altrimenti salta il tunnel quando cambiamo le route) e poi togliere la default e aggiungere la nuova:

route add IP_DNS_RETE_LOCALE gw GATEWAY_LOCALE

route add default gw 10.0.0.1

Abbiamo ipotizzato fino ad ora che il server DNS della rete locale risolva qualunque cosa, quindi non vi servirà cambiarlo, se volete farlo allora è consigliabile specificare l’ip del server dns della rete locale a iodine.

Sicurezza

La sicurezza della password per accedere al tunnel, come già detto è molto blanda. Se non ci sono eccessivi cali di prestazioni vi consiglio di non seguire quanto detto prima per uscire su internet e mettere una VPN sul vostro server ed uscire su internet una volta effettuato l’accesso a quella.

Versioni incompatibili

Fate molta attenzione alle versioni di iodine su server e client, se sono release di date molto diverse potrebbe non funzionare nulla!
Per controllare la versione lanciate (ovviamente):

iodine -v