Negli ultimi tempi mi è capitato spesso di dover sviluppare ed eseguire dei programmi sul mini-computer più famoso al giorno d’oggi: il raspberry pi. Nel contesto del laboratorio universitario in cui mi sono trovato a farlo ho dovuto però gestire l’impossibilità di avere le periferiche adatte per lavorare direttamente su di esso: monitor, tastiera e dongle wi-fi per connettermi ad internet in caso di necessità. Cercando una soluzione online non ho avuto molta fortuna, mi sono quindi rivolto al mio insegnante (che ringrazio) per capire come poter fare per programmare sulla piccola scheda avendo come unico tramite il mio computer portatile. La soluzione fornitami, e che oggi vi ripropongo in versione generalizzata e non strettamente legata al raspberry pi (che da adesso in avanti chiamerò dispositivo client), è stata quella di collegare la scheda con un cavo ethernet al mio pc e comandarla tramite ssh (Secure Shell). Bisogna però tenere conto del fatto che per poter raggiungere questo obiettivo è indispensabile che il dispositivo client ottenga in qualche modo un indirizzo IP per poterlo identificare all’interno della rete, e questo lo si fa configurando opportunamente un semplice server DHCP (Dynamic Host Configuration Protocol) che giri sul nostro sistema. Premettendo che oggi non entreremo nel merito di ssh (che magari esploreremo con una guida a parte), quello che andiamo a fare è vedere come settare il nostro server DHCP e condividere con il dispositivo client la connessione ad internet.  Il programma che andremo ad utilizzare per configurare il nostro server si chiama, come da titolo, dnsmasq,  ed è presente sulle repository ufficiali di molte distribuzioni risultando quindi installabile tranquillamente tramite il vostro gestore di pacchetti preferito, ma in caso non lo fosse, potete scaricarne i codici sorgenti da qui. Come al solito vi ricordiamo che il sistema su cui si basa la guida è Debian 8.4, ma tutti i passaggi dovrebbero rimanere validi per qualunque altra distro. Una volta installato dnsmasq possiamo procedere con la guida vera e propria:

Informazioni preliminari

Prima di cominciare è necessario conoscere il nome con cui il nostro sistema identifica le nostre interfacce di rete, solitamente la porta ethernet viene identificata con eth0 e la scheda del wi-fi con wlan0, ma, specie nei portatili usciti di recente, la nomenclatura potrebbe essere differente. Per toglierci ogni dubbio ci basta dare da terminale il comando:

$ sudo ifconfig

il cui risultato dovrebbe darvi qualcosa del genere:

dnsmasq-2

I nomi a sinistra sono quelli che ci interessano e che utilizzeremo nei passi successivi di questa guida.

Configurazione di dnsmasq:

Per poter configurare il programma, tutto quello che è sufficiente fare è andare a modificare il file dnsmasq.conf che trovare all’interno della cartella /etc. Qui vi mostro come farlo utilizzando il terminale e l’editor di testo nano. Il comando che ho utilizzato è:

$ sudo nano /etc/dnsmasq.conf

La schermata che vi si dovrebbe proporre dovrebbe essere molto simile a questa:

dnsmasq-1

Se masticate un pochino l’inglese non vi dovrebbe risultare troppo complicato capire qual’è la funzione di ogni riga, sono tutte ben commentate e forniscono una chiara spiegazione di tutte le opzioni. Fortunatamente non è necessario settare tutto quanto, vi mostrerò quindi le opzioni minime da modificare per le funzionalità che servono a noi. In particolare, le voci che andremo ad editare sono quelle relative a:

  • Interfaccia utilizzata: nel nostro caso la porta ethernet, in questo modo impediamo anche che venga utilizzata la scheda wifi per fornire indirizzi a dispositivi nei paraggi involontariamente;
  • Indirizzo di ascolto: la sotto-rete da noi definita ed il localhost;
  • Range di indirizzi assegnabili ed intervallo di tempo per cui viene mantenuto un indirizzo: questo parametro è fondamentale per essere sicuri di non utilizzare gli indirizzi di una sottorete già popolata andando a causare problemi agli altri utenti, anche se il rischio dovrebbe essere eliminato con l’opzione riguardante l’interfaccia modificata prima. A parte la sicurezza questa informazione è utile nel caso in cui avessimo bisogno di trovare velocemente l’IP assegnato al nostro dispositivo client (per esempio per accedervi via ssh).

Per inserire le modifiche potete decommentare rimuovendo il cancelletto ed aggiungendo le informazioni giuste alle righe di interesse oppure potete aggiungere alla fine del file queste righe (opportunamente modificate con le informazioni giuste per voi):

interface=eth0
listen-address=192.168.5.1,127.0.0.1
dhcp-range=192.168.5.50,192.168.5.150,12h

Una volta fatto questo siamo pronti per passare allo step successivo.

Configurazione di una connessione manuale

