Red Hat Linux 6.X as an Internet Gateway for a Home Network Paul Ramsey 22 Giugno 2000 Un semplice tutorial su come configurare la distribuzione Red Hat 6 e relative varianti per operare come gateway per internet per una pic­ cola rete domestica o in ufficio. Gli argomenti trattati comprendono masquerading, DNS, DHCP e sicurezza di base. Traduzione a cura di Alessio Ciregia, , e revisione a cura di Daniele Masini, . ______________________________________________________________________ Indice Generale 1. Introduzione 1.1 Versioni 1.2 Copyright 2. Mettere insieme le cose 2.1 Con un hub 2.2 Senza un hub 2.3 Con una sola scheda di rete 3. Configurare la rete 3.1 Configurare un driver di rete 3.1.1 Due schede di rete identiche 3.2 Configurare la rete interna 3.2.1 Il dispositivo di rete 3.2.2 Il server DHCP 3.2.3 I computer client 3.2.4 Il server DNS 3.2.5 Verificare la rete interna 3.3 Configurare la rete esterna 3.3.1 Con un IP statico 3.3.2 Con il DHCP 3.3.3 Stranezze ed anomalie 3.3.3.1 PPP Over Ethernet (PPPoE) 3.3.3.2 Semplici trucchi per il DHCP 3.3.3.3 Road Runner 3.3.4 Uno sguardo alle impostazioni di rete 3.4 Sicurezza 4. Configurare il Masquerading 5. Problemi 5.1 ICQ non funziona 5.2 Se si ha Caldera 2.X e non Red Hat 6.X 5.3 Si vuole che una delle macchine interne funzioni come server Web ______________________________________________________________________ 11.. IInnttrroodduuzziioonnee Questa pagina contiene un semplice manuale per impostare Red Hat 6.X come gateway per Internet per una rete domestica o una piccola rete in ufficio. Le istruzioni sono molto semplificate: non sarà discusso nessun caso particolare e saranno fatte alcune considerazioni su quali indirizzi di rete saranno utilizzati. Le assunzioni principali sono: · Si ha una connessione Cable o ADSL full time ad Internet. · Si ha installato Red Hat 6.x su almeno uno dei propri computer. Si noti che queste indicazioni sono valide anche per le distribuzioni derivate da Red Hat, come Mandrake 6.X che è distribuita da MacMillan Publishing sotto una vari nomi. · Il proprio computer Linux ha due schede di rete installare ed entrambe sono compatibili con Linux. · Si ha un hub ethernet per collegare in rete più di un computer o un cavo incrociato se si vuole collegare in rete un solo computer. · Si sa come modificare file di testo sulla propria macchina Linux. · Si è in grado di effettuare il login sulla macchina Linux come root. Si è in grado di installare pacchetti RPM dal proprio CD-ROM Linux. Se qualcuna di queste condizioni non è soddisfatta, allora questo documento probabilmente non è quello fa per il lettore. Non c'è nulla di particolare che deve essere fatto durante il processo di installazione. Si scelga semplicemente un'installazione che abbia senso e la si porti a termine. Questo documento suggerisce di installare da zero ogni cosa che abbia a che fare con la rete, per evitare di fare supposizioni su cosa è stato installato o configurato durante l'installazione. Per essere sicuri che le cose funzionino e non ci sia confusione circa l'inserimento delle varie informazioni, tutte le configurazioni saranno fatte modificando direttamente i file di configurazione del sistema invece di utilizzare gli strumenti di configurazione grafici forniti da Red Hat. Da un lato, questo potrebbe risultare un po' più difficile, ma in questo modo le indicazioni saranno più facilmente applicabili a distribuzioni e situazioni differenti (per esempio, se X non funziona o si sta configurando un server senza monitor). 11..11.. VVeerrssiioonnii L'ultima versione di questo documento dovrebbe sempre essere disponibile su http://www.coastnet.com/~pramsey/linux/homenet.html per la versione HTML e su http://www.coastnet.com/~pramsey/linux/homenet.sgml per la versione SGML. · 21 Dicembre 1999: Prima versione. · 2 Gennaio 2000: Aggiunti i suggerimenti di John Mellor sui collegamenti di rete esterni. · 22 Gennaio 2000: Piccoli aggiornamenti a proposito di schede di rete identiche ed informazioni sull'IP aliasing da parte di Chris Lea. · 16 Marzo 2000: Alcune informazioni sulla sicureza dei name server e sul supporto a Caldera da parte Nelson Gibbs. · 22 Giugno 2000: Documentate le stranezze riguardanti la configurazione di Red Hat 6.2. Ulteriori informazioni sul PPPoE da parte Kerr First. 11..22.. CCooppyyrriigghhtt Copyright © 2000, Paul Ramsey. This manual may be reproduced in whole or in part, without fee, subject to the following restrictions: · The copyright notice above and this permission notice must be preserved complete on all complete or partial copies. · Any translation or derived work must be approved by the author in writing before distribution. · If you distribute this work in part, instructions for obtaining the complete version of this manual must be included, and a means for obtaining a complete version provided. · Small portions may be reproduced as illustrations for reviews or quotes in other works without this permission notice if proper citation is given. Exceptions to these rules may be granted for academic purposes: Write to the author and ask. These restrictions are here to protect us as authors, not to restrict you as learners and educators. 22.. MMeetttteerree iinnssiieemmee llee ccoossee Nel caso in cui si stia usando o meno un hub, la topologia della propria rete sarà lievemente differente. Qui saranno trattate soltanto le connessioni con cablaggio RJ45 (quella cosa che somiglia al cavo telefonico) senza parlare di cavi coassiali. Col coassiale si possono collegare in rete più macchine senza aver bisogno di un hub, ma si deve avere attenzione a terminare i cavi e ad altre cose. Se si conosce già tutto sui collegamenti di rete, queste istruzioni risulteranno una ripetizione. 22..11.. CCoonn uunn hhuubb Se si ha un hub, la rete somiglierà a questa. Si colleghi la scheda eth0 della macchina Linux al modem o al terminale ADSL utilizzando il cavo fornito dal provider al momento dell'installazione (o uno che si sa che funzioni in questa configurazione). Questo è importante perché a volte è necessario collegare i modem con un cavo incrociato ed altre volte bisogna utilizzare un cavo dritto: quello che si deve usare è quello fornito dalla compagnia telefonica. Si colleghi la scheda eth1 della macchina Linux all'hub con un cavo dritto. Si colleghino tutti gli altri computer all'hub con cavi dritti. 22..22.. SSeennzzaa uunn hhuubb Se non si ha un hub, si può comunque connettere un computer alla macchina Linux, utilizzando un cavo incrociato. La topologia della rete somiglierà a questa. Si colleghi la scheda eth0 della macchina Linux al modem o al terminale ADSL utilizzando il cavo fornito dal provider. Si colleghi la scheda eth1 della macchina Linux all'altro computer con un cavo incrociato. 22..33.. CCoonn uunnaa ssoollaa sscchheeddaa ddii rreettee Questa non è una configurazione consigliata (in questa configurazione la rete interna e quella esterna sono sulla stessa rete fisica e sono perciò teoricamente più suscettibili al cracking; in realtà, il rischio è probabilmente molto basso) ma _p_u_ò essere realizzata. Il percorso può variare. Il kernel Linux include il supporto per l'"IP aliasing", che permette ad una scheda ethernet di funzionare simultaneamente con due indirizzi IP differenti. I tipi di kernel forniti con Red Hat e Mandrake comprendono di default il supporto per l'IP aliasing. Per impostare il gateway con una sola scheda di rete ethernet, in tutti i seguenti codici esemplificativi, si sostituisca semplicemente eth1 con eth0:0. _N_e_l_l_a _s_i_t_u_a_z_i_o_n_e _c_o_n _u_n_a _s_i_n_g_o_l_a _s_c_h_e_d_a_, non _è _r_a_c_c_o_m_a_n_d_a_t_o _u_t_i_l_i_z_z_a_r_e _u_n _s_e_r_v_e_r _D_H_C_P_. Si colleghino tutte le macchine ed il modem o il terminale ADSL all'hub. Incrociare le dita e proseguire. 33.. CCoonnffiigguurraarree llaa rreettee Bene, a questo punto Linux è già installato sul gateway. È possibile che una delle schede di rete sia già configurata, e che la connessione ad Internet sia già impostata. Comunque sia, ripercorriamo la configurazione dall'inizio, assumendo che non sia stato configurato niente. Si effettui l'accesso come root. Tutte le istruzioni fornite in questo documento presumono che si sia riconosciuti dal sistema come root. Il kernel di Linux si riferisce alle due schede ethernet come eth0 e eth1, per cui è in questo modo che da ora in poi ci si riferirà ad esse. Il problema è riconoscerle. Ecco una maniera "semplice" per capirlo, che sicuramente funziona almeno il 50% delle volte: si metta il computer su un tavolo con la scheda madre orizzonatale ed il pannello posteriore di fronte (come si farebbe se si volesse aprirlo per farci qualche lavoro). La scheda più a sinistra è l'eth0 -- si può etichettarla in qualche modo. Adesso, si annoti su un foglio il costruttore ed il modello sia dell'eth0 che dell'eth1. Bene, vediamo se l'eth0 e l'eth1 sono state riconosciute automaticamente dal kernel. Si digiti ifconfig eth0 e ifconfig eth1. In entrambi i casi, se il kernel ha riconosciuto la scheda, si dovrebbe vedere qualcosa tipo questo (considerando che i numeri e chissà cos'altro potrebbero essere differenti): eth0 Link encap: Ethernet HWaddr 00:60:67:4A:02:0A inet addr:0.0.0.0 Bcast:0.0.0.0 Mask:255.255.255.255 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:466 errors:0 dropped:0 overruns:0 frame:0 TX packets:448 errors:0 dropped:0 overruns:0 carrier:0 collisions:85 txqueuelen:100 Interrupt:10 Base address:0xe400 Se il kernel non riconosce la scheda di rete si vedrà qualcosa tipo questo: eth0: error fetching interface information: Device not found. 33..11.. CCoonnffiigguurraarree uunn ddrriivveerr ddii rreettee Se entrambe le schede sono state riconosciute, si può saltare alla prossima sezione. Altrimenti, si legga questa sezione. Quindi una o entrambe le schede non sono state riconosciute dal kernel. Questo non è un problema, davvero. Quello che stiamo per andare a fare è di dire al kernel più esplicitamente come trovare le schede. Ci sono un sacco di metodi e "trucchi", e non saranno trattati tutti. Si ricordi: quando le cose si fanno dure, i duri si rivolgono all'Ethernet HOWTO. Ecco dei consigli riassuntivi: · _S_i _h_a _u_n_a _s_c_h_e_d_a _d_i _r_e_t_e _P_C_I_. Probabilmente si è in una buona posizione, sempre che non sia talmente recente che non esistano ancora i relativi driver. È possibile raccogliere un grande quantità di informazioni sulle schede di rete (ed altre cose) andando a leggere in /proc/pci, annotandosi produttori e modelli. · _S_i _h_a _u_n_a _s_c_h_e_d_a _d_i _r_e_t_e _I_S_A_. Probabilmente si dovrà scoprire l'indirizzo di I/O di base e l'IRQ con cui opera la scheda. Si hanno i manuali, vero? Vero? Se non è così, potrebbe essere il momento di visitare il sito web del produttore e vedere se contiene qualche riferimento online. Oppure se si ha un vecchio dischetto DOS per la configurazione della scheda, si avvii il DOS e si guardi se c'è un programma di setup con cui si può leggere ed impostare l'indirizzo di I/O e l'IRQ. · _S_i _h_a _u_n_a _s_c_h_e_d_a _I_S_A _P_l_u_g_'_n_'_P_l_a_y_. Prima si dovrà imparare come configurarla -- leggere il Plug'n'Play HOWTO. Fortunatamente, una volta che la scheda sarà configurata si conoscerà esattamente sia l'indirizzo di I/O che l'IRQ. Ora, poiché si conoscono sia la marca che il modello dell'eth0 e dell'eth1 si può visitare la pagina di compatibilità dell'Ethernet HOWTO e cercare la scheda. Si prenda nota del driver consigliato e di qualsiasi informazione a proposito di opzioni particolari che potrebbe richiedere la scheda. È il momento di modificare un file di configurazione! Il file che modificheremo è /etc/conf.modules. Si apra il file nell'editor di testo preferito. Poiché ci sono così tante possibilità e combinazioni di cose che si possono trovare in questo file, sarà presentata come esempio la configurazione del mio gateway. Esso ha una scheda PCI 10/100Mb basata sul chip VIA Rhine, ed un clone di una scheda ISA 10Mb NE2000. Si usa quella a 100Mb per la rete interna e la scheda a 10Mb per la connessione esterna. Il file /etc/conf.modules è il seguente: alias parport_lowlevel parport_pc alias eth0 ne options ne io=0x300 irq=10 alias eth1 via-rhine Il file conf.modules è configurato come segue: · La prima riga configura la porta parallela per la stampa. Probabilmente se ne avrà una simile anche nella popria configurazione. La si lasci pure così. · La seconda riga (alias eth0 ne) dice al kernel di usare il driver ne per il dispositivo eth0. · La terza riga (options ne io=0x300 irq=10) dice al driver ne a quale indirizzo I/O e a quale interrupt IRQ troverà la scheda ISA. Se si ha una scheda ISA probabilmente si dovrà usare questo tipo di direttiva: si sostituisca semplicemente il driver, l'indirizzo I/O e l'IRQ con le corrette informazioni riguardanti la propria scheda. · La quarta riga (alias eth1 via-rhine) dice al kernel di usare il driver via-rhine per l'eth1. Visto che la scheda eth1 di esempio è una scheda PCI, non si ha bisogno di fornire informazioni riguardanti I/O e IRQ: il sottosistema PCI configura automaticamente il dispositivo. Ci si assicuri di avere la voce alias nel file conf.modules per entrambe le proprie schede, e le righe corrette per le opzioni riguardanti tutte le schede ISA. Si potrebbero avere già delle righe in conf.modules per ogni scheda ethernet configurata durante l'installazione. Quando il file conf.modules è stato modificato, si provi a digitare ifconfig eth0 e ifconfig eth1. Si dovrebbe ricevere qualche errore se sono modificati gli indirizzi di I/O e gli IRQ senza un manuale del fabbricante. 33..11..11.. DDuuee sscchheeddee ddii rreettee iiddeennttiicchhee Dunque, si è stati molto molto astuti, comprando due schede di rete identiche per il proprio gateway Linux, ed ora non si riesce a farle funzionare insieme? Non bisogna preoccuparsi, per farle coesistere è solo una questione di usare la sintassi corretta nel file /etc/conf.modules. Supponendo che gli indirizzi e i numeri di IRQ siano già stati recuperati e presumendo che le schede in questione siano cloni NE2000 (una scelta comune) identici, il file /etc/conf.modules dovrebbe somigliare a questo: alias eth0 ne alias eth1 ne options ne io=0x330,0x360 irq=7,9 Le opzioni di indirizzamento sono state scritte sulla stessa riga, ed il primo numero per ogni tipo di indirizzamento è relativo all'eth0, mentre il secondo numero è per l'eth1. 33..22.. CCoonnffiigguurraarree llaa rreettee iinntteerrnnaa La "rete interna" è la rete su cui parlano tutti i computer di casa o dell'ufficio. La "rete esterna" è la spaventosa Internet dall'altro lato della macchina Linux. Nel complesso, la rete interna sarà completamente isolata dalla rete esterna madiante la macchina Linux, la quale opererà come un firewall con livello di sicurezza intermedio. 33..22..11.. IIll ddiissppoossiittiivvoo ddii rreettee Dal momento che i driver sono funzionanti ed il sistema è in grado di vedere sia l'eth0 che l'eth1 con il comando ifconfig, è il momento di configurare la rete casalinga interna. Si suppone che la rete interna sia collegata all'eth1 e quella esterna all'eth0. La rete interna sarà una rete privata e perciò avrà un indirizzo IP speciale riservato per il networking interno: 192.168.1.0. Questa è una "rete privata di classe C", nel caso si vogliano impressionare i propri amici. Prima di tutto dobbiamo assicurarci che la rete sia attivata. Si modifichi il file /etc/sysconfig/network e ci si assicuri che esistano le seguenti righe: NETWORKING=yes FORWARD_IPV4=yes La prima riga dice a Linux che vogliamo che i dispositivi di rete vengano attivati al momento dell'avvio del sistema. La seconda riga dice a Linux di abilitare l'IP forwarding. Questo sarà richiesto quando andremo a configurare il masquerading nella Sezione 4. _N_o_t_a _d_i _R_e_d_h_a_t _6_._2_: Per supportare correttamente l'IP forwarding e il masquerading, Red Hat 6.2 richiede delle modifiche al file /etc/sysctl.conf. Assicurarsi che le seguenti righe esistano e che siano impostate con i valori corretti: net.ipv4.ip_forward = 1 net.ipv4.ip_always_defrag = 1 In Red Hat e nelle distribuzioni da essa derivate tutte le impostazioni delle interfacce di rete sono contenute in dei file che si trovano nella directory /etc/sysconfig/network-scripts. In questa directory, si crei il file ifcfg-eth1 con al suo interno le seguenti righe: DEVICE=eth1 IPADDR=192.168.1.1 ONBOOT=yes Queste impostazioni dicono agli script di rete di configurare eth1 al momento del boot e di assegnargli un particolare indirizzo IP. Attivare la propria rete con le nuove impostazioni per mezzo del seguente comando: /etc/rc.d/init.d/network restart 33..22..22.. IIll sseerrvveerr DDHHCCPP Un server DHCP configurerà automaticamente i dispositivi della rete casalinga interna con indirizzi IP. Questo è molto utile se si hanno dei computer portatili: si potranno semplicemente collegarli alla rete e saranno immediatamente configurati nel modo corretto. Se non si desidera impostare un server DHCP sulla rete interna, si può saltare questa sezione. Prima di tutto si deve essere sicuri di avere installato il server DHCP. Per far questo si monti il CD di Linux e si installi l'RPM relativo al dhcp. Quindi si modifichi il file /etc/dhcpd.conf con le seguenti righe (e solo queste): subnet 192.168.1.0 netmask 255.255.255.0 { range 192.168.1.2 192.168.1.60; default-lease-time 86400; max-lease-time 86400; option routers 192.168.1.1; option ip-forwarding off; option broadcast-address 192.168.1.255; option subnet-mask 255.255.255.0; } Se si ha intenzione di impostare la macchina Linux per funzionare da caching domain name server, si inserisca la seguente opzione: option domain-name-servers 192.168.1.1; Se si conosce l'indirizzo del server DNS esterno e _n_o_n si ha intenzione di usare la macchina Linux come server DNS, inserire la seguente opzione, dove x.x.x.x e y.y.y.y sono gli indirizzi IP dei server DNS esterni: option domain-name-servers x.x.x.x, y.y.y.y; Se si utilizzerà Samba come servizio di file sharing sulla macchina Linux per i computer Windows, si aggiungano le seguenti opzioni per usare la macchina Linux come server WINS e browsing server di default: option netbios-name-servers 192.168.1.1; option netbios-dd-server 192.168.1.1; option netbios-node-type 8; option netbios-scope ""; La configurazione di Samba e del WINS va al di là dello scopo di questo documento. Per informazioni a riguardo, si inizi col vedere il SMB HOWTO e si proceda da lì. Ci sono ancora un po' di passi da fare. Quindi, si modifichi il file /etc/rc.d/init.d/dhcpd ricercando la seguente riga: /sbin/route add -host 255.255.255.255 dev eth1 I client DHCP su cui gira Windows hanno bisogno di un particolare indirizzo di broadcast nelle risposte DHCP, e questo comando forza lo stack TCP/IP di Linux a produrlo. Se la riga precedente non c'è, _l_a _s_i _a_g_g_i_u_n_g_a. Se invece _s_i _t_r_o_v_a una riga analoga a quella precedente, ci si assicuri che il dispositivo a cui essa si riferisce sia eth1. Il prossimo passo consiste nel modificare il file /etc/rc.d/init.d/dhcpd per usare l'eth1 come il dispositivo di default. Sostituire la riga: daemon /usr/sbin/dhcpd con: daemon /usr/sbin/dhcpd eth1 Adesso siamo pronti per avviare il server DHCP con il comando: /etc/rc.d/init.d/dhcpd start. Quindi, dobbiamo accertarci che il server DHCP si avvii all'avvio del sistema. Alcuni pacchetti RPM del server DHCP non includono le direttive per garantire che il server parta ogni volta, così ci assicureremo che parta invocando il comando chkconfig dhcpd on. Questo comando fa sì che RedHat aggiunga lo script di avvio del DHCP nelle directory dei vari runlevel sotto /etc/rc.d. Nei runlevel 3 e 5 (multiuser console e multiuser X) il server DHCP viene avviato. Nei runlevel 0, 1 e 6 (shutdown, single user e reboot) il server DHCP viene disattivato. 33..22..33.. II ccoommppuutteerr cclliieenntt Se si è impostato il DHCP, la configurazione dei computer client è molto semplice: si abiliti semplicemente la configurazione tramite DHCP. Per i computer Windows, questo vuol dire aprire il "Pannello di Controllo", quindi cliccare sull'opzione "Rete", cercare il protocollo "TCP/IP" e continuare con "Configura". Spuntare l'opzione che dice "Configura l'indirizzo TCP/IP automaticamente", applicare le modifiche e riavviare. Prima di riavviare, si può digitare (sul gateway) il seguente comando: tail -f /var/log/messages. Questo visualizzerà il log di sistema di Linux continuamente. Se tutto è andato bene, quando il computer Windows verrà riavviato, si vedrà la sua richiesta di un indirizzo IP e la risposta da parte del server DHCP. Per interrompere il comando tail -f, premere Control-C. Se non si è impostato il DHCP, la configurazione è comunque piuttosto semplice. Si apra l'opzione "Rete" dal "Pannello di Controllo", e si scelga di configurare il protocollo TCP/IP. Si può assegnare ai computer client qualsiasi indirizzo nella rete 192.168.1.0 eccetto 192.168.1.0 (l'indirizzo di rete), 192.168.1.255 (l'indirizzo di broadcast) o 192.168.1.1 (il server Linux). Si ricordi di non assegnare mai lo stesso indirizzo IP a due computer. Si imposti l'indirizzo del "Gateway" a 192.168.1.1, cosicché il traffico in uscita sia indirizzato attraverso il gateway Linux. L'IP Masquerading HOWTO contiene informazioni molto dettagliate sulla configurazione dei client nella sezione relativa alla configurazione. In generale, per configurare un computer client, si abilita la configurazione tramite DHCP, oppure si assegna manualmente un indirizzo della rete 192.168.1.X con il gateway 192.168.1.1. Si faccia in modo che anche il server DNS sia 192.168.1.1 se si è attivato un caching DNS server (v. più avanti) oppure si imposti il DNS con gli indirizzi forniti dal provider. 33..22..44.. IIll sseerrvveerr DDNNSS Far funzionare la macchina Linux da caching DNS server migliorerà (leggermente) la velocità di navigazione, perché gli indirizzi DNS comunemente usati saranno salvati nella rete interna e non sarà necessario andarli a richiedere su Internet. Se si è interessati a creare un DNS pienamente funzionante, c'è una grande quantità di cose (complesse) da imparare. È disponibile un DNS HOWTO, e il libro DNS and BIND è un buon riferimento cartaceo (ed anche molto completo). Per fare in modo che le macchine client ottengano un vantaggio dal caching server, devono essere configurate per usare il gateway Linux come server DNS primario. Le direttive sul DHCP fornite nella sezione 3.2.2 sono un modo per farlo. Se i client sono configurati manualmente, si può cambiare la configurazione relativa al DNS negli stessi file usati per impostare l'indirizzo IP della macchina. Per installare il server DNS, si installi l'RPM bind, quindi l'RPM caching-nameserver. A questo punto, è quasi tutto pronto. Appena installato, il caching server funzionerà bene, ma se si conoscono gli indirizzi IP dei DNS del provider Internet si possono migliorare leggermente le prestazioni modificando il file /etc/named.conf e aggiungendo la riga seguente subito dopo quella contenente la direttiva directory (dove x.x.x.x e y.y.y.y sono gli indirizzi IP del server DNS primario e secondario): forwarders { x.x.x.x; y.y.y.y; }; Questa modifica fa in modo che il server DNS interno interroghi i server DNS del provider prima di attraversare Internet alla ricerca di un dato indirizzo. I server dei provider hanno spesso una cache di informazioni DNS molto ricca e possono offrire più velocemente una risposta rispetto a quanto possa fare il server DNS interno. Il demone named ha avuto qualche problema di sicurezza negli ultimi 12 mesi, perciò è molto importante utilizzare l'ultima versione, e fare qualche cambiamento alle impostazioni di default per aumentare la sicurezza. 1. Si controlli la versione di bind e ci si assicuri che sia almeno la 8.2.2. Controllare l'ultima versione sul sito Red Hat Updates oppure Mandrake Updates. 2. Si restringa l'accesso al name server interno solo alla rete locale aggiungendo la riga allow-query { 192.168.1/24; 127.0.0.1/32; }; nel file /etc/named.conf subito dopo la direttiva forwarders. 3. Si eviti di far girare il name server con i privilegi di root. Se il server girasse con tali privilegi, un exploit del server concederebbe all'intruso i privilegi di root. Facendo girare il server con i diritti di un utente con delle restrizioni, come nobody, si possono diminuire i rischi dovuti ad un eventuale exploit. Per far girare il name server come nobody, si modifichi il file /etc/rc.d/init.d/named cambiando la riga daemon named in daemon named -u nobody -g nobody. Per assicurarsi che il server DNS parta al momento del boot, digitare: chkconfig named on. Di nuovo, questo assicura che il servizio venga attivato al boot per i runlevel usuali (3 e 5). Bene, adesso si può avviare il server DNS: /etc/rc.d/init.d/named start 33..22..55.. VVeerriiffiiccaarree llaa rreettee iinntteerrnnaa Finché non configuriamo la rete esterna, il servizio DNS non funzionerà (visto che deve comunicare con altri server DNS su Internet), ma possiamo provare la connettività interna di base con il programma ping. Su uno dei computer client, si apra un terminale (MSDOS), e si digiti ping 192.168.1.1. Questo spedirà pacchetti verso la macchina Linux ad intervalli regolari, e la macchina Linux risponderà con altri i pacchetti. Se le cose stanno funzionando nel modo giusto, si dovrebbero vedere i tempi di ritorno dei pacchetti. 33..33.. CCoonnffiigguurraarree llaa rreettee eesstteerrnnaa Ora siamo pronti per configurare la rete esterna. Talvolta può essere difficoltoso, a seconda di quanto il provider supporta Linux. Se si hanno delle difficoltà, c'è un ADSL mini-HOWTO che descrive più dettagliatamente gli aspetti dell'ADSL. Se riesco a trovare un HOWTO sui modem, inserirò il link. Il problema principale della maggior parte delle connessioni è quello di _o_t_t_e_n_e_r_e _u_n _i_n_d_i_r_i_z_z_o _I_P. Alcuni provider Internet assegnano indirizzi IP statici agli abbonati ADSL, e in questo caso la configurazione è semplice. Però, la maggior parte dei provider si sono spostati verso la configurazione dinamica mediante (indovinato) il DHCP. Questo vuol dire che il computer Linux fungerà da _s_e_r_v_e_r DHCP sull'interfaccia eth1, e da _c_l_i_e_n_t DHCP sull'interfaccia eth0. Inoltre, molti provider hanno iniziato a fornire i loro servizi in modi specializzati e non standard presumendo che i loro clienti stiano usando Windows. Alcuni di questi casi saranno discussi alla fine della sezione 3.3.2. 33..33..11.. CCoonn uunn IIPP ssttaattiiccoo Se il provider Internet fornisce un indirizzo IP statico, siamo in una botte di ferro. Prima di tutto, si crei un nuovo file di configurazione relativo ad un'interfaccia, /etc/sysconfig/network- scripts/ifcfg-eth0 contenente le seguenti righe: DEVICE=eth0 IPADDR=x.x.x.x NETMASK=y.y.y.y ONBOOT=yes Sostituire x.x.x.x e y.y.y.y con i valori forniti dal provider Internet. Adesso si modifichi il file /etc/resolv.conf e si inseriscano le seguenti informazioni: search dominio_del_provider nameserver n.n.n.n nameserver m.m.m.m Il dominio_del_provider dovrebbe essere fornito dal provider Internet. Quindi si inserisca l'indirizzo IP del DNS primario e quello del DNS secondario al posto di n.n.n.n e m.m.m.m. Se la macchina Linux è stata impostata per funzionare da server DNS, si può aggiungere la riga nameserver 127.0.0.1 prima delle altre direttive nameserver. Ciò farà sì che venga usato il caching server prima di inoltrare richieste all'esterno per richiedere informazioni concernenti il DNS. 33..33..22.. CCoonn iill DDHHCCPP Se il provider Internet usa la configurazione dinamica mediante DHCP, si deve creare un nuovo file di configurazione per la relativa interfaccia, /etc/sysconfig/network-scripts/ifcfg-eth0 ed inserirvi le righe seguenti: DEVICE=eth0 BOOTPROTO=dhcp ONBOOT=yes Ci si assicuri che il demone dhcpcd client sia installato sul sistema: inserire il CD di Linux ed installa il pacchetto RPM dhcpcd. È il momento di verificare la configurazione di rete del sistema. Si può usare semplicemente il comando /etc/rc.d/init.d/network restart. Quindi si verifichi la connessione esterna eseguendo ping verso un computer su Internet, tipo www.yahoo.com, e si controlli che qualcosa ritorni indietro. 33..33..33.. SSttrraanneezzzzee eedd aannoommaalliiee La situazione reale può differire dalle semplicistiche situazioni qui descritte. Ecco qualche breve nota sulle varie difficoltà riscontrabili ed i link alle risorse più autorevoli per procedere alla loro risoluzione. Si ringrazia John Mellor per aver fornito i link e per avermi spinto ad aggiungere questa sezione. 33..33..33..11.. PPPPPP OOvveerr EEtthheerrnneett ((PPPPPPooEE)) Molti provider ADSL (Bell Atlantic, per esempio) stanno attualmente insistendo che il loro nuovi utenti debbano utilizzare, per connettersi al servizio, il protocollo "PPP over Ethernet" (PPPoE). A tal fine, forniscono un programma client per Windows: non molto utile per gli utenti Linux. Fortunatamente, PPPoE è un protocollo semplice e sono in corso molti sforzi per il supporto sotto Linux. · Il Roaring Penguin PPPoE Client è consigliato da Kerr First. · PPPoE on Linux for Bell Sympatico <* http://www.panix.com/~dfoster/prog/linux/pppoe.html> · PPPoE on Linux for Sympatico (General Info) (Linux Info) 33..33..33..22.. SSeemmpplliiccii ttrruucccchhii ppeerr iill DDHHCCPP Una delle abitudini preferite che hanno i provider è quella di legare il servizio ad un solo hostname, o comunque a una sola interfaccia di rete. Probabilmente questo è per prevenire che si possano collegare più computer alla stessa porta ethernet utilizzando un hub (naturalmente, usando Linux e il Masquerading si può ottenere lo stesso effetto con una maggiore sicurezza e la compagnia telefonica non ha modo di saperlo!). Se il provider ci ha assegnato un hostname ed ha insistito affinché si impostasse la macchina Windows con questo nome, al fine di usare il loro servizio, allora bisogna assicursi che la macchina Linux invii questo hostname quando fa una richiesta al DHCP per ottenere un indirizzo IP. Il client DHCP di Red Hat viene chiamato quando si imposta il BOOTPROTO con dhcp nel file di configurazione dell'interfaccia, ma viene chiamato senza riferimenti ad un hostname. Per chiamare il programma con un hostname, in Red Hat 6.1, si modifichi il file /etc/sysconfig/network, cambiando la riga: HOSTNAME= In modo che risulti come questa: HOSTNAME=nome_assegnato_dal_provider In alcune varianti di Red Hat potrebbe non funzionare. Se non funziona, controllare lo script /sbin/ifup e guardando se le chiamate a dhcpcd e pump includono il parametro -h $HOSTNAME. Se non lo fanno, lo si aggiunga, in modo che esse risultino analoghe a /sbin/dhcpcd -i $DEVICE -h $HOSTNAME e /sbin/pump -i $DEVICE -h $HOSTNAME. 33..33..33..33.. RRooaadd RRuunnnneerr Il servizio Road Runner ha un processo di login particolare che deve essere eseguito prima che il server possa essere utilizzato. Fortunatamente è disponibile un dettagliato http://usmcug.usm.maine.edu/~kpesce/rr}{Linux Road Runner HOWTO}. 33..33..44.. UUnnoo ssgguuaarrddoo aallllee iimmppoossttaazziioonnii ddii rreettee Ora si ammiri il proprio lavoro. Si digiti ifconfig per vedere la configurazione di tutti i dispositivi di rete. Sul gateway dovrebbe risultare qualcosa di analogo a: eth0 Link encap:Ethernet HWaddr 00:60:67:4A:02:0A inet addr:24.65.182.43 Bcast:24.65.182.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:487167 errors:0 dropped:0 overruns:0 frame:0 TX packets:467064 errors:0 dropped:0 overruns:0 carrier:0 collisions:89 txqueuelen:100 Interrupt:10 Base address:0xe400 eth1 Link encap:Ethernet HWaddr 00:80:C8:D3:30:2C inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:284112 errors:0 dropped:0 overruns:0 frame:1 TX packets:311533 errors:0 dropped:0 overruns:0 carrier:0 collisions:37938 txqueuelen:100 Interrupt:5 Base address:0xe800 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:3924 Metric:1 RX packets:12598 errors:0 dropped:0 overruns:0 frame:0 TX packets:12598 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 Si noti che l'interfaccia eth0 ha un indirizzo IP esterno di fantasia, e l'eth1 ha un indirizzo interno privato. Si dia un'occhiata alla tabella di routing digitando il comando route. Sul gateway dovrebbe risultare qualcosa di analogo a: Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 255.255.255.255 * 255.255.255.255 UH 0 0 0 eth1 192.168.1.0 * 255.255.255.0 U 0 0 0 eth1 24.65.182.0 * 255.255.255.0 U 0 0 0 eth0 127.0.0.0 * 255.0.0.0 U 0 0 0 lo default 24.65.182.1 0.0.0.0 UG 0 0 0 eth0 Quindi, abbiamo verificato che la rete esterna è configurata, la rete interna è configurata, il dispositivo locale è configurato, l'indirizzo speciale di broadcast 255.255.255.255 è configurato, e la route di default è configurata per puntare al gateway di default del provider. Perfetto! Ora si hanno la rete interna e quella esterna. Tutto quello che rimane da fare consiste nell'aprire la porta fra le due. Quindi, per prima cosa dobbiamo assicurarci che nessun "mostro" possa entrare dall'esterno. 33..44.. SSiiccuurreezzzzaa Uno degli inconvenienti nello stare connessi a Internet in modo permanente tramite l'ADSL o via modem è che il computer è esposto a potenziali minacce alla sicurezza per 24 ore al giorno, 7 giorni alla settimana. Utilizzare Linux come gateway riduce i rischi, perché esso nasconde gli altri computer: per quanto riguarda Internet, solo la macchina Linux è disponibile per le connessioni. Questo vuol dire che la rete interna è sicura quanto la macchina Linux, così a questo punto saranno firniti dei consigli basilari per rendere la macchina Linux più sicura. Per prima cosa, si devono chiudere fuori tutti i tipi cattivi. Per fare questo, si modifichi il file /etc/hosts.deny in modo che somigli a questo: # # hosts.deny This file describes the names of the hosts which are # *not* allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # # The portmap line is redundant, but it is left to remind you that # the new secure portmap uses hosts.deny and hosts.allow. In particular # you should know that NFS uses portmap! ALL: ALL Questo indica ai "TCP wrappers" -- che controllano il 95% delle connessioni in entrata -- di negare tutte le connessioni provenienti da qualsiasi computer. Questa è una regola piuttosto buona! Ma, ma ti impedirà anche di accedere alla macchina Linux dall'interno della rete casalinga, che è una seccatura, così faremo un'eccezione: si modifichi il file /etc/hosts.allow in modo che somigli a questo: # # hosts.allow This file describes the names of the hosts which are # allowed to use the local INET services, as decided # by the '/usr/sbin/tcpd' server. # ALL: 127.0.0.1 ALL: 192.168.1. Questo indica ai "TCP wrappers" di permettere connessioni a tutti i servizi dal dispositivo di loopback (127.0.0.1) e dalla rete casalinga (192.168.1.). Adesso sono stati chiusi fuori i mostri, con un potente lucchetto. Se si vogliono attivare barriere e sistemi di allarme, si dovrà essere un po' più sofisticati. Il Security HOWTO è un buon posto per iiziare se si desidera imparare qualcosa di più su come mettere in sicurezza la macchina Linux. 44.. CCoonnffiigguurraarree iill MMaassqquueerraaddiinngg Tutto a posto! I preliminari sono finiti, adesso siamo dove inizia la magia. L'IP masquerading è uno dei servizi veramente magici che Linux fornisce. Ci sono prodotti commerciali per Windows che fanno la stessa cosa, ma non in modo così efficace: un vecchio 386 può felicemente fornire servizi di IP masquerading per un intero ufficio di medie dimensioni, ma non riesce a far girare Windows 95, anche solo col pacchetto di masquerading (come supplemento, ho letto su alcune recenti riviste che Windows 2000 supporterà la "condivisione delle connessioni" senza nessun software aggiuntivo -- questo suona come se le compagnie che vendevano software di condivisione delle connessioni siano state "abbracciate ed estese" dalla Microsoft -- comunque, non consiglio di provare Windows 2000 su un 386). Linux ha funzionalità di firewall estremamente versatili, ed adesso le andremo ad utilizzare nella maniera più semplice e cruda. Se si desidera imparare come implementare un firewall da esperto, si dovrebbe leggere sia il Firewalling HOWTO per capire la teoria e l'IPChains HOWTO per le istruzioni sul nuovo strumento di firewall ipchains che viene fornito col kernel 2.2.X (e per estensione con Red Hat 6.X). È anche disponibile un IP Masquerading HOWTO molto buono che contiene molti più dettagli riguardo ai trucchi sul masquerading. Una volta che la rete interna e quella esterna sono operative, configurare un semplice masquerading è molto facile. Si modifichi il file /etc/rc.d/rc.local aggiungendo le seguenti righe: # 1) Svuota le tabelle delle regole. /sbin/ipchains -F input /sbin/ipchains -F forward /sbin/ipchains -F output # 2) Imposta i tempi del MASQ e consente i pacchetti in entrata per la configurazione DHCP. /sbin/ipchains -M -S 7200 10 60 /sbin/ipchains -A input -j ACCEPT -i eth0 -s 0/0 68 -d 0/0 67 -p udp # 3) Nega tutti i pacchetti di forwarding tranne quelli della rete interna. # Maschera questi ultimi. /sbin/ipchains -P forward DENY /sbin/ipchains -A forward -s 192.168.1.0/24 -j MASQ # 4) Carica i moduli di forwarding per i servizi speciali. /sbin/modprobe ip_masq_ftp /sbin/modprobe ip_masq_raudio Le ultime due righe caricano i moduli del kernel che permettono all'FTP ed a RealAudio di funzionare sui computer della rete interna. Ci sono altri moduli per i servizi speciali che possono essere aggiunti se se ne ha bisogno: · CUSeeMe (/sbin/modprobe ip_masq_cuseeme) · Internet Relay Chat (/sbin/modprobe ip_masq_irc) · Quake (/sbin/modprobe ip_masq_quake) · VDOLive (/sbin/modprobe ip_masq_vdolive) Ora siamo pronti per provare il masquerading! Si lanci lo script rc.local con il comando /etc/rc.d/rc.local e siamo pronti a partire! Ci si sieda davanti ad uno degli altri computer e si provi a navigare nel web. Con un po' di fortuna, ogni cosa funzionerà. 55.. PPrroobblleemmii Ci sono un po' di problemi e un po' di cose che possono andare male usando un documento semplice come questo, perché ci sono diversi casi particolari. La maggior parte di essi riguardano la configurazione degli apparati della rete interna e di quella esterna. Cercherò di rispondere alle persone che hanno dei problemi: segnalatemi cosa è andato male e aggiungerò dei link in questo documento, così le persone che hanno problemi riguardanti casi particolari possono avere una traccia per un aiuto. Contattatemi pure all'indirizzo pramsey@refractions.net. 55..11.. IICCQQ nnoonn ffuunnzziioonnaa Alcune parti di ICQ funzionano bene con il masquerading. Altre parti non funzionano affatto. C'è un modulo ICQ beta, anche se in fase di sviluppo, che risolve alcuni dei problemi (ma non tutti) nel far girare ICQ con il masquerading. Il file README nel codice sorgente della distribuzione descrive come compilare il modulo. Una volta compilato ed installato, si digiti /sbin/modprobe ip_masq_icq. 55..22.. SSee ssii hhaa CCaallddeerraa 22..XX ee nnoonn RReedd HHaatt 66..XX Bene, per prima cosa congratulazioni per la controtendenza! Seconda cosa, Nelson Gibbs (ngibbs@pacbell.net) invia buone notizie, perché molte di queste istruzioni saranno valide per Caldera. Ci sono alcuni cambiamenti importanti da tenere in conto, comunque: 1. Una dichiarazione GATEWAY=xxx.xxx.xxx.xxx nei file /etc/sysconfig/network-scripts/ifcfg-eth0 ed eth1 per l'interfaccia (l'interfaccia locale usa un indirizzo IP remoto e l'interfaccia remota usa l'IP del gateway del provider). 2. Ci si assicuri che lo script /etc/sysconfig/daemons/dhcpd segnali ROUTE_DEVICE come eth1 e _n_o_n eth0. 3. /etc/dhcpd.conf richiede una dichiarazione di sottorete per entrambe le interfacce (non sono completamente sicuro perché ho fatto la seconda dichiarazione: subnet 216.102.154.201 netmask 255.255.255.255 { } senza nessun'altra opzione ed il server DHCP ascolta e spedisce sulla eth0 e la eth1). Il server DHCP dà errore se è specificata una sola sottorete. 4. _N_o_n aggiungere la route all'host 255.255.255.255, lo script /etc/rc.d/init.d/dhcpd che usa Caldera ha già risolto il problema. _A_s_s_i_c_u_r_a_r_s_i di cambiare a eth1 tutti i riferimenti all'eth0 contenuti nello script. 55..33.. SSii vvuuoollee cchhee uunnaa ddeellllee mmaacccchhiinnee iinntteerrnnee ffuunnzziioonnii ccoommee sseerrvveerr WWeebb Una cosa da nulla! Comunque, _s_i _h_a _b_i_s_o_g_n_o _d_i _u_n _i_n_d_i_r_i_z_z_o _I_P _s_t_a_t_i_c_o affinché questa semplice serie di istruzioni funzioni. Nel caso di indirizzo IP dinamico, si avrà bisogno di qualche script in più per assicurarci che l'indirizzo IP sia aggiornato nei comandi di port forwarding quando l'indirizzo cambia. Si ricordi che fare il forwarding di una porta esterna su una macchina interna rende la macchina "interna" meno "interna" di prima, ma può essere fatto in maniera trasparente e con una degradazione delle prestazioni praticamente nulla. Uno degli effetti collaterali del codice dell'IP masquerading nel kernel di Linux è l'abilità di fare alcuni giochetti divertenti con i pacchetti quando questi raggiungono lo strato network, e ipmasqadm ne trae vantaggio. Per alcune ragioni ipmasqadm non è fornito con tutte le varianti di Red Hat e di Mandrake, quindi si dovrà probabilmente scaricarlo dal sito web del manutentore -- esiste un RPM ed anche il codice sorgente. Una volta ottenuto l'RPM, lo si installi e si aggiungano le seguenti righe al file /etc/rc.d/rc.local: /usr/sbin/ipmasqadm portfw -f /usr/sbin/ipmasqadm portfw -a -P tcp -L x.x.x.x 80 -R 192.168.1.x 80 Il primo comando svuota le regole del port forwarding ed il secondo comando aggiunge il forward dalla porta 80 dell'interfaccia esterna alla porta 80 della macchina interna che fa da web server. Si noti che l'indirizzo IP statico esterno va al posto di x.x.x.x e l'indirizzo IP dell'interfaccia della macchina interna va al posto di 192.168.1.x. Adesso le richieste esterne per la porta 80 saranno redirette in modo trasparente alla porta 80 della macchina interna. Non si può testare questo meccanismo effettuando un telnet o connettendosi alla porta 80 del gateway da una delle macchine interne: il port forwarder serve solo le richieste che arrivano sull'interfaccia _e_s_t_e_r_n_a.