Nessun risultato. Prova con un altro termine.
Guide
Notizie
Software
Tutorial

Configurare un indirizzo IP "al volo"

Ciò che è necessario sapere per assegnare parametri di funzionamento temporanei a una interfaccia di rete in Linux.
Ciò che è necessario sapere per assegnare parametri di funzionamento temporanei a una interfaccia di rete in Linux.
Link copiato negli appunti

Quando utilizziamo una risorsa raggiungibile su rete assai di rado lo facciamo invocando direttamente il suo indirizzo IP. In genere adoperiamo le Uniform Resource Identificator (URI). Le URI possono essere distinte in due sottotipologie ovvero le Uniform Resource Name (URN), sequenze alfanumeriche che, mediante opportuni servizi, consentono di ottenere in risposta un indirizzo IP considerato con queste in relazione e le URL (Uniform Resource Locator). Queste ultime altro non sono che URN o indirizzi IP con in aggiunta alcune informazioni utili per identificare il servizio che dovrà essere adoperato per assolvere alla richiesta. Ad esempio html.it è una URN mentre http://html.it/ è una URL.

Configurazione temporanea di una interfaccia di rete

Adesso è il momento di sperimentare la configurazione al volo di una interfaccia di rete per verificare sul campo ciò che poi andremo a implementare in modo permanente attingendo alle competenze che saranno presentate nei prossimi capitoli.
Disponete di uno strumento molto intuitivo, ovvero ifconfing, che consente di assegnare a una interfaccia specifiche senza affrontare una selva di specifiche e file. Ovviamente in quanto "temporanei" i parametri assegnati non sopravviveranno al reboot del dispositivo.

fprincipe@html13:~$ ifconfig
lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 114  bytes 8836 (8.8 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 114  bytes 8836 (8.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
fprincipe@html13:~$ ip addr
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp0s8:  mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:c1:b9:91 brd ff:ff:ff:ff:ff:ff
fprincipe@html13:~$ sudo ifconfig enp0s8 192.168.0.113 netmask 255.255.255.0
fprincipe@html13:~$ ifconfig
enp0s8: flags=4163  mtu 1500
        inet 192.168.0.113  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::a00:27ff:fec1:b991  prefixlen 64  scopeid 0x20
        ether 08:00:27:c1:b9:91  txqueuelen 1000  (Ethernet)
        RX packets 119  bytes 20749 (20.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 24  bytes 2004 (2.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
lo: flags=73  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 134  bytes 10400 (10.4 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 134  bytes 10400 (10.4 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Lanciamo ifconfig una prima volta e verifichiamo le interfacce configurate. Il comando ip addr consente di ottenere anche l’identificativo delle interfacce non configurate, selezioniamo una interfaccia libera e la battezziamo passando i comandi come segue: ifconfig [nome dell’intefaccia] [indirizzo ip] netmask [valore della subnet mask] broadcast [indirizzo del broadcast]. Lanciamo ifconfig un’ultima volta e verifichiamo che l’interfaccia in questione sia ora temporaneamente configurata.

DNS Server Name Resolver

Ora disponiamo di tutto il bagaglio necessario per poter comprendere che a qualsiasi dispositivo dialoghi su reti connesse a Internet occorra un riferimento tanto per il gateway quanto per default nameserver. Come abbiamo detto il primo servirà quale ponte verso ulteriori tronconi di rete o meglio per raggiungere specifici indirizzi IP in essi ospitati mentre il secondo sarà necessario per consentire di associare a un riferimento URN un corrispondente indirizzo IP. Per saggiare l’associazione URN/indirizzo IP possiamo utilizzare il comando nslookuop. A seguire un piccolo esempio.

[fprincipe@html2 ~]$ nslookup www.html.it
Server:		8.8.8.8
Address:	8.8.8.8#53
Non-authoritative answer:
Name:	www.html.it
Address: 46.37.29.204

Per il momento concentriamoci sull’ultimo rigo dell’output ottenuto. Alla voce Address scopriamo l’indirizzo IP della risorsa che stiamo invocando. Quando una macchina desidera risolvere questa associazione interroga un Domain Name System (DNS). I Domain Server di riferimento devono quindi essere specificati. Osserviamo ora il primo rigo dell’output relativo all’esempio precedente. Alla voce Server possiamo trovare il DNS che è stato interrogato per fornirci una risposta. Ogni dispositivo che avrà necessità di inoltrare richiesta per associare un URN a un indirizzo IP deve disporre di un elenco di indirizzi IP che potranno svolgere la funzione di server DNS. Questo elenco è contenuto nel file /etc/resolv.conf.

[fprincipe@html2 ~]$ more /etc/resolv.conf
# nameserver 192.168.0.1
nameserver 45.81.215.7
nameserver 8.8.8.8

Le righe che iniziano con cancelletto (#) sono commenti. Nel file sono riportati tre diversi nameserver, il primo è, appunto, commentato, il secondo è inventato di sana pianta quindi non corrisponde a un server reale, il terzo è invece un servizio DNS di Google effettivamente operativo. Torniamo all’esempio relativo a nslookup. Possiamo constatare che sebbene siano presenti tre distinti indirizzi IP di DNS server le risposte ci giungono solo dal terzo. Il primo infatti, essendo commentato, non viene preso in considerazione. Il secondo non può rispondere quindi viene scartato. Otteniamo pertanto risposte solo dal terzo. Da ciò comprendiamo che nel file in questione è possibile inserire anche più di un DNS server e che questi verranno interrogati seguendo l’ordine stabilito sino a quando uno di essi non risponderà in modo valido. Lo stesso principio può essere adottato in locale. Se desideriamo associare qualcosa di equivalente alle URN ma “ad uso interno per la LAN” il modo più semplice di farlo è popolare il file /etc/hosts delle nostre macchine. Vediamo in dettaglio un esempio.

[fprincipe@html2 ~]$ more /etc/hosts
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
192.168.0.101	html1
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
[fprincipe@html2 ~]$ ping html1
PING html1 (192.168.0.101) 56(84) bytes of data.
64 bytes from html1 (192.168.0.101): icmp_seq=1 ttl=64 time=0.190 ms
64 bytes from html1 (192.168.0.101): icmp_seq=2 ttl=64 time=0.227 ms
64 bytes from html1 (192.168.0.101): icmp_seq=3 ttl=64 time=0.212 ms
^C
--- html1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2048ms
rtt min/avg/max/mdev = 0.190/0.209/0.227/0.022 ms

Per ogni riga potremo specificare un indirizzo IP e una serie di alias separati da spazio. Questo consentirà di attivare un collegamento con una risorsa presente nella nostra LAN tramite il suo indirizzo IP ottenuto invocando uno dei sui alias alfanumerici.

Ti consigliamo anche