In questo passaggio vediamo come inserire un profilo di connessione attivabile manualmente in modo da poter sfruttare il meccanismo definito prima solo quando è effettivamente necessario. Se per esempio ci stessimo connettendo via ethernet ad un router, dovrebbe fornire lui un indirizzo al nostro computer e non il contrario, quindi abbiamo bisogno di poter scegliere il profilo di connessione da utilizzare. Ho cercato diverse volte di effettuare questa procedura utilizzando il terminale per fornire una guida il più generale possibile, ma ahimè utilizzando l’interfaccia testuale ho sempre fallito ed il profilo di connessione non veniva riconosciuto. Ho dovuto ripiegare sulle funzionalità del mio desktop environment per compiere questa operazione. Spero possa essere di consolazione il fatto che questo passaggio è stato testato da me ed i miei colleghi su KDE 4 (che vedrete qui), GNOME 3, Cinnamon Unity ed in tutti i casi le finestre erano pressoché identiche ed ha sempre funzionato tutto. Per impostare la nostra connessione manuale dobbiamo:

  • Aprire il nostro editor delle connessioni (nel mio caso dal vassoio di sistema);
  • Cliccare su “aggiungi nuova connessione“;
  • Selezionare “cablata“;
  • Aprire la scheda relativa alle impostazioni di “IPv4

A questo punto dovete inserire le informazioni (Metodo, Server DNS, Indirizzo, Maschera di rete e Gateway) come nella finestra qui sotto stando attenti ad utilizzare per l’indirizzo e per il gateway lo stesso valore che avete utilizzato all’interno del file dnsmasq.conf:

dnsmasq-3

Come ultimo passaggio cliccate sul pulsante “Rotte” che vedete in basso (in altri desktop environment è stato tradotto come “instradamenti“, in inglese sarebbe “routes” o “routing“) e mettete la spunta su “utilizza solo per le risorse su questa connessione“:

dnsmasq-4

NOTA BENE: questo punto è fondamentale perché, senza questa apparentemente insignificante spunta, andando ad utilizzare il profilo di connessione manuale, se stiamo utilizzando contemporaneamente anche la connessione wi-fi quest’ultima verrà disattivata e non potremo raggiungere quello che è lo scopo di questa guida.

Arrivati a questo punto non ci resta che procedere con l’ultimo passo:

Condivisione delle rete col dispositivo client

Senza perderci in dettagli tecnici, il modo più semplice per poter abilitare permanentemente questa funzione è quello inserire un paio di righe nello script rc.local (presente all’interno di /etc) che viene eseguito all’avvio del sistema. Per farlo è sufficiente utilizzare il comando:

sudo nano /etc/rc.local

ed aggiungere in fondo al file queste righe:

iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
iptables -A FORWARD -i wlan0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan0 -j ACCEPT
/etc/init.d/dnsmasq restart

In questo modo è anche possibile effettuare il forwarding dei dati dalla porta ethernet verso la scheda wi-fi, ma questo esula dallo scopo della guida, quindi non approfondiremo oltre. L’ultima riga invece riavvia dnsmasq in modo che sia abilitato a ricevere i dati inviati dalla scheda wi-fi. L’ultima cosa da fare è abilitare l’ip-forwarding andando a modificare il file sysctl.conf (presente anch’esso in /etc) con il comando:

sudo nano /etc/sysctl.conf

ed aggiungere (o modificare il valore se già presente) la riga seguente:

net.ipv4.ip_forward = 1

A questo punto dal prossimo avvio, collegando un dispositivo via ethernet dovremo scegliere manualmente il profilo di connessione da noi impostato ed il client riceverà automaticamente un indirizzo IP e, se il nostro computer è connesso, sarà automaticamente collegato ad internet.

Spero di esservi stato utile con questa guida, se avete dubbi o domande non esitate a lasciare un commento!

