Condividere la connessione a internet: differenze tra le versioni

Da Guide@Debianizzati.Org.
Vai alla navigazione Vai alla ricerca
m (→‎Configurazione Router: formattazioni e piccole modifiche)
m (→‎Masquerading: errori nomi script (segnalato in pagina discussione))
 
(17 versioni intermedie di 8 utenti non mostrate)
Riga 1: Riga 1:
{{stub}}
{{Versioni compatibili|Jessie|Stretch|Buster}}
==Come effettuare una connessione remota SSH da Windows a Linux==
== Premessa ==
Oggi che la maggior parte degli utenti domestici ha la possibilità di accedere ad Internet con connessioni a [http://it.wikipedia.org/wiki/Larghezza_di_banda banda] larga (ad esempio [http://it.wikipedia.org/wiki/ADSL ADSL]) e che è sempre più frequente avere a disposizione almeno un paio di computer, si avverte la necessità di poter condividere la connessione tra i vari computer della nostra rete domestica.


Ho deciso di fare questa guida poich� ho avuto molta difficolt� a creare una connessione remota sicura fra una macchina Windows ed una Linux in una LAN (o in una WAN) in quanto la maggior parte delle guide, degli How-To e delle FAQ che ho trovato in Internet esamina tale connessione fra due macchine Linux.
GNU/Linux è probabilmente la scelta più indicata in questi frangenti, essendo un sistema operativo nato espressamente in ambiente di rete: moltissimi dei [http://it.wikipedia.org/wiki/Router router] sul mercato fanno uso di GNU/Linux come sistema operativo, perché non farlo anche noi?


La connessione remota sicura che esaminero` e` detta '''connessione SSH''' (Secure SHell) che si basa sulla [http://it.wikipedia.org/wiki/Crittografia_asimmetrica criptografia asimetrica] detta anche '''criptografia a coppia di chiavi''' o, piu` semplicemente, '''a chiave pubblica/privata''' (o, semplicemente, '''a chiave pubblica''') che consiste nella generazione di una coppia di chiavi (chiamate [http://it.wikipedia.org/wiki/Chiave_privata chiave privata] e [http://it.wikipedia.org/wiki/Chiave_pubblica chiave pubblica]). In pratica, la '''chiave pubblica''' codifica la communicazione mentre la '''chiave privata''' decodifica tale comunicazione e vengono generate usando degli algoritmi asimetrici che sono [http://it.wikipedia.org/wiki/RSA RSA] e '''DSA''' e le connessioni che usano tali coppie di chiavi prodotte da questi algoritmi asimetrici sono dette '''connessioni SSH'''. Tali algoritmi, pero`, servono soltanto per instaurare una connessione criptata fra il client SSH e il server SSH in quanto, per il trasferimento vero e proprio dei dati, si usano degli algoritmi simmetrici, come AES o 3DES, che sono molto piu` efficenti per questo scopo ovvero per cifrare la comunicazione. Quindi:
== Prerequisiti ==
Tutto quello di cui abbiamo bisogno è la nostra Debian, una scheda di rete per ciascun PC da collegare alla rete locale ed un hub o switch.


Una '''[[connessione SSH]]''' e` una connessione cifrata che utilizza gli algoritmi asimetrici RSA o DSA soltanto per verificare se una chiave pubblica, memorizzata sul server, derivi da una chiave privata salvata sul client (in modo da garantire la reciproca autenticita` del server e del client) in modo da essere utilizzata, per l'intera sessione, per la cifratura simmetrica con algoritmi come AES o 3DES.
Se avete un collegamento ADSL tramite modem USB e due soli computer, basta collegare le due schede di rete tramite cavetto ethernet cross (incrociato), non serve nient'altro. Uno dei due computer dovrà poi essere connesso ad internet tramite modem USB (vedere [[Indice_Guide#Modem_e_periferiche_di_rete|Modem e periferiche di rete]] per l'installazione e la configurazione), oppure tramite una seconda scheda di rete.


Per fare in modo che Debian si comporti come un router avremo bisogno anche di ''iptables''. Vi rimando alla guida [[Debian e iptables]] per la sua corretta installazione e configurazione.


== Configurazione Router ==
Per fare in modo che Debian faccia da [http://it.wikipedia.org/wiki/Gateway gateway] tra i PC della LAN e internet dobbiamo utilizzare il [http://it.wikipedia.org/wiki/Network_address_translation NAT] ''(Network Address Translation)''.<br>
Il tipo di NAT che ci interessa in questa guida è chiamato '''masquerading''' ''(mascheramento)'' degli indirizzi locali.<br>
Il motivo è semplice: per accedere a internet è necessario avere un [http://it.wikipedia.org/wiki/Indirizzo_IP indirizzo IP] di tipo pubblico, che il nostro ISP ci fornisce. Per permettere anche ai computer sprovvisti di indirizzo pubblico di navigare, dobbiamo fare in modo che i loro indirizzi di tipo privato vengano "nascosti" dietro a quello pubblico.


=== Masquerading ===
Con [[privilegi di amministrazione]] digitiamo il seguente comando:
<pre># iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE</pre>
questo abilita il mascheramento degli indirizzi privati.


Nel caso il computer che fa da router sia collegato ad internet mediante un'altra interfaccia di rete (di solito ethx), al posto di ppp0 va messo il nome di quest'ultima e quindi diventa:
<pre># iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE</pre>


Per caricare queste regole di ''iptables'' ad ogni avvio conviene salvarle una volta e per tutte con '''iptables-save''' e caricarle ad ogni avvio con '''iptables-restore'''. Questi comandi leggono e scrivono su STDIN e STDOUT quindi bisogna usare la redirezione di shell.


----
Per salvare le regole correnti di ''iptables'' basta scrivere da ''root'':
<pre># iptables-save > /etc/iptables-save</pre>


: [[Utente:Balubeto|Balubeto]] 04:46, 29 Mag 2006 (EDT)
Poi ad ogni avvio dovremo richiamare il seguente comando:
<pre>
# iptables-restore < /etc/iptables-save
</pre>
 
Basta creare uno script in <code>/etc/network/if-up.d/</code> che esegua tale comando. Per esempio:
<pre>
# touch /etc/network/if-up.d/restore-iptables
</pre>
 
E poi modificare <code>/etc/network/if-up.d/restore-iptables</code> con il proprio editor di testo preferito (per esempio [[nano]]):
<pre>
#! /bin/sh
 
readonly CONFIG_FILE="/etc/iptables-save"
 
# execute the script only if $CONFIG_FILE exists
test -f "$CONFIG_FILE" || exit 0
 
# restore IP tables
printf %s " * Loading iptables saved state... "
iptables-restore < "$CONFIG_FILE" &&
printf %s\\n "[ OK ]"
</pre>
 
E renderlo eseguibile:
<pre>
# chmod a+x /etc/network/if-up.d/restore-iptables
</pre>
La regola verrà caricata ad ogni avvio del sistema, senza che sia necessario digitarla nuovamente, e solo se il file <code>/etc/iptables-save</code> esiste.
 
=== Ip Forwarding ===
Configurare ''iptables'' non è però sufficiente. I comuni PC, infatti, non devono essere in grado di comportarsi come i [http://it.wikipedia.org/wiki/Router router] e cioè non devono poter [[routing|instradare]] pacchetti da una rete all'altra.<br>
Dato che per noi è fondamentale abilitare questa possibilità, dobbiamo agire su un parametro del kernel che regola questa funzione: l' '''ip-forwarding'''.
 
L'ip-forwarding si può abilitare "al volo" semplicemente impostando a "1" la relativa variabile del kernel, con il comando:
<pre># echo 1 > /proc/sys/net/ipv4/ip_forward</pre>
così facendo, però, ad ogni riavvio dovremo reimpostare la variabile.
 
==== Impostare l'<code>ip-forwarding</code> al boot: <code>/etc/sysctl.conf</code> ====
 
Se avete installato ''ipmasq'', l'ip-forwarding è già abilitato: passate alle misure di sicurezza.
 
Il metodo più semplice, consigliato nella maggior parte dei casi, per impostare l'ip-forwarding ad ogni boot è di inserire in <code>/etc/sysctl.conf</code>:
 
<pre>
## Abilita il forwarding di pacchetti non locali - FONDAMENTALE
net/ipv4/ip_forward = 1
</pre>
In questo caso si abilita unicamente per IPv4; è necessario, se si desidera, abilitarlo anche per IPv6.
 
È opportuno impostare anche alcune misure di sicurezza (le prime due dovrebbero essere già attive di default):
<pre>
## Ignora finti messaggi di errore ICMP
net/ipv4/icmp_ignore_bogus_error_responses = 1
 
## Non risponde ai ping inviati al broadcast della subnet
net/ipv4/icmp_echo_ignore_broadcasts = 1
 
## Non accetta pacchetti ICMP di route redirection
net/ipv4/conf/all/accept_redirects = 0
 
## Protezione anti spoofing
net/ipv4/conf/all/rp_filter = 1
</pre>
 
==== Impostare l'<code>ip-forwarding</code> al boot: script ====
È possibile anche abilitare l'ip-forwarding associando uno script alla creazione delle interfacce di rete in fase di boot. Questo metodo è consigliato solo in caso di setup più complessi, in cui si vogliono impostare regole diverse a seconda dell'interfaccia di rete che si attiva.
 
Per prima cosa, apriamo con il nostro editor preferito il file <code>/etc/network/interfaces</code> e cerchiamo la sezione relativa alla nostra scheda di rete.
 
Dovreste individuare qualcosa di simile a:
 
<pre>
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
</pre>
 
A questo punto, nella riga immediatamente successiva a "broadcast ...", inseriamo questa direttiva:
 
<pre>
auto eth0
iface eth0 inet static
address 192.168.0.1
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
        pre-up /etc/network/iface-secure
</pre>
 
Questo comando dice allo script, che si occupa di configurare la scheda di rete, di lanciare un altro script, e cioè <code>/etc/network/iface-secure</code>, che provvediamo subito a creare con il comando:
 
<pre># touch /etc/network/iface-secure</pre>
 
Dopodiché rendiamolo eseguibile e scrivibile per [[root]] con:
 
<pre># chmod 755 /etc/network/iface-secure</pre>
 
All'interno di questo file scriveremo il nostro comando per abilitare l' ip-forwarding:
 
<pre>
#! /bin/sh
 
### Abilita il forwarding di pacchetti non locali - FONDAMENTALE
echo 1 > /proc/sys/net/ipv4/ip_forward
 
### Ignora finti messaggi di errore ICMP
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses
 
### Non risponde ai ping inviati al broadcast della subnet
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
 
### Non accetta pacchetti ICMP di route redirection
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects
</pre>
 
=== Server DNS ===
Per poter navigare su internet, è necessario che i PC della nostra rete locale abbiano accesso ad un server [[DNS]] che traduca per noi gli indirizzi internet in indirizzi IP.
 
Un modo per fare questo consiste nell'impostare, per ciascuno dei nostri PC, i server [[DNS]] forniti dal nostro provider.
 
Esiste tuttavia un'alternativa molto più comoda e performante: creare un nostro server [[DNS]] ed utilizzarlo in sostituzione di quelli del provider. Questa soluzione porta ad alcuni vantaggi:
* sui PC della LAN dovremo configurare sempre un solo server [[DNS]] immutabile e che conosciamo bene (senza faticose ricerche);
* i tempi di risposta sono nettamente più performanti rispetto a server esterni alla LAN, sia perché il server è raggiungibile direttamente (senza instradamento attraverso internet), sia perché sfrutta un sistema di cache (se 10 PC chiedono l' indirizzo di debian.org, ad esempio, il nostro [[DNS]] effettuerà la richiesta solo la prima volta e per le restanti 9 utilizzerà le informazioni memorizzate nella propria cache);
* grazie a questo meccanismo di caching i [[DNS]] del provider sono meno stressati e quindi più performanti a loro volta.
 
Per realizzare il nostro server useremo '''bind''', probabilmente il miglior software esistente per questo compito.
 
Per prima cosa installiamo ''bind9'' ed alcuni strumenti utili:
 
<pre># apt install bind9 dnsutils</pre>
 
Ora configuriamo il server in modo che faccia le sue richieste ai server [[DNS]] che vogliamo noi anziché ai ROOT SERVERS (sono pochi in tutto il mondo, molto stressati e aggiornati più lentamente di altri). Tutto quello che dobbiamo fare è editare la sezione '''options''' del file <code>/etc/bind/named.conf.options</code>:
 
<pre>options {
directory "/var/cache/bind";
 
forward first;
forwarders {
INDIRIZZO IP DNS PRIMARIO; #varia a seconda del provider
INDIRIZZO IP DNS SECONDARIO; #varia a seconda del provider
};
 
auth-nxdomain no; # conform to RFC1035
};</pre>
 
Ora non ci resta che riavviare ''bind'' con il comando:
 
<pre># service bind9 restart</pre>
 
e configurarlo come [[DNS]] sui PC della nostra rete.
 
=== Altri Protocolli ===
==== FTP ====
Con la configurazione svolta fino a questo punto dovrebbe essere possibile accedere dai PC della LAN a server FTP esterni in ''passive mode'' (se ciò non fosse possibile vedere più avanti: [[Condividere_la_connessione_a_internet#Problemi_con_MTU|Problemi con MTU]]).
 
Se si vuole accedere a server FTP in ''active mode'' il router deve tracciare le connessioni FTP, e a tal scopo basta caricare i due moduli:
 
<pre>
# modprobe ip_conntrack_ftp
# modprobe ip_nat_ftp
</pre>
 
Da questo momento in poi i PC della LAN dovrebbero essere in grado di accedere ai server FTP anche in ''active mode''.
 
==== IRC ====
Dovreste essere in grado di usare IRC senza problemi dai PC della vostra LAN. In caso contrario potreste provare a caricare manualmente i moduli che servono al router per gestire le connessioni ad IRC:
<pre>
# modprobe ip_conntrack_irc ports=5555,6666,6667,6668,6669,7000
# modprobe ip_nat_irc
</pre>
dove, con la direttiva "ports=" indichiamo le porte generalmente utilizzate dai server IRC.
 
Se avete problemi, leggete più avanti: [[Condividere_la_connessione_a_internet#Problemi_con_MTU|Problemi con MTU]].
 
== Configurazione LAN ==
Passiamo ora alla configurazione degli altri PC della nostra rete domestica.<br>
==== Premessa ====
Generalmente per le reti locali domestiche si utilizzano indirizzi IP del tipo 192.168.0.x, dove x è un numero variabile tra 1 e 254. Questo significa che all'interno della stessa rete possiamo avere fino a 254 indirizzi IP univoci.<br>
Generalmente il router di una rete ha come indirizzo IP il primo o l'ultimo della rete e cioè 192.168.0.1 oppure 192.168.0.254. In questo esempio noi useremo il primo.
=== Assegnare un IP ===
Ad ogni PC della LAN si deve assegnare un indirizzo IP per poter comunicare con gli altri PC della rete interna (che nel caso limite è il solo PC che fa da router). Per assegnare un indirizzo IP statico basta usare il comando:
<pre>
# ifconfig eth0 192.168.0.2 up
</pre>
dove 192.168.0.2 è l'indirizzo arbitrario che si è scelto per la particolare macchina.<br>
Il comando '''ifconfig''' permette di specificare molti più parametri ma, utilizzando l'indirizzo dell'esempio, questi verranno preconfigurati automaticamente.
Per non riscrivere questo comando ad ogni boot, si può inserire in <code>/etc/network/interfaces</code>:
<pre>
auto eth0
iface eth0 inet static
    address 192.168.0.2
    netmask 255.255.255.0
    network 192.168.0.0
    broadcast 192.168.0.255
</pre>
 
=== Impostare il gateway ===
Ora bisogna dire ad ogni macchina della LAN di instradare tutti i pacchetti diretti verso l'esterno al PC fisicamente collegato ad internet (che fa da router). A tal scopo basta impostare il ''default gateway'':
<pre>
# route add default gw 192.168.0.1
</pre>
Per non dover scrivere questo comando ad ogni riavvio, è sufficiente aggiungere al file <code>/etc/network/interfaces</code>, subito al di sotto della direttiva ''''broadcast ...'''' la seguente linea:
<pre>
  gateway 192.168.0.1
</pre>
 
=== Impostare il server DNS ===
Per impostare il server [[DNS]] che i nostri PC useranno è necessario editare il file <code>/etc/resolv.conf</code> inserendo la seguente linea:
<pre>nameserver 192.168.0.1</pre>
assicurandoci di scriverlo nella prima riga del file ''(L'ordine con cui il sistema interroga i [[DNS]] è identico a quello in cui compaiono in /etc/resolv.conf)''
 
=== Client Windows® ===
Per la configurazione di eventuali PC con installato Microsoft® Windows® vi rimandiamo alla Guida in Linea, al sito di supporto ed al vostro rivenditore hardware (che per contratto è tenuto a fornirvi assistenza).
 
== Problemi con MTU ==
Può capitare a volte, specialmente con collegamenti ADSL, che l'MTU impostato di default  per le interfacce di rete (1500) non sia appropriato e causi vari malfunzionamenti. Ad esempio, io non riuscivo ad usare wget, ftp, apt-get e irc. Altri hanno riportato di non potere accedere a certi siti.
 
Risolvere questo problema è semplice, basta impostare l'MTU di tutte le interfacce ethernet ad un valore più basso di 1500. A tal scopo basta aggiungere in <code>/etc/network/interfaces</code> una riga apposita:
 
<pre>
iface eth0 inet static
address 192.168.0.2
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
        mtu 1412
</pre>
 
Questo su tutti i computer della LAN e anche sul PC che funge da router. Se si ha poi una connessione ppp per collegarsi ad internet, sul pc-router bisognerà impostare l'MTU anche per questa interfaccia. Qui la configurazione potrebbe variare a seconda dei casi, ma usualmente è possibile impostare l'MTU in <code>/etc/ppp/options</code> e/o in <code>/etc/ppp/peers/tuo-provider</code>.
 
Riavviando ora tutte le interfacce di rete sia eth0 che ppp, avremo impostato il nuovo valore per l'MTU sperando di aver eliminato i malfunzionamenti.
 
== Test ==
Finalmente siamo arrivati al momento di testare la nostra rete domestica.
 
Nei prossimi minuti cercheremo di appurare se i vari elementi che abbiamo predisposto in precedenza sono effettivamente funzionanti e, se non lo sono, per quale motivo.
 
Per fare questo avremo bisogno di alcuni tra i più usati strumenti diagnostici: '''ping''' e '''nslookup''', ma non preoccupatevi: il primo viene installato automaticamente ed il secondo abbiamo provveduto ad installarlo contestualmente a ''bind''.
 
=== Comunicazione tra router e client ===
Prima di tutto annotiamo l'indirizzo IP del client (in questo esempio: 192.168.0.2).
 
Ora apriamo una shell sul PC che funge da router e digitiamo il comando:
<pre>
$ ping -c 4 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=1.41 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=0.953 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=255 time=0.988 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=255 time=1.02 ms
 
--- 192.168.2.0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.953/1.094/1.417/0.191 ms
</pre>
 
Per ora non ci interessa il significato dei messaggi a video, ma unicamente il fatto che dal router è effettivamente possibile raggiungere (pingare) il client.
 
Possiamo essere certi che sia così guardando semplicemente le statistiche riassuntive stampate al termine del test, la frase:
 
<pre>4 packets transmitted, 4 received, 0% packet loss, time 3002ms</pre>
 
infatti ci informa che abbiamo trasmesso al client 4 pacchetti e che il client li ha ricevuti tutti.
 
Se così non fosse, avremmo avuto un output del tipo:
<pre>
$ ping -c 4 192.168.0.2
PING 192.168.0.1 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
From 192.168.0.1 icmp_seq=4 Destination Host Unreachable
 
--- 192.168.0.2 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2998ms
, pipe 3
</pre>
 
Possiamo vedere che il client (192.168.0.2) non è raggiungibile (Destination Host Unreachable) dal router (from 192.168.0.1).
Se tutto è andato bene passiamo al punto seguente, in caso contrario controlliamo:
* che l'indirizzo del client sia corretto.
* che i cavi di rete siano collegati correttamente;
* che le schede di rete segnalino la presenza del segnale elettrico (ethernel link);
 
=== Comunicazione tra client e router ===
Il traffico della nostra rete deve essere necessariamente di tipo bidirezionale: dobbiamo quindi assicurarci che dal client sia possibile raggiungere il router.
 
Ripetiamo le operazioni del punto precedente, questa volta, però, operando dal client in direzione del router.
 
=== Risoluzione dei nomi ===
Verifichiamo che il nostro client sia in grado di risolvere i nomi degli host (di qui in seguito [[FQDN]]): questo significa che deve essere in grado di poter identificare un computer presente in internet non solo in base al suo indirizzo IP, ma anche in base ad un nome facilmente memorizzabile.
 
Facciamo subito un esempio usando come riferimento il FQDN '''www.debianizzati.org'''.
<pre>
# nslookup www.debianizzati.org
Server:        192.168.0.1
Address:        192.168.0.1#53
 
Non-authoritative answer:
Name:  www.debianizzati.org
Address: 66.199.227.58
</pre>
Possiamo vedere che il server che ci fornisce l'indirizzo è 192.168.0.1, cioè il nostro router, e che siamo in grado di risolvere gli FQDN in indirizzi IP. A riprova di questo, se tentiamo di pingare ''www.debianizzati.org'', otterremo il seguente output:
<pre>
$ ping -c 2 www.debianizzati.org
PING www.debianizzati.org (66.199.227.58) 56(84) bytes of data.
64 bytes from cp4.idleserv.net (66.199.227.58): icmp_seq=1 ttl=50 time=153 ms
64 bytes from cp4.idleserv.net (66.199.227.58): icmp_seq=2 ttl=50 time=152 ms
</pre>
mentre se non fosse possibile associare ''www.debianizzati.org'' al corretto IP, leggeremmo:
<pre>
$ ping www.debianizzati.org
ping: unknown host www.debianizzati.org
</pre>
 
== Conclusioni ==
Se siete giunti fino in fondo dovreste essere in grado di condividere la connessione ad internet in semplici LAN domestiche e risolvere i principali problemi che possono insorgere.
 
Se avete idee su come migliorare questa guida, segnalazione di errori e/o proposte non esitate a comunicarle nella pagina di discussione oppure sul [http://www.debianizzati.org forum di debianizzati].
 
Buona Navigazione!
 
{{Autori
|Autore = [[Utente:Guide @ Debianizzati.Org|Debianizzati.Org]]
|Estesa_da =
:[[Utente:Keltik|keltik]]
:[[Utente:TheNoise|The Noise]]
|Verificata_da=
:[[Utente:Clockwork orange|Clockwork Orange]]
:[[Utente:HAL 9000|HAL 9000]] 10:40, 7 set 2019 (CEST)
|Numero_revisori = 2
}}
 
[[Categoria:Configurazione ethernet]]
[[Categoria:Reti con Windows]]

Versione attuale delle 08:43, 7 set 2019

Debian-swirl.png Versioni Compatibili

Debian 8 "jessie"
Debian 9 "stretch"
Debian 10 "buster"

Premessa

Oggi che la maggior parte degli utenti domestici ha la possibilità di accedere ad Internet con connessioni a banda larga (ad esempio ADSL) e che è sempre più frequente avere a disposizione almeno un paio di computer, si avverte la necessità di poter condividere la connessione tra i vari computer della nostra rete domestica.

GNU/Linux è probabilmente la scelta più indicata in questi frangenti, essendo un sistema operativo nato espressamente in ambiente di rete: moltissimi dei router sul mercato fanno uso di GNU/Linux come sistema operativo, perché non farlo anche noi?

Prerequisiti

Tutto quello di cui abbiamo bisogno è la nostra Debian, una scheda di rete per ciascun PC da collegare alla rete locale ed un hub o switch.

Se avete un collegamento ADSL tramite modem USB e due soli computer, basta collegare le due schede di rete tramite cavetto ethernet cross (incrociato), non serve nient'altro. Uno dei due computer dovrà poi essere connesso ad internet tramite modem USB (vedere Modem e periferiche di rete per l'installazione e la configurazione), oppure tramite una seconda scheda di rete.

Per fare in modo che Debian si comporti come un router avremo bisogno anche di iptables. Vi rimando alla guida Debian e iptables per la sua corretta installazione e configurazione.

Configurazione Router

Per fare in modo che Debian faccia da gateway tra i PC della LAN e internet dobbiamo utilizzare il NAT (Network Address Translation).
Il tipo di NAT che ci interessa in questa guida è chiamato masquerading (mascheramento) degli indirizzi locali.
Il motivo è semplice: per accedere a internet è necessario avere un indirizzo IP di tipo pubblico, che il nostro ISP ci fornisce. Per permettere anche ai computer sprovvisti di indirizzo pubblico di navigare, dobbiamo fare in modo che i loro indirizzi di tipo privato vengano "nascosti" dietro a quello pubblico.

Masquerading

Con privilegi di amministrazione digitiamo il seguente comando:

# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

questo abilita il mascheramento degli indirizzi privati.

Nel caso il computer che fa da router sia collegato ad internet mediante un'altra interfaccia di rete (di solito ethx), al posto di ppp0 va messo il nome di quest'ultima e quindi diventa:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Per caricare queste regole di iptables ad ogni avvio conviene salvarle una volta e per tutte con iptables-save e caricarle ad ogni avvio con iptables-restore. Questi comandi leggono e scrivono su STDIN e STDOUT quindi bisogna usare la redirezione di shell.

Per salvare le regole correnti di iptables basta scrivere da root:

# iptables-save > /etc/iptables-save

Poi ad ogni avvio dovremo richiamare il seguente comando:

# iptables-restore < /etc/iptables-save

Basta creare uno script in /etc/network/if-up.d/ che esegua tale comando. Per esempio:

# touch /etc/network/if-up.d/restore-iptables

E poi modificare /etc/network/if-up.d/restore-iptables con il proprio editor di testo preferito (per esempio nano):

#! /bin/sh

readonly CONFIG_FILE="/etc/iptables-save"

# execute the script only if $CONFIG_FILE exists
test -f "$CONFIG_FILE" || exit 0

# restore IP tables
printf %s " * Loading iptables saved state... "
iptables-restore < "$CONFIG_FILE" &&
printf %s\\n "[ OK ]"

E renderlo eseguibile:

# chmod a+x /etc/network/if-up.d/restore-iptables

La regola verrà caricata ad ogni avvio del sistema, senza che sia necessario digitarla nuovamente, e solo se il file /etc/iptables-save esiste.

Ip Forwarding

Configurare iptables non è però sufficiente. I comuni PC, infatti, non devono essere in grado di comportarsi come i router e cioè non devono poter instradare pacchetti da una rete all'altra.
Dato che per noi è fondamentale abilitare questa possibilità, dobbiamo agire su un parametro del kernel che regola questa funzione: l' ip-forwarding.

L'ip-forwarding si può abilitare "al volo" semplicemente impostando a "1" la relativa variabile del kernel, con il comando:

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

così facendo, però, ad ogni riavvio dovremo reimpostare la variabile.

Impostare l'ip-forwarding al boot: /etc/sysctl.conf

Se avete installato ipmasq, l'ip-forwarding è già abilitato: passate alle misure di sicurezza.

Il metodo più semplice, consigliato nella maggior parte dei casi, per impostare l'ip-forwarding ad ogni boot è di inserire in /etc/sysctl.conf:

## Abilita il forwarding di pacchetti non locali - FONDAMENTALE
net/ipv4/ip_forward = 1

In questo caso si abilita unicamente per IPv4; è necessario, se si desidera, abilitarlo anche per IPv6.

È opportuno impostare anche alcune misure di sicurezza (le prime due dovrebbero essere già attive di default):

## Ignora finti messaggi di errore ICMP
net/ipv4/icmp_ignore_bogus_error_responses = 1

## Non risponde ai ping inviati al broadcast della subnet
net/ipv4/icmp_echo_ignore_broadcasts = 1

## Non accetta pacchetti ICMP di route redirection
net/ipv4/conf/all/accept_redirects = 0

## Protezione anti spoofing 
net/ipv4/conf/all/rp_filter = 1

Impostare l'ip-forwarding al boot: script

È possibile anche abilitare l'ip-forwarding associando uno script alla creazione delle interfacce di rete in fase di boot. Questo metodo è consigliato solo in caso di setup più complessi, in cui si vogliono impostare regole diverse a seconda dell'interfaccia di rete che si attiva.

Per prima cosa, apriamo con il nostro editor preferito il file /etc/network/interfaces e cerchiamo la sezione relativa alla nostra scheda di rete.

Dovreste individuare qualcosa di simile a:

auto eth0
iface eth0 inet static
	address 192.168.0.1
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255

A questo punto, nella riga immediatamente successiva a "broadcast ...", inseriamo questa direttiva:

auto eth0
iface eth0 inet static
	address 192.168.0.1
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255 
        pre-up /etc/network/iface-secure

Questo comando dice allo script, che si occupa di configurare la scheda di rete, di lanciare un altro script, e cioè /etc/network/iface-secure, che provvediamo subito a creare con il comando:

# touch /etc/network/iface-secure

Dopodiché rendiamolo eseguibile e scrivibile per root con:

# chmod 755 /etc/network/iface-secure

All'interno di questo file scriveremo il nostro comando per abilitare l' ip-forwarding:

#! /bin/sh

### Abilita il forwarding di pacchetti non locali - FONDAMENTALE
echo 1 > /proc/sys/net/ipv4/ip_forward

### Ignora finti messaggi di errore ICMP
echo 1 > /proc/sys/net/ipv4/icmp_ignore_bogus_error_responses

### Non risponde ai ping inviati al broadcast della subnet
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts

### Non accetta pacchetti ICMP di route redirection
echo 0 > /proc/sys/net/ipv4/conf/all/accept_redirects

Server DNS

Per poter navigare su internet, è necessario che i PC della nostra rete locale abbiano accesso ad un server DNS che traduca per noi gli indirizzi internet in indirizzi IP.

Un modo per fare questo consiste nell'impostare, per ciascuno dei nostri PC, i server DNS forniti dal nostro provider.

Esiste tuttavia un'alternativa molto più comoda e performante: creare un nostro server DNS ed utilizzarlo in sostituzione di quelli del provider. Questa soluzione porta ad alcuni vantaggi:

  • sui PC della LAN dovremo configurare sempre un solo server DNS immutabile e che conosciamo bene (senza faticose ricerche);
  • i tempi di risposta sono nettamente più performanti rispetto a server esterni alla LAN, sia perché il server è raggiungibile direttamente (senza instradamento attraverso internet), sia perché sfrutta un sistema di cache (se 10 PC chiedono l' indirizzo di debian.org, ad esempio, il nostro DNS effettuerà la richiesta solo la prima volta e per le restanti 9 utilizzerà le informazioni memorizzate nella propria cache);
  • grazie a questo meccanismo di caching i DNS del provider sono meno stressati e quindi più performanti a loro volta.

Per realizzare il nostro server useremo bind, probabilmente il miglior software esistente per questo compito.

Per prima cosa installiamo bind9 ed alcuni strumenti utili:

# apt install bind9 dnsutils

Ora configuriamo il server in modo che faccia le sue richieste ai server DNS che vogliamo noi anziché ai ROOT SERVERS (sono pochi in tutto il mondo, molto stressati e aggiornati più lentamente di altri). Tutto quello che dobbiamo fare è editare la sezione options del file /etc/bind/named.conf.options:

options {
directory "/var/cache/bind";

forward first;
forwarders {
INDIRIZZO IP DNS PRIMARIO; #varia a seconda del provider
INDIRIZZO IP DNS SECONDARIO; #varia a seconda del provider
};

auth-nxdomain no; # conform to RFC1035
};

Ora non ci resta che riavviare bind con il comando:

# service bind9 restart

e configurarlo come DNS sui PC della nostra rete.

Altri Protocolli

FTP

Con la configurazione svolta fino a questo punto dovrebbe essere possibile accedere dai PC della LAN a server FTP esterni in passive mode (se ciò non fosse possibile vedere più avanti: Problemi con MTU).

Se si vuole accedere a server FTP in active mode il router deve tracciare le connessioni FTP, e a tal scopo basta caricare i due moduli:

# modprobe ip_conntrack_ftp
# modprobe ip_nat_ftp

Da questo momento in poi i PC della LAN dovrebbero essere in grado di accedere ai server FTP anche in active mode.

IRC

Dovreste essere in grado di usare IRC senza problemi dai PC della vostra LAN. In caso contrario potreste provare a caricare manualmente i moduli che servono al router per gestire le connessioni ad IRC:

# modprobe ip_conntrack_irc ports=5555,6666,6667,6668,6669,7000 
# modprobe ip_nat_irc

dove, con la direttiva "ports=" indichiamo le porte generalmente utilizzate dai server IRC.

Se avete problemi, leggete più avanti: Problemi con MTU.

Configurazione LAN

Passiamo ora alla configurazione degli altri PC della nostra rete domestica.

Premessa

Generalmente per le reti locali domestiche si utilizzano indirizzi IP del tipo 192.168.0.x, dove x è un numero variabile tra 1 e 254. Questo significa che all'interno della stessa rete possiamo avere fino a 254 indirizzi IP univoci.
Generalmente il router di una rete ha come indirizzo IP il primo o l'ultimo della rete e cioè 192.168.0.1 oppure 192.168.0.254. In questo esempio noi useremo il primo.

Assegnare un IP

Ad ogni PC della LAN si deve assegnare un indirizzo IP per poter comunicare con gli altri PC della rete interna (che nel caso limite è il solo PC che fa da router). Per assegnare un indirizzo IP statico basta usare il comando:

# ifconfig eth0 192.168.0.2 up

dove 192.168.0.2 è l'indirizzo arbitrario che si è scelto per la particolare macchina.
Il comando ifconfig permette di specificare molti più parametri ma, utilizzando l'indirizzo dell'esempio, questi verranno preconfigurati automaticamente. Per non riscrivere questo comando ad ogni boot, si può inserire in /etc/network/interfaces:

auto eth0
iface eth0 inet static
    address 192.168.0.2
    netmask 255.255.255.0
    network 192.168.0.0
    broadcast 192.168.0.255 

Impostare il gateway

Ora bisogna dire ad ogni macchina della LAN di instradare tutti i pacchetti diretti verso l'esterno al PC fisicamente collegato ad internet (che fa da router). A tal scopo basta impostare il default gateway:

# route add default gw 192.168.0.1

Per non dover scrivere questo comando ad ogni riavvio, è sufficiente aggiungere al file /etc/network/interfaces, subito al di sotto della direttiva 'broadcast ...' la seguente linea:

   gateway 192.168.0.1

Impostare il server DNS

Per impostare il server DNS che i nostri PC useranno è necessario editare il file /etc/resolv.conf inserendo la seguente linea:

nameserver 192.168.0.1

assicurandoci di scriverlo nella prima riga del file (L'ordine con cui il sistema interroga i DNS è identico a quello in cui compaiono in /etc/resolv.conf)

Client Windows®

Per la configurazione di eventuali PC con installato Microsoft® Windows® vi rimandiamo alla Guida in Linea, al sito di supporto ed al vostro rivenditore hardware (che per contratto è tenuto a fornirvi assistenza).

Problemi con MTU

Può capitare a volte, specialmente con collegamenti ADSL, che l'MTU impostato di default per le interfacce di rete (1500) non sia appropriato e causi vari malfunzionamenti. Ad esempio, io non riuscivo ad usare wget, ftp, apt-get e irc. Altri hanno riportato di non potere accedere a certi siti.

Risolvere questo problema è semplice, basta impostare l'MTU di tutte le interfacce ethernet ad un valore più basso di 1500. A tal scopo basta aggiungere in /etc/network/interfaces una riga apposita:

iface eth0 inet static
	address 192.168.0.2
	netmask 255.255.255.0
	network 192.168.0.0
	broadcast 192.168.0.255
        mtu 1412

Questo su tutti i computer della LAN e anche sul PC che funge da router. Se si ha poi una connessione ppp per collegarsi ad internet, sul pc-router bisognerà impostare l'MTU anche per questa interfaccia. Qui la configurazione potrebbe variare a seconda dei casi, ma usualmente è possibile impostare l'MTU in /etc/ppp/options e/o in /etc/ppp/peers/tuo-provider.

Riavviando ora tutte le interfacce di rete sia eth0 che ppp, avremo impostato il nuovo valore per l'MTU sperando di aver eliminato i malfunzionamenti.

Test

Finalmente siamo arrivati al momento di testare la nostra rete domestica.

Nei prossimi minuti cercheremo di appurare se i vari elementi che abbiamo predisposto in precedenza sono effettivamente funzionanti e, se non lo sono, per quale motivo.

Per fare questo avremo bisogno di alcuni tra i più usati strumenti diagnostici: ping e nslookup, ma non preoccupatevi: il primo viene installato automaticamente ed il secondo abbiamo provveduto ad installarlo contestualmente a bind.

Comunicazione tra router e client

Prima di tutto annotiamo l'indirizzo IP del client (in questo esempio: 192.168.0.2).

Ora apriamo una shell sul PC che funge da router e digitiamo il comando:

$ ping -c 4 192.168.0.2
PING 192.168.0.2 (192.168.0.2) 56(84) bytes of data.
64 bytes from 192.168.0.2: icmp_seq=1 ttl=255 time=1.41 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=255 time=0.953 ms
64 bytes from 192.168.0.2: icmp_seq=3 ttl=255 time=0.988 ms
64 bytes from 192.168.0.2: icmp_seq=4 ttl=255 time=1.02 ms

--- 192.168.2.0 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3002ms
rtt min/avg/max/mdev = 0.953/1.094/1.417/0.191 ms

Per ora non ci interessa il significato dei messaggi a video, ma unicamente il fatto che dal router è effettivamente possibile raggiungere (pingare) il client.

Possiamo essere certi che sia così guardando semplicemente le statistiche riassuntive stampate al termine del test, la frase:

4 packets transmitted, 4 received, 0% packet loss, time 3002ms

infatti ci informa che abbiamo trasmesso al client 4 pacchetti e che il client li ha ricevuti tutti.

Se così non fosse, avremmo avuto un output del tipo:

$ ping -c 4 192.168.0.2
PING 192.168.0.1 (192.168.0.2) 56(84) bytes of data.
From 192.168.0.1 icmp_seq=1 Destination Host Unreachable
From 192.168.0.1 icmp_seq=2 Destination Host Unreachable
From 192.168.0.1 icmp_seq=3 Destination Host Unreachable
From 192.168.0.1 icmp_seq=4 Destination Host Unreachable

--- 192.168.0.2 ping statistics ---
4 packets transmitted, 0 received, +4 errors, 100% packet loss, time 2998ms
, pipe 3

Possiamo vedere che il client (192.168.0.2) non è raggiungibile (Destination Host Unreachable) dal router (from 192.168.0.1). Se tutto è andato bene passiamo al punto seguente, in caso contrario controlliamo:

  • che l'indirizzo del client sia corretto.
  • che i cavi di rete siano collegati correttamente;
  • che le schede di rete segnalino la presenza del segnale elettrico (ethernel link);

Comunicazione tra client e router

Il traffico della nostra rete deve essere necessariamente di tipo bidirezionale: dobbiamo quindi assicurarci che dal client sia possibile raggiungere il router.

Ripetiamo le operazioni del punto precedente, questa volta, però, operando dal client in direzione del router.

Risoluzione dei nomi

Verifichiamo che il nostro client sia in grado di risolvere i nomi degli host (di qui in seguito FQDN): questo significa che deve essere in grado di poter identificare un computer presente in internet non solo in base al suo indirizzo IP, ma anche in base ad un nome facilmente memorizzabile.

Facciamo subito un esempio usando come riferimento il FQDN www.debianizzati.org.

# nslookup www.debianizzati.org
Server:         192.168.0.1
Address:        192.168.0.1#53

Non-authoritative answer:
Name:   www.debianizzati.org
Address: 66.199.227.58

Possiamo vedere che il server che ci fornisce l'indirizzo è 192.168.0.1, cioè il nostro router, e che siamo in grado di risolvere gli FQDN in indirizzi IP. A riprova di questo, se tentiamo di pingare www.debianizzati.org, otterremo il seguente output:

$ ping -c 2 www.debianizzati.org
PING www.debianizzati.org (66.199.227.58) 56(84) bytes of data.
64 bytes from cp4.idleserv.net (66.199.227.58): icmp_seq=1 ttl=50 time=153 ms
64 bytes from cp4.idleserv.net (66.199.227.58): icmp_seq=2 ttl=50 time=152 ms

mentre se non fosse possibile associare www.debianizzati.org al corretto IP, leggeremmo:

$ ping www.debianizzati.org
ping: unknown host www.debianizzati.org

Conclusioni

Se siete giunti fino in fondo dovreste essere in grado di condividere la connessione ad internet in semplici LAN domestiche e risolvere i principali problemi che possono insorgere.

Se avete idee su come migliorare questa guida, segnalazione di errori e/o proposte non esitate a comunicarle nella pagina di discussione oppure sul forum di debianizzati.

Buona Navigazione!




Guida scritta da: Debianizzati.Org Swirl-auth60.png Debianized 60%
Estesa da:
keltik
The Noise
Verificata da:
Clockwork Orange
HAL 9000 10:40, 7 set 2019 (CEST)

Verificare ed estendere la guida | Cos'è una guida Debianized