Post scriptum: su vostra segnalazione (e per questo ringrazio l’utenza che collabora attivamente con noi per migliorare il nostro lavoro) vi faccio presente che è FORTEMENTE SCONSIGLIATO collegarsi con il profilo creato utilizzando questa guida ad una rete dove è già presente un server DHCP in quanto potrebbe causare dei malfunzionamenti piuttosto seri su tutta quanta la rete.

  • Kib

    Sto lottando anche io in questi giorni con le configurazioni di rete e mi chiedo
    visto che le regole di iptables servono solo in alcuni casi, invece di caricarle ad ogni avvio (rc.local) non sarebbe meglio salvarle su un file e caricarle in iptables con ‘:-$ iptables-restore iptablesRules.share’?

    • Leonardo Bertazzolo

      Probabilmente hai ragione, la tua soluzione è senz’altro “più pulita” , purtroppo non ho avuto tempo di esplorare per bene questo tipo di soluzione e, visto che io ci lavoro tutti i giorni almeno al momento, ho voluto fornire qualcosa che ero sicuro che funzionasse subito. Inoltre non volevo complicare troppo la guida per chi è ancora alle prime armi, magari più avanti faremo qualcosa di più dettagliato e più adeguato in merito 🙂

      • Samael

        Io uso la stessa pratica di Kib per le regole relative ad rtmpdump. 🙂

        Ho dato le regole nella command line, come hai fatto vedere tu, e poi ho creato un file chiamato /etc/firewall/rules.conf tramite iptables-save.
        Poi da lì ho uno script INIT personale /etc/rc.d/rc.firewall che attivo quando serve e che carica iptables-restore se è in start o fa il flush se è in stop.

        • Kib

          questa della regola sotto rc.d mi piace un sacco. Grazie

  • Massimo A. Carofano

    Grandi ragazzi!
    Prossima guida “come condividere la connessione wifi del pc tramite usb con un tablet android”???

  • michele casari

    hai fisicamente un cavo che va dal raspberry al tuo portatile? In tal caso no dovrebbe essere un cavo cross?

    • El Ninho

      stavo per dire la stessa cosa. il cavo normale serve solo per il router altrimenti sai quante testate al muro danno quelli che provano la guida

    • jboss

      le ultime schede di rete (già da 15 anni )non hanno bisogno di cavi cross

      • El Ninho

        Ne sei sicuro a me non risulta

        • Leonardo Bertazzolo

          Se devo essere onesto non ho mai verificato se il cavo fosse cross o meno, ho utilizzato diversi (una decina) cavi senza pormi il quesito ed ha sempre funzionato sia col raspberry (modelli 1, b+ e 2 model b) e anche con altri portatili collegati. Magari è solo una coincidenza ed erano tutti cavi cross ma sinceramente non credo.

    • Kib

      Solitamente con il cavo cross vai di IP fisso non con il DHCP o sbaglio?

  • Alicia Frantinelli

    Ciao,
    penso valga la pena sottolineare di non collegare il dispositivo così configurato (con server DHCP) in una rete dove c’è già un altro server DHCP, altrimenti potrebbero verificarsi seri malfunzionamenti.

    • Leonardo Bertazzolo

      Ciao, hai perfettamente ragione, in effetti pensavo si intendesse quando ho scritto di specificare l’interfaccia durante la configurazione, ma rileggendo mi rendo conto che forse non ci ho calcato abbastanza su questo aspetto, aggiungerò quanto prima una nota, grazie della segnalazione! 🙂

      • Kib

        Questo non l’ho capito. Perchè dovrebbe creare dei problemi?
        Quando configuri Dnsmasq definisci una sotto rete, i client che ti utilizzeranno come DHCP non avranno mai IP uguali ai client collegati al DHCP Generale della LAN.

        Sbaglio? O forse non ho capito la natura del problema

        • Leonardo Bertazzolo

          Se configuri tutto esattamente come nella guida qui sopra in effetti non dovrebbe dare alcun tipo di problema perchè la sotto rete è in un range che difficilmente viene utilizzato in reti di utilizzo comune, ma se per caso la rete in cui vai a finire tu usa gli stessi indirizzi del range definito da te la cosa potrebbe generare conflitti. L’aver definito come unica interfaccia di utilizzo la sola porta ethernet dovrebbe costituire un’ulteriore protezione, ma sai com’è ,non si sa mai che ti trovi nelle circostanze sbagliate al momento sbagliato e vai a finire in quell’unica rete nel raggio di 7 province che fornisce connessione via ethernet, tu ti colleghi, selezioni per sbaglio il profilo manuale e finisci per dare indirizzi a casaccio a tutti i pc collegati. Insomma è un rischio abbastanza piccolo, ma c’è.

  • giovanni

    Chiedo scusa se vado in OT, ma vista la bravura dell’autore dell’articolo volevo approfittare per chiederti se puoi aiutarmi a risolvere un problema che non riesco a risolvere. Io uso debian e sia prima con iceweasel che adesso con firefox, non mi riproduce i video di quattroruote. Aggiungo che se installo firefox di mint o ubuntu o pacchettizzato da altre distro, il tutto funziona tranquillamente. Inoltre in about:config i mediasource sono su true. Grazie in anticipo per l’aiuto.

    • Leonardo Bertazzolo

      Ciao Giovanni, facendo un piccolo test con iceweasel ho constatato il tuo stesso problema. Documentandomi un po’ su internet mi pare di capire che il problema risiede nel fatto che le attuali versioni di iceweasel e firefox utilizzate per la versione stabile di debian non hanno più il supporto per gstreamer. L’unico modo per risolvere il problema sembra essere installare una versione che lo contenga o compilarseli dai sorgenti ed attivarlo con l’opzione relativa. Se non ho capito male (ma ti confesso di aver dato solo una letta veloce)pare che le versioni incluse in debian testing lo abbiano reintrodotto.

      • giovanni

        Grazie per la risposta. In questo momento sto usando debian testing con firefox 45 esr e purtroppo NON si riesce a riprodurre i video. Un vero peccato, anche se ci vogliono 2 minuti per installare una versione diversa è un po una rottura perchè quando esce la nuova versione tipo ora con la 42, non sia aggiorna dai repo ma devi andare a cercartela. Grazie comunque.

No more articles