➪ (Under refinement...)
Introduzione
Malgrado gli innumerevoli post e le varie guide sembra che Samba sia ancora un argomento interessante pieno di domande da parte di noi utenti (e qualche volta amministratori) a causa forse della sua natura interdisciplinare e per questo complessa. Si va dal networking al internetworking al securing ed altro in cui ogni settore se andiamo ad approfondirlo è...quasi una "scienza" a se stante. Se questo non bastasse per implementare la condivisone è necessaria la conoscenza specifica che si deve avere non per uno bensì per due Sistemi Operativi(OS's): Windows e *nix.
Personalmente ho trovato tanta informazione nel net e questo è positivo, ma purtroppo ha l' inconveniente di essere "dispersiva" o spesso troppo focalizzata su dei problemi specifici. Mettere quindi insieme tutti questi pezzi non è stato, almeno per me, banale. In verità forse sarebbe più appropriato prendere da subito dei buoni libri fra le mani. Conoscendo bene quanto essi costano cercherò di simularlo qui in piena sintonia con lo spirito F/LOSS OSS o più appropriatamente CC.
Lo scopo principale di questi "Appunti sulle reti e Samba" non è risolvere velocemente un particolare problema (per questo esistono in giro una marea di post, guide, how-to ecc) ma:
- prima di tutto comprendere, guardando estensivamente nel contorno, ciò che riguarda il mettere in comunicazione macchine che "girano" diversi OS e condividono risorse (files/directory/stampanti/dispositivi ATAPI ) nella stessa LAN e solo successivamente cominciare ad implementare.
- unificare da diverse fonti tutto il materiale necessario (riportando tutto quanto serve per una comprensione base) in questo testo e rimandare al ipertesto per eventuali approfondimenti successivi.
Questo modo si procedere ci farà innanzitutto prendere coscienza e capire tutto ciò che succede dietro le quinte e di conseguenza ci farà entrare pian piano sempre più nell' universo Samba aiutandoci di fare delle scelte via via più consapevoli e sicure indifferentemente se dovessimo intervenire su una rete di soli due o di qualche centinaio/migliaio di hosts.
NOTA: Gli OS utilizzati qui sono le versioni in inglese di Windows XP Professional SP2 e Ubuntu Intrepid Ibex (8.10 ma vale pure per 9.04 e successive). I link su wikipedia o altre fonti li ho scelti di proposito in lingua inglese per il semplice fatto che essendo essa la lingua franca qui (e in genere nel campo ingegneristico) queste fonti sono molto più complete delle corrispondenti localizzate nelle altre lingue. Quindi per chi non ha dimestichezza traduttore + ... intuizione e il giuoco è fatto.
Se in ogni caso si vuole usare wikipedia in Italiano una volta caricata la pagina in Inglese basta sostituire nella barra indirizzi del browser en. con it. e premere il tasto di ricaricamento (refresh) della pagina(F5 o CTRL + F5). p.e. http://en.wikipedia.org/wiki/Point-to-Point_Protocol ---> http://it.wikipedia.org/wiki/Point-to-Point_Protocol . Se la pagina in italiano esiste spunterà (anche se quasi sicuramente sarà più povera di informazioni).
Se in ogni caso si vuole usare wikipedia in Italiano una volta caricata la pagina in Inglese basta sostituire nella barra indirizzi del browser en. con it. e premere il tasto di ricaricamento (refresh) della pagina(F5 o CTRL + F5). p.e. http://en.wikipedia.org/wiki/Point-to-Point_Protocol ---> http://it.wikipedia.org/wiki/Point-to-Point_Protocol . Se la pagina in italiano esiste spunterà (anche se quasi sicuramente sarà più povera di informazioni).
Network intercomunicante?
Quando per esempio si vuole:
- Usare una stampante in LAN da ogni host della LAN (non collegato ovviamente direttamente alla stampante con cavo p.e. tramite porta USB o porta RS232 )
- Condividere dispositivi ATAPI(CD/DVD-ROM), i nostri files, directory, stampanti con altri hosts o semplicemente accedere alle suddette risorse messe in condivisione da altri hosts
- Fare il backup centralizzato di tutti i PC appartenenti alla rete in una base dati della stessa LAN
- Usare software applicativo di rete (progettato cioè per essere usato da più utenti contemporaneamente e per un accesso concorrente verso l' informazione che viene aggiornata in tempo reale) tipo databases (basi di dati), workgroup scheduling, calendar programs, email
- Condividere una connessione a Internet da parte di più PC
- Giocare multi-user games dentro una home/office LAN o su Internet
Ruoli del PC
- Un standalone computer : lavora in completo isolamento
- Un standalone computer connesso saltuariamente ad altri via un qualche modem
- Un membro di un piccolo gruppo di lavoro (workgroup) di computers senza un server centrale in un peer-to-peer network in cui ogni PC è essenzialmente indipendente dagli altri come se fosse un standalone computer se non fosse che qualcuno mette in condivisione qualche risorsa(una cartella, altro ). Ogni peer(host) può eseguire indifferentemente il suo OS di preferenza(Windows, Mac OSX, Linux, BSD o ogni SO su cui è stato portato il protocollo SMB).
- Un membro di un piccolo gruppo di lavoro (workgroup) di computers sotto la supervisione di un server centrale, questa volta a differenza di prima(rete peer-to-peer) ci sarà un host supervisore(server). Il server conterrà almeno un' informazione su nomi utente/passwords dei hosts . Gli altri host saranno i clients in un client-server network. I servers possono essere Samba (su *nix-boxes), Windows XP Professional (La versione XP Professional è limitata da Microsoft fino a sole 10 connessioni contemporanee. Per più connessioni si deve rivolgere alla versione Server), Windows Server 2008-2003-2000 (nelle varie versioni Advanced Server, Enterprise Server, o Data Center), Novell NetWare
- Un membro di una rete client-server che a sua volta è connessa ad altre reti p.e. un computer in un ufficio distaccato di una grande compagnia che ha sede in qualche altra parte del mondo. Questo forma il cosiddetto enterprise network e dà una grande importanza alla gestione, sicurezza, allocazione di risorse su diciamo un' “infinità” di hosts diffusi su una WAN
Nota: Windows XP Professional ha tutto il necessario per essere impiegato fino ad una rete peer-to-peer (sempre col limite di 10 connessioni contemporanee). Non può invece agire da database centralizzato per una rete client-server o addirittura in un contesto Active Directory. D' altro canto *nix (e quindi anche Ubuntu + Samba) invece fa fronte tranquillamente a tutti i ruoli suddetti e per di più gratis(FSM). Visti i tempi di crisi che percorriamo non e' proprio un aspetto da sottovalutare. Per prendere coscienza dell' ordine di grandezza sul aspetto economico un' occhiata qui chiarirebbe eventuali dubbi.
Per trattare questo argomento piuttosto complesso (nelle sue sfaccettature) in modo relativamente semplice ed approfondito l' ho scisso in due parti ben distinte (anche se a volte ridondanti). La prima tratterà il networking Windows e l' altra il networking Linux (*nix in generale).
Network Clients
Windows XP ha tutte e due le componenti client e server dell' architettura Samba. Più precisamente Microsoft fornisce Windows XP con due clients:
Per i non allenati: prima di proseguire raccomando caldamente una lettura del paragrafo seguente (Networking vademecum) rimandando ad eventuali approfondimenti sui seguenti link:
Nota: Non se la prendano i più letterati per la grossolana trattazione usata qui ma la divulgazione è un' arte IMHO ... affatto semplice...
Networking vademecum
Fondamenti di Microsoft Windows networking
Network Clients
Windows XP ha tutte e due le componenti client e server dell' architettura Samba. Più precisamente Microsoft fornisce Windows XP con due clients:
- il client per reti Microsoft (che è quello a cui noi siamo interessati qui): Esso usa i due protocolli Server Message Block (SMB) e NetBIOS over TCP/IP (NetBT) per comunicare con altri host Windows, Windows 2K Servers, e IBM OS/2 LAN Manager Servers. SMB e NetBIOS sono implementati (nascosti per un interazione diretta) dentro il sistema client-server della suite di networking Microsoft dentro il sistema operativo.
- il client per reti Novell NetWare (precisamente Novell oltre alla versione distribuita da Microsoft fornisce anche la propria versione per il suo client che si può scaricare dal loro sito): Il client per reti Novell usa invece il proprio NetWare Core Protocol (NCP) per comunicare col server Novell NetWare-- che è un servizio di rete per Windows XP o Windows 2000 Server--oppure con File Services for Novell Networks (disponibile, come pure il File Services for Macintosh, solo sulla versione Windows 2K Server di Microsoft Windows).
Per i non allenati: prima di proseguire raccomando caldamente una lettura del paragrafo seguente (Networking vademecum) rimandando ad eventuali approfondimenti sui seguenti link:
Nota: Non se la prendano i più letterati per la grossolana trattazione usata qui ma la divulgazione è un' arte IMHO ... affatto semplice...
Networking vademecum
È necessario capire almeno grossolanamente il meccanismo che sta sotto molti termini/acronimi nel ambito networking che troviamo qua e la nella Rete delle reti o nei testi.
Trasporto
Ognuno dei suddetti network clients usa un transport protocol (TCP/IP, IPX/SPX, NetBEUI --NetBIOS Enhanced User Interface--) per scambiare messagi (pacchetti) fra il nostro host e un host remoto che fa da server (e offre il servizio di condivisione). Vediamo brevemente i compiti espletati da questi protocolli:
Il TCP/IP (Transport Control Protocol/Internet Protocol)
IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange) Anch'esso è un set di protocolli che espleta esattamente la stessa funzione del TCP/IP. Fu sviluppato da Novell per il suo software di rete NetWare.
NetBEUI (NetBIOS Enhanced User Interface)
Fu sviluppato inizialmente da IBM per il suo IBM PC Network. Anch' esso svolge lo stesso lavoro di TCP/IP manca però di un meccanismo di routing verso reti esterne. Quindi può solo trasportare dati fra hosts che si trovano sulla stessa LAN fisica. Esso veniva supportato da Windows 9x fino all' arrivo di XP dopo di che Microsoft ha smesso di supportarlo.
Il TCP/IP (Transport Control Protocol/Internet Protocol)
- IP garantisce la trasmissione e l' internetwork routing
- TCP garantisce l' assenza di errori nel trasmettere i dati end to end (da host a host). Essendo IP(il livello rete) inaffidabile, TCP(il livello trasporto che sta sopra il livello rete nella pila dei protocolli TCP/IP) fa in modo che la connessione funzioni come una pipe(condotto) a due vie sulla quale due processi end to end possono scrivere o leggere.
Il protocollo TCP identifica i hosts e i servizi sui hosts dalla coppia (numero IP, porta) associata ad ogni host. Un host può fornire più servizi ognuno distinto dal suo numero di porta. La stessa porta può essere aperta simultaneamente su piu' host distinsti pero' solo un processo può aprire una determinata porta del host ad un determinato istante.
Una proprietà importante delle porte è che una volta stabilita la connessione client-server un altra copia(istanza) del server può associarsi alla stessa porta e mettersi in ascolto di ulteriori clients. Questo permette accessi concorrenti di clients verso lo stesso server alla stessa porta. Tali connessioni si distinguono dal diverso numero di IP per ogni client connesso. IETF (Internet Engineering Task Force) regolarmente rilascia una RFC-1700 (Assigned Numbers) che descrive fra altre cose i numeri di porta dei cosiddetti well-known services. In questo modo ogni client conosce la mappa (servizio, porta). Linux per tale mappatura utilizza il file /etc/services$ cat /etc/services # Network services, Internet style # # Note that it is presently the policy of IANA to assign a single well-known # port number for both TCP and UDP; hence, officially ports have two entries # even if the protocol doesn't support UDP operations. # # Updated from http://www.iana.org/assignments/port-numbers and other # sources like http://www.freebsd.org/cgi/cvsweb.cgi/src/etc/services . # New ports will be added on request if they have been officially assigned # by IANA and used in the real-world or are needed by a debian package. # If you need a huge list of used numbers please install the nmap package. tcpmux 1/tcp # TCP port service multiplexer echo 7/tcp echo 7/udp discard 9/tcp sink null discard 9/udp sink null systat 11/tcp users daytime 13/tcp daytime 13/udp netstat 15/tcp qotd 17/tcp quote msp 18/tcp # message send protocol msp 18/udp chargen 19/tcp ttytst source chargen 19/udp ttytst source ftp-data 20/tcp ftp 21/tcp fsp 21/udp fspd ssh 22/tcp # SSH Remote Login Protocol ssh 22/udp telnet 23/tcp smtp 25/tcp mail time 37/tcp timserver time 37/udp timserver rlp 39/udp resource # resource location nameserver 42/tcp name # IEN 116 whois 43/tcp nicname tacacs 49/tcp # Login Host Protocol (TACACS) tacacs 49/udp re-mail-ck 50/tcp # Remote Mail Checking Protocol re-mail-ck 50/udp domain 53/tcp # name-domain server domain 53/udp mtp 57/tcp # deprecated tacacs-ds 65/tcp # TACACS-Database Service tacacs-ds 65/udp bootps 67/tcp # BOOTP server bootps 67/udp bootpc 68/tcp # BOOTP client bootpc 68/udp tftp 69/udp gopher 70/tcp # Internet Gopher gopher 70/udp rje 77/tcp netrjs finger 79/tcp www 80/tcp http # WorldWideWeb HTTP www 80/udp # HyperText Transfer Protocol link 87/tcp ttylink kerberos 88/tcp kerberos5 krb5 kerberos-sec # Kerberos v5 kerberos 88/udp kerberos5 krb5 kerberos-sec # Kerberos v5 supdup 95/tcp hostnames 101/tcp hostname # usually from sri-nic iso-tsap 102/tcp tsap # part of ISODE acr-nema 104/tcp dicom # Digital Imag. & Comm. 300 acr-nema 104/udp dicom # Digital Imag. & Comm. 300 csnet-ns 105/tcp cso-ns # also used by CSO name server csnet-ns 105/udp cso-ns rtelnet 107/tcp # Remote Telnet rtelnet 107/udp pop2 109/tcp postoffice pop-2 # POP version 2 pop2 109/udp pop-2 pop3 110/tcp pop-3 # POP version 3 pop3 110/udp pop-3 sunrpc 111/tcp portmapper # RPC 4.0 portmapper sunrpc 111/udp portmapper auth 113/tcp authentication tap ident sftp 115/tcp uucp-path 117/tcp nntp 119/tcp readnews untp # USENET News Transfer Protocol ntp 123/tcp ntp 123/udp # Network Time Protocol pwdgen 129/tcp # PWDGEN service pwdgen 129/udp # PWDGEN service loc-srv 135/tcp epmap # Location Service loc-srv 135/udp epmap netbios-ns 137/tcp # NETBIOS Name Service netbios-ns 137/udp netbios-dgm 138/tcp # NETBIOS Datagram Service netbios-dgm 138/udp netbios-ssn 139/tcp # NETBIOS session service netbios-ssn 139/udp imap2 143/tcp imap # Interim Mail Access P 2 and 4 imap2 143/udp imap snmp 161/tcp # Simple Net Mgmt Protocol snmp 161/udp # Simple Net Mgmt Protocol snmp-trap 162/tcp snmptrap # Traps for SNMP snmp-trap 162/udp snmptrap # Traps for SNMP cmip-man 163/tcp # ISO mgmt over IP (CMOT) cmip-man 163/udp cmip-agent 164/tcp cmip-agent 164/udp mailq 174/tcp # Mailer transport queue for Zmailer mailq 174/udp # Mailer transport queue for Zmailer xdmcp 177/tcp # X Display Mgr. Control Proto xdmcp 177/udp nextstep 178/tcp NeXTStep NextStep # NeXTStep window nextstep 178/udp NeXTStep NextStep # server bgp 179/tcp # Border Gateway Protocol bgp 179/udp prospero 191/tcp # Cliff Neuman's Prospero prospero 191/udp irc 194/tcp # Internet Relay Chat irc 194/udp smux 199/tcp # SNMP Unix Multiplexer smux 199/udp at-rtmp 201/tcp # AppleTalk routing at-rtmp 201/udp at-nbp 202/tcp # AppleTalk name binding at-nbp 202/udp at-echo 204/tcp # AppleTalk echo at-echo 204/udp at-zis 206/tcp # AppleTalk zone information at-zis 206/udp qmtp 209/tcp # Quick Mail Transfer Protocol qmtp 209/udp # Quick Mail Transfer Protocol z3950 210/tcp wais # NISO Z39.50 database z3950 210/udp wais ipx 213/tcp # IPX ipx 213/udp imap3 220/tcp # Interactive Mail Access imap3 220/udp # Protocol v3 pawserv 345/tcp # Perf Analysis Workbench pawserv 345/udp zserv 346/tcp # Zebra server zserv 346/udp fatserv 347/tcp # Fatmen Server fatserv 347/udp rpc2portmap 369/tcp rpc2portmap 369/udp # Coda portmapper codaauth2 370/tcp codaauth2 370/udp # Coda authentication server clearcase 371/tcp Clearcase clearcase 371/udp Clearcase ulistserv 372/tcp # UNIX Listserv ulistserv 372/udp ldap 389/tcp # Lightweight Directory Access Protocol ldap 389/udp imsp 406/tcp # Interactive Mail Support Protocol imsp 406/udp https 443/tcp # http protocol over TLS/SSL https 443/udp snpp 444/tcp # Simple Network Paging Protocol snpp 444/udp microsoft-ds 445/tcp # Microsoft Naked CIFS microsoft-ds 445/udp kpasswd 464/tcp kpasswd 464/udp saft 487/tcp # Simple Asynchronous File Transfer saft 487/udp isakmp 500/tcp # IPsec - Internet Security Association isakmp 500/udp # and Key Management Protocol rtsp 554/tcp # Real Time Stream Control Protocol rtsp 554/udp # Real Time Stream Control Protocol nqs 607/tcp # Network Queuing system nqs 607/udp npmp-local 610/tcp dqs313_qmaster # npmp-local / DQS npmp-local 610/udp dqs313_qmaster npmp-gui 611/tcp dqs313_execd # npmp-gui / DQS npmp-gui 611/udp dqs313_execd hmmp-ind 612/tcp dqs313_intercell # HMMP Indication / DQS hmmp-ind 612/udp dqs313_intercell qmqp 628/tcp qmqp 628/udp ipp 631/tcp # Internet Printing Protocol ipp 631/udp # # UNIX specific services # exec 512/tcp biff 512/udp comsat login 513/tcp who 513/udp whod shell 514/tcp cmd # no passwords used syslog 514/udp printer 515/tcp spooler # line printer spooler talk 517/udp ntalk 518/udp route 520/udp router routed # RIP timed 525/udp timeserver tempo 526/tcp newdate courier 530/tcp rpc conference 531/tcp chat netnews 532/tcp readnews netwall 533/udp # for emergency broadcasts gdomap 538/tcp # GNUstep distributed objects gdomap 538/udp uucp 540/tcp uucpd # uucp daemon klogin 543/tcp # Kerberized `rlogin' (v5) kshell 544/tcp krcmd # Kerberized `rsh' (v5) afpovertcp 548/tcp # AFP over TCP afpovertcp 548/udp remotefs 556/tcp rfs_server rfs # Brunhoff remote filesystem nntps 563/tcp snntp # NNTP over SSL nntps 563/udp snntp submission 587/tcp # Submission [RFC4409] submission 587/udp ldaps 636/tcp # LDAP over SSL ldaps 636/udp tinc 655/tcp # tinc control port tinc 655/udp silc 706/tcp silc 706/udp kerberos-adm 749/tcp # Kerberos `kadmin' (v5) # webster 765/tcp # Network dictionary webster 765/udp rsync 873/tcp rsync 873/udp ftps-data 989/tcp # FTP over SSL (data) ftps 990/tcp telnets 992/tcp # Telnet over SSL telnets 992/udp imaps 993/tcp # IMAP over SSL imaps 993/udp ircs 994/tcp # IRC over SSL ircs 994/udp pop3s 995/tcp # POP-3 over SSL pop3s 995/udp # # From ``Assigned Numbers'': # #> The Registered Ports are not controlled by the IANA and on most systems #> can be used by ordinary user processes or programs executed by ordinary #> users. # #> Ports are used in the TCP [45,106] to name the ends of logical #> connections which carry long term conversations. For the purpose of #> providing services to unknown callers, a service contact port is #> defined. This list specifies the port used by the server process as its #> contact port. While the IANA can not control uses of these ports it #> does register or list uses of these ports as a convienence to the #> community. # socks 1080/tcp # socks proxy server socks 1080/udp proofd 1093/tcp proofd 1093/udp rootd 1094/tcp rootd 1094/udp openvpn 1194/tcp openvpn 1194/udp rmiregistry 1099/tcp # Java RMI Registry rmiregistry 1099/udp kazaa 1214/tcp kazaa 1214/udp nessus 1241/tcp # Nessus vulnerability nessus 1241/udp # assessment scanner lotusnote 1352/tcp lotusnotes # Lotus Note lotusnote 1352/udp lotusnotes ms-sql-s 1433/tcp # Microsoft SQL Server ms-sql-s 1433/udp ms-sql-m 1434/tcp # Microsoft SQL Monitor ms-sql-m 1434/udp ingreslock 1524/tcp ingreslock 1524/udp prospero-np 1525/tcp # Prospero non-privileged prospero-np 1525/udp datametrics 1645/tcp old-radius datametrics 1645/udp old-radius sa-msg-port 1646/tcp old-radacct sa-msg-port 1646/udp old-radacct kermit 1649/tcp kermit 1649/udp l2f 1701/tcp l2tp l2f 1701/udp l2tp radius 1812/tcp radius 1812/udp radius-acct 1813/tcp radacct # Radius Accounting radius-acct 1813/udp radacct msnp 1863/tcp # MSN Messenger msnp 1863/udp unix-status 1957/tcp # remstats unix-status server log-server 1958/tcp # remstats log server remoteping 1959/tcp # remstats remoteping server cisco-sccp 2000/tcp sieve # Cisco SCCP cisco-sccp 2000/udp search 2010/tcp ndtp pipe_server 2010/tcp nfs 2049/tcp # Network File System nfs 2049/udp # Network File System gnunet 2086/tcp gnunet 2086/udp rtcm-sc104 2101/tcp # RTCM SC-104 IANA 1/29/99 rtcm-sc104 2101/udp gsigatekeeper 2119/tcp gsigatekeeper 2119/udp gris 2135/tcp # Grid Resource Information Server gris 2135/udp # Grid Resource Information Server cvspserver 2401/tcp # CVS client/server operations cvspserver 2401/udp venus 2430/tcp # codacon port venus 2430/udp # Venus callback/wbc interface venus-se 2431/tcp # tcp side effects venus-se 2431/udp # udp sftp side effect codasrv 2432/tcp # not used codasrv 2432/udp # server port codasrv-se 2433/tcp # tcp side effects codasrv-se 2433/udp # udp sftp side effect mon 2583/tcp # MON traps mon 2583/udp dict 2628/tcp # Dictionary server dict 2628/udp gsiftp 2811/tcp gsiftp 2811/udp gpsd 2947/tcp gpsd 2947/udp gds_db 3050/tcp # InterBase server gds_db 3050/udp icpv2 3130/tcp icp # Internet Cache Protocol icpv2 3130/udp icp mysql 3306/tcp mysql 3306/udp nut 3493/tcp # Network UPS Tools nut 3493/udp distcc 3632/tcp # distributed compiler distcc 3632/udp daap 3689/tcp # Digital Audio Access Protocol daap 3689/udp svn 3690/tcp subversion # Subversion protocol svn 3690/udp subversion suucp 4031/tcp # UUCP over SSL suucp 4031/udp # UUCP over SSL sysrqd 4094/tcp # sysrq daemon sysrqd 4094/udp # sysrq daemon remctl 4373/tcp # Remote Authenticated Command Service remctl 4373/udp # Remote Authenticated Command Service iax 4569/tcp # Inter-Asterisk eXchange iax 4569/udp radmin-port 4899/tcp # RAdmin Port radmin-port 4899/udp rfe 5002/udp # Radio Free Ethernet rfe 5002/tcp mmcc 5050/tcp # multimedia conference control tool (Yahoo IM) mmcc 5050/udp sip 5060/tcp # Session Initiation Protocol sip 5060/udp sip-tls 5061/tcp sip-tls 5061/udp aol 5190/tcp # AIM aol 5190/udp xmpp-client 5222/tcp jabber-client # Jabber Client Connection xmpp-client 5222/udp jabber-client xmpp-server 5269/tcp jabber-server # Jabber Server Connection xmpp-server 5269/udp jabber-server cfengine 5308/tcp cfengine 5308/udp mdns 5353/tcp # Multicast DNS mdns 5353/udp # Multicast DNS postgresql 5432/tcp postgres # PostgreSQL Database postgresql 5432/udp postgres freeciv 5556/tcp rptp # Freeciv gameplay freeciv 5556/udp amqp 5672/tcp amqp 5672/udp amqp 5672/sctp ggz 5688/tcp # GGZ Gaming Zone ggz 5688/udp # GGZ Gaming Zone x11 6000/tcp x11-0 # X Window System x11 6000/udp x11-0 x11-1 6001/tcp x11-1 6001/udp x11-2 6002/tcp x11-2 6002/udp x11-3 6003/tcp x11-3 6003/udp x11-4 6004/tcp x11-4 6004/udp x11-5 6005/tcp x11-5 6005/udp x11-6 6006/tcp x11-6 6006/udp x11-7 6007/tcp x11-7 6007/udp gnutella-svc 6346/tcp # gnutella gnutella-svc 6346/udp gnutella-rtr 6347/tcp # gnutella gnutella-rtr 6347/udp sge_qmaster 6444/tcp # Grid Engine Qmaster Service sge_qmaster 6444/udp # Grid Engine Qmaster Service sge_execd 6445/tcp # Grid Engine Execution Service sge_execd 6445/udp # Grid Engine Execution Service afs3-fileserver 7000/tcp bbs # file server itself afs3-fileserver 7000/udp bbs afs3-callback 7001/tcp # callbacks to cache managers afs3-callback 7001/udp afs3-prserver 7002/tcp # users & groups database afs3-prserver 7002/udp afs3-vlserver 7003/tcp # volume location database afs3-vlserver 7003/udp afs3-kaserver 7004/tcp # AFS/Kerberos authentication afs3-kaserver 7004/udp afs3-volser 7005/tcp # volume managment server afs3-volser 7005/udp afs3-errors 7006/tcp # error interpretation service afs3-errors 7006/udp afs3-bos 7007/tcp # basic overseer process afs3-bos 7007/udp afs3-update 7008/tcp # server-to-server updater afs3-update 7008/udp afs3-rmtsys 7009/tcp # remote cache manager service afs3-rmtsys 7009/udp font-service 7100/tcp xfs # X Font Service font-service 7100/udp xfs http-alt 8080/tcp webcache # WWW caching service http-alt 8080/udp # WWW caching service bacula-dir 9101/tcp # Bacula Director bacula-dir 9101/udp bacula-fd 9102/tcp # Bacula File Daemon bacula-fd 9102/udp bacula-sd 9103/tcp # Bacula Storage Daemon bacula-sd 9103/udp xmms2 9667/tcp # Cross-platform Music Multiplexing System xmms2 9667/udp # Cross-platform Music Multiplexing System amanda 10080/tcp # amanda backup services amanda 10080/udp hkp 11371/tcp # OpenPGP HTTP Keyserver hkp 11371/udp # OpenPGP HTTP Keyserver bprd 13720/tcp # VERITAS NetBackup bprd 13720/udp bpdbm 13721/tcp # VERITAS NetBackup bpdbm 13721/udp bpjava-msvc 13722/tcp # BP Java MSVC Protocol bpjava-msvc 13722/udp vnetd 13724/tcp # Veritas Network Utility vnetd 13724/udp bpcd 13782/tcp # VERITAS NetBackup bpcd 13782/udp vopied 13783/tcp # VERITAS NetBackup vopied 13783/udp wnn6 22273/tcp # wnn6 wnn6 22273/udp # # Datagram Delivery Protocol services # rtmp 1/ddp # Routing Table Maintenance Protocol nbp 2/ddp # Name Binding Protocol echo 4/ddp # AppleTalk Echo Protocol zip 6/ddp # Zone Information Protocol #========================================================================= # The remaining port numbers are not as allocated by IANA. #========================================================================= # Kerberos (Project Athena/MIT) services # Note that these are for Kerberos v4, and are unofficial. Sites running # v4 should uncomment these and comment out the v5 entries above. # kerberos4 750/udp kerberos-iv kdc # Kerberos (server) kerberos4 750/tcp kerberos-iv kdc kerberos_master 751/udp # Kerberos authentication kerberos_master 751/tcp passwd_server 752/udp # Kerberos passwd server krb_prop 754/tcp krb5_prop hprop # Kerberos slave propagation krbupdate 760/tcp kreg # Kerberos registration swat 901/tcp # swat kpop 1109/tcp # Pop with Kerberos knetd 2053/tcp # Kerberos de-multiplexor zephyr-srv 2102/udp # Zephyr server zephyr-clt 2103/udp # Zephyr serv-hm connection zephyr-hm 2104/udp # Zephyr hostmanager eklogin 2105/tcp # Kerberos encrypted rlogin # Hmmm. Are we using Kv4 or Kv5 now? Worrying. # The following is probably Kerberos v5 --- ajt@debian.org (11/02/2000) kx 2111/tcp # X over Kerberos iprop 2121/tcp # incremental propagation # # Unofficial but necessary (for NetBSD) services # supfilesrv 871/tcp # SUP server supfiledbg 1127/tcp # SUP debugging # # Services added for the Debian GNU/Linux distribution # linuxconf 98/tcp # LinuxConf poppassd 106/tcp # Eudora poppassd 106/udp ssmtp 465/tcp smtps # SMTP over SSL moira_db 775/tcp # Moira database moira_update 777/tcp # Moira update protocol moira_ureg 779/udp # Moira user registration spamd 783/tcp # spamassassin daemon omirr 808/tcp omirrd # online mirror omirr 808/udp omirrd customs 1001/tcp # pmake customs server customs 1001/udp skkserv 1178/tcp # skk jisho server port predict 1210/udp # predict -- satellite tracking rmtcfg 1236/tcp # Gracilis Packeten remote config server wipld 1300/tcp # Wipl network monitor xtel 1313/tcp # french minitel xtelw 1314/tcp # french minitel support 1529/tcp # GNATS cfinger 2003/tcp # GNU Finger frox 2121/tcp # frox: caching ftp proxy ninstall 2150/tcp # ninstall service ninstall 2150/udp zebrasrv 2600/tcp # zebra service zebra 2601/tcp # zebra vty ripd 2602/tcp # ripd vty (zebra) ripngd 2603/tcp # ripngd vty (zebra) ospfd 2604/tcp # ospfd vty (zebra) bgpd 2605/tcp # bgpd vty (zebra) ospf6d 2606/tcp # ospf6d vty (zebra) ospfapi 2607/tcp # OSPF-API isisd 2608/tcp # ISISd vty (zebra) afbackup 2988/tcp # Afbackup system afbackup 2988/udp afmbackup 2989/tcp # Afmbackup system afmbackup 2989/udp xtell 4224/tcp # xtell server fax 4557/tcp # FAX transmission service (old) hylafax 4559/tcp # HylaFAX client-server protocol (new) distmp3 4600/tcp # distmp3host daemon munin 4949/tcp lrrd # Munin enbd-cstatd 5051/tcp # ENBD client statd enbd-sstatd 5052/tcp # ENBD server statd pcrd 5151/tcp # PCR-1000 Daemon noclog 5354/tcp # noclogd with TCP (nocol) noclog 5354/udp # noclogd with UDP (nocol) hostmon 5355/tcp # hostmon uses TCP (nocol) hostmon 5355/udp # hostmon uses UDP (nocol) rplay 5555/udp # RPlay audio service nsca 5667/tcp # Nagios Agent - NSCA mrtd 5674/tcp # MRT Routing Daemon bgpsim 5675/tcp # MRT Routing Simulator canna 5680/tcp # cannaserver sane-port 6566/tcp sane saned # SANE network scanner daemon ircd 6667/tcp # Internet Relay Chat zope-ftp 8021/tcp # zope management by ftp tproxy 8081/tcp # Transparent Proxy omniorb 8088/tcp # OmniORB omniorb 8088/udp clc-build-daemon 8990/tcp # Common lisp build daemon xinetd 9098/tcp mandelspawn 9359/udp mandelbrot # network mandelbrot git 9418/tcp # Git Version Control System zope 9673/tcp # zope server webmin 10000/tcp kamanda 10081/tcp # amanda backup services (Kerberos) kamanda 10081/udp amandaidx 10082/tcp # amanda backup services amidxtape 10083/tcp # amanda backup services smsqp 11201/tcp # Alamin SMS gateway smsqp 11201/udp xpilot 15345/tcp # XPilot Contact Port xpilot 15345/udp sgi-cmsd 17001/udp # Cluster membership services daemon sgi-crsd 17002/udp sgi-gcd 17003/udp # SGI Group membership daemon sgi-cad 17004/tcp # Cluster Admin daemon isdnlog 20011/tcp # isdn logging system isdnlog 20011/udp vboxd 20012/tcp # voice box system vboxd 20012/udp binkp 24554/tcp # binkp fidonet protocol asp 27374/tcp # Address Search Protocol asp 27374/udp csync2 30865/tcp # cluster synchronization tool dircproxy 57000/tcp # Detachable IRC Proxy tfido 60177/tcp # fidonet EMSI over telnet fido 60179/tcp # fidonet EMSI over TCP
- Inoltre supporta l' indirizzamento di grandi reti (disponendo attualmente, e in modo transitorio, l' indirizzamento a 32-bits(4 bytes) di IPv4 , e nell' immediato futuro di indirizzamento di 128-bit(16 bytes) del nuovo IPv6) ed una struttura gerarchica di naming (tipo harrykar.blogspot.com). Riguardo Ipv6 una buona parte parte di applicazioni deve essere modificata per poterlo utilizzare.
Nota sui vantaggi dello stack TCP/IP(tutte le versioni di Windows già dal Windows 95 supportano anche TCP/IP) :
I protocolli più comuni supportati da TCP/IP includono HTTP, FTP, Simple Mail Transfer Protocol (SMTP), Network File System (NFS), Telnet, Secure Shell (SSH), Network News Transfer Protocol (NNTP), X Window System, e molti altri.
Fra i protocolli di trasporto della pila OSI quello che va per la maggiore è il TCP/IP. Il punto forte di TCP/IP è che gli strumenti che sono originariamente scritti per altri network stacks possono attualmente usare anche il TCP/IP.
I protocolli più comuni supportati da TCP/IP includono HTTP, FTP, Simple Mail Transfer Protocol (SMTP), Network File System (NFS), Telnet, Secure Shell (SSH), Network News Transfer Protocol (NNTP), X Window System, e molti altri.
Fra i protocolli di trasporto della pila OSI quello che va per la maggiore è il TCP/IP. Il punto forte di TCP/IP è che gli strumenti che sono originariamente scritti per altri network stacks possono attualmente usare anche il TCP/IP.
In particolare mi riferisco al protocollo file-sharing Server Message Block (SMB) [o Common Internet File System (CIFS) che si dica] usato da Windows che può andare su TCP/IP(NetBT) --via Network Basic Input/Output System(NetBIOS)-- , anzichè su NetBIOS Extended User Interface (NetBEUI), che è quella nativa (originaria) dello stack di protocolli per DOS e Windows.
Su una rete uniforme(ossia rete fatta da PC che eseguono lo stesso OS) di hosts Linux, il TCP/IP sarebbe una buona scelta a causa del suo supporto per la maggior parte dei protocolli di rete più importanti. Sebbene durante gli anni 1980 molte piattaforme non-Unix(Windows, Novell etc.) hanno sviluppato stack di protocolli proprietari, i sistemi Unix di allora usavano il TCP/IP, e quindi molti protocolli di rete Unix attuali continuano ad usare il TCP/IP. Linux ha ereditato questi protocolli, e cosi una rete con macchine solo Linux o *nix opera benissimo usando solo TCP/IP; Attualmente eccetto casi particolari non c'è bisogno di usare nessun altro network stack in un ambiente mono-OS eccetto se la rete contiene qualche sistema che esegue qualche Os vecchiotto che non supporta completamente il TCP/IP --tipo un vecchio Macintosh potrebbe supportare il file sharing solo su AppleTalk--, o potremmo avere dei sistemi DOS o Windows configurati per usare IPX o NetBEUI. In queste situazioni, il supporto di Linux per network stack alternativi può rivelarsi un gran vantaggio.
IPX/SPX (Internetwork Packet Exchange/Sequenced Packet Exchange) Anch'esso è un set di protocolli che espleta esattamente la stessa funzione del TCP/IP. Fu sviluppato da Novell per il suo software di rete NetWare.
NetBEUI (NetBIOS Enhanced User Interface)
Fu sviluppato inizialmente da IBM per il suo IBM PC Network. Anch' esso svolge lo stesso lavoro di TCP/IP manca però di un meccanismo di routing verso reti esterne. Quindi può solo trasportare dati fra hosts che si trovano sulla stessa LAN fisica. Esso veniva supportato da Windows 9x fino all' arrivo di XP dopo di che Microsoft ha smesso di supportarlo.
Risoluzione nomi (hostname resolution / address resolution)
Il software di rete ha la responsabilità di risolvere (trasformare, mappare) il nome di un host verso l' indirizzo fisico MAC associato ad ogni NIC (Network Interface Card). Più precisamente c'e una doppia trasformazione : Hostname -> IP -> MAC.
- La prima trasformazione Hostname -> IP si chiama hostname resolution: Quando un' applicazione abbisogna di trovare l' indirizzo IP di un host, usa le funzioni di libreria gethostbyname e gethostbyaddr. Tradizionalmente, queste funzioni insieme ad altre funzioni sono state raggruppate in una libreria a parte chiamata resolver library; su Linux, tali funzioni sono parte della libreria standard libc. Ad ogni modo tale set di funzioni si chiamano semplicemente come the resolver.
Su una piccola rete (come potrebbe essere una rete Ethernet o anche un cluster di Ethernets) non è molto difficile mantenere tabelle che mappano hostnames verso indirizzi IP. Tale informazione è di solito (se non si usa DNS o NIS) memorizzata in un file chiamato /etc/hosts. Quando aggiungiamo o rimuoviamo hosts, o riassegnammo indirizzi, tutto quello che si deve fare è aggiornare il file /etc/hosts per ogni host della rete.
Un qualche risolutore di nomi comunque è necessario anche quando non si eseguono delle interfacce di rete(per esempio durante la fase di booting). Inoltre ci aiuta nel uso di hostnames simbolici dentro gli scrips di rete rc in modo che se cambiano gli indirizzi IP a noi tocca solo copiare un file hosts modificato su tutti i PC e fare il reboot, anzichè editare separatamente un grande numero di files rc (run command).
Nel file /etc/hosts mettiamo tutti i host locali, i gateways e i server NIS --solo se si usa il NYS di Peter Eriksson. Le altre implementazioni di NIS localizzano i loro servers solo in runtime usando ypbind-- . Dobbiamo assicurarci che il nostro resolver usa solo informazioni dal file /etc/hosts durante il testing iniziale(perché i sample files(templates) che vengono con i software DNS o NIS possono produrre strani risultati).
Per far si che tutte le applicazioni usino esclusivamente /etc/hosts quando cercano l' indirizzo IP di un host dobbiamo modificare il file /etc/host.conf . Precisamente dobbiamo commentare (mettendo alla prima colonna un cancelleto) ogni linea che comincia con la keyword order (nel qualcaso ci fossero) e inserire solo la linea: order hosts
- Ecco la sintassi del file hosts:
The hosts file contains one entry per line, consisting of an IP address, a hostname, and an optional list of aliases for the hostname. The fields are separated by spaces or tabs, and the address field must begin in the first column. Anything following a hash sign (#) is regarded as a comment and is ignored. Hostnames can be either fully qualified or relative to the local domain. For example for vale, you would usually enter the fully qualified name, vale.vbrew.com, and vale by itself in the hosts file, so that it is known by both its official name and the shorter local name.
# Hosts file for Virtual Brewery/Virtual Winery
#
# IP FQDN aliases
#
127.0.0.1 localhost
#
172.16.1.1 vlager.vbrew.com vlager vlager-if1
172.16.1.2 vstout.vbrew.com vstout
172.16.1.3 vale.vbrew.com vale
#
172.16.2.1 vlager-if2
172.16.2.2 vbeaujolais.vbrew.com vbeaujolais
172.16.2.3 vbardolino.vbrew.com vbardolino
172.16.2.4 vchianti.vbrew.com vchianti
Ecco un esempio su come appare il file hosts della macchina vlager nel network Virtual Brewery. Il host vlager possiede due interfacce di rete. Quindi sono stati inclusi due nomi speciali, vlager-if1 e vlager-if2, che mappano gli indirizzi di entrambe le interfacce di rete sul host vlager. Cosi come per gli indirizzi IP degli hosts, talvolta si usa un nome simbolico anche per i network numbers. Perciò il file /etc/hosts ha un compagno chiamato /etc/networks che mappa network names verso network numbers, e viceversa. Nel network Virtual Brewery, noi dobbiamo installare un file networks (Nota che i nomi nelle reti non devono collidere con hostnames dal hosts file, altrimenti molti programmi produranno strani risultati):
In ogni caso tale metodo di gestione diventa difficile quando il numero di host aumenta.# /etc/networks for the Virtual Brewery
brew-net 172.16.1.0
wine-net 172.16.2.0
Una soluzione a questo problema è il Network Information System (NIS), sviluppato da Sun Microsystems, chiamato anche Yellow Pages(YP). NIS memorizza i file hosts (e altre informazioni) in un database su un host master da cui i clients possono ottenerli. Ancora una volta tale approccio va bene per reti di media grandezza come le LAN, a causa del mantenimento centralizzato e poi distribuzione dell' intero database dei hosts.
Pure in Internet, le informazioni sugli indirizzi furono state inizialmente immagazzinate in un singolo DB HOSTS.TXT. Tale file fu mantenuto da Network Information Center (NIC), e doveva essere scaricato ed installato da tutti i siti partecipanti. Quando poi il network diventò molto grande, tale schema cominciò a mostrare la corda. Al di la dell' overhead amministrativo(il carico dei server che lo distribuivano diventò molto alto) dovuto all' installazione frequente di HOSTS.TXT, ancor peggio, tutti propio tutti i nomi dei hosts della rete dovevano essere registrati nel NIC, assicurando cosi l' univocità del nome.Questi problemi hanno indotto nel 1994 a un nuovo schema di risoluzione nomi: il Domain Name System. DNS è stato progettato da Paul Mockapetris ed ha affrontato contemporaneamente ambedue i problemi su menzionati
- La seconda trasformazione IP -> MAC si chiama address resolution: Il meccanismo che mappa gli indirizzi IP a indirizzi di livello più basso (scheda di rete) si chiama ARP. Esso non si confina solo in ambito Ethernet o Token Ring, ma si usa anche su alti tipi di rete, come l' amateur radio AX.25 protocol. ARP si comporta come una persona che vuole trovare un altra dentro una sala affollata. Ossia chiama a voce alta in modo che tutti possano sentirlo "chi è il tizio che ha nome X?" aspettando che qualcuno eventualmente gli risponda. Quando ottiene la risposta sa a quale persona corrisponde il nome X. Quando ARP vuole trovare l' indirizzo Ethernet (MAC address) che corrisponde ad un dato indirizzo IP, usa una caratteristica di Ethernet chiamata broadcasting, in cui un datagram è indirizzato a tutti gli host della rete simultaneamente. Il broadcast datagram emmesso dal richiedente (ARP request) contiene una domanda (quale è il tuo MAC?) per l' indirizzo IP. Ogni host che lo riceve compara l' IP contenuto nel broadcast datagram col proprio e se coincide, emmette una ARP reply verso il host richiedente includendo il proprio indirizzo MAC. Adesso il host richiedente può estrarre dalla reply l' Ethernet address(MAC) del replicante ottenendo cosi oltre al IP che gia aveva, anche il MAC address del replicante. Se invece non esiste alcun replicante alla ARP request (vuol dire che il host ricercato sta al di fuori della portata del broadcasting ossia fuori dalla LAN) si usa un mecanismo diverso che si chiama routing. Una volta che un host richiedente ha trovato un Ethernet address(MAC), lo memorizza nella sua ARP cache in modo da non doverlo richiedere di nuovo la prossima volta che desidera mandare un datagram verso il host replicante. Comunque è sconveniente mantenere questa cache per sempre (come d' altronde per ogni cache); Per esempio se il host replicante cambia la sua Ethernet card per un malfunzionamento l' ARP entry diventa non più valida. Per cui le entries nella ARP cache dopo un po di tempo vengono scartate e vien forzata una nuova ARP request.
Talvolta serve l' operazione inversa ossia un host neccesita conoscere il suo indirizzo IP assocciato col suo indirizzo MAC. Un esempio comune nelle LAN è il caso di un host diskless (senza diso fisso contenente l' OS) che deve fare il boot (da un boot server di rete).
Il client diskless non ha nessuna informazione circa se stesso --eccetto il suo MAC address dentro il firmware della sua NIC. Quindi emette in broadcast un messaggio di richiesta verso il boot server affinchè quest' ultimo gli fornisca un IP address. Questo protocollo chiamato Reverse Address Resolution Protocol (RARP) insieme al protocollo BOOTP serve per definire la procedura per fare il bootstrapping di clients diskless sulla rete.
Come si fa la mappatura indirizzo - hostname è molto variabile e dipende dal particolare transport protocol che usiamo. Vediamolo brevemente:
NetBEUI
Tale protocollo risolve i nomi in questo modo:
Il Servizio di risoluzione nomi e di routing nel protocollo IP
- Manda un messaggio broadcast (verso tutti i host collegati alla rete LAN) dicendo: "Chi si chiama tizio per favore mi mandi un messaggio di risposta riportando il suo indirizzo MAC " Niente male tutto funziona automaticamente (senza necessità di alcun settaggio da parte nostra su alcun file di configurazione) finché il tizio fa parte della stessa LAN fisica.
- Ma se invece di una grande LAN ci fossero due LAN più piccole separate da un collegamento WAN (p.e. Internet ) cosa succederebbe? NetBEUI manderebbe un messaggio broadcast attraverso la WAN. Poi il link WAN farebbe in modo di consegnare il broadcast ad ogni LAN connessa alla WAN e ricorsivamente cosi via fino ad arrivare ad ogni host connesso ad Internet. Ora tenendo conto che una WAN e' lentissima se paragonata ad una Gbit-Mbit LAN ethernet e che il numero degli host (che possono fare broadcast) e la frequenza del broadcast (da ogni host) sono entità relativamente elevate non ci vuole molto per capire che in poco tempo la WAN si saturerebbe con i soli messaggi broadcast (e non con messaggi utili a noi come normalmente magari dovrebbe essere). Quindi NetBEUI non funziona sulle WAN ed è la ragione per cui la sua inventrice Microsoft l' ha abbandonato non appena è apparso Windows XP(fine 2001).
Il Servizio di risoluzione nomi e di routing nel protocollo IP
L' Internet Protocol (IP) è molto più sofisticato di NetBEUI nel risolvere i nomi degli host. L' IP utilizza il Directory service. Dal punto di vista dell' utente finale IP fa lo stesso che faceva NetBEUI. Internamente però cambia tutto:
- Un host comunica con una particolare macchina che è il DNS server (da il nome di un host con cui vuole connettersi richiedendo il suo IP )
- Il DNS server gli ritorna un numero (IP) che rappresenta l'indirizzo a livello globale (numero unico al mondo) in quel istante di quel host.
Routing IP
Tutti i router del mondo capiscono cosa vuol dire un indirizzo IP (79.55.163.229) in modo da mandare i pacchetti (i nostri o altrui --in caso di instradamento--) verso la giusta direzione.
Per esempio consideriamo il caso in cui: Il nostro host deve ricevere una PDU (Packet Data Unit) dall' indirizzo IP di sopra. Il primo router in cui transita la PDU non deve avere la conoscenza globale (di tutti gli indirizzi IP del mondo) ma deve solo sapere verso dove mandare dati per tutti gli indirizzi che cominciano con 79. Una volta che il pacchetto è arrivato al secondo router, il router responsabile degli indirizzi che cominciano con 79 manda il pacchetto verso il terzo router responsabile a gestire tutti gli indirizzi che cominciano con 79.55 il quale a sua volta lo manda vero il router responsabile per tutti gli indirizzi che cominciano con 79.55.163 che è il nostro router locale dentro la nostra LAN il quale sa dove si trova l' indirizzo del nostro host (che e' la parte .229 di 79.55.163.229). Una volta arrivato il pacchetto al router di casa nostra lui si incarica di recapitarlo al host della nostra LAN che ha richiesto questo pacchetto dati chiudendo cosi il viaggio di tale pacchetto.
Se invece è il nostro host a mandare dati verso un indirizzo IP si potrebbero presentare 2 casi :
- Lui prima verifica se l' indirizzo IP destinazione del pacchetto sta nella nostra LAN (lo fa attraverso il subnet number della subnet mask: Ogni host in una LAN IP deve avere lo stesso subnet number. Quindi se il subnet number del host mittente coincide con il subnet number del host destinazione quest' ultimo host fa parte della stessa LAN del host mittente) . Se è vero questo il nostro host manda un pacchetto broadcast (in slang si dice ARPa -- dal nome del protocollo che usa--) nella LAN dicendo "Il host con IP destinazione prego mi mandi il suo indirizzo fisico MAC (indirizzo della NIC card --scheda-adattatore di rete--). Con il MAC del host destinazione il nostro computer ha tutta l' informazione necessaria per mandarli quello che vuole.
- Quando invece l' indirizzo IP destinazione del pacchetto non sta dentro la LAN (apparterrà ad una altra LAN che dista dalla nostra almeno una rete intermedia quindi siamo in ambito WAN) il nostro host manda (forward) il pacchetto verso il nostro router il quale fa a sua volta forward verso i suoi omologhi nella WAN (Internet) e come abbiamo visto poc'anzi il pacchetto arriva al host con IP destinazione dopo un gran palleggio. Una volta trovata la destinazione Il router della LAN destinazione finalmente ARPa pure lui per trovare il host a cui è destinato il pacchetto.
Prima del DHCP gli indirizzi si immettevano manualmente per ogni host. Vi lascio immaginare il malessere che portava l' admin di rete quando doveva fare anche una piccola modifica e doveva amministrare reti con qualche centinaio di host. Era facilissimo che niente più funzionasse un istante dopo. Per ovviare a ciò l' Internet community sviluppò il protocollo BootP
Microsoft è partita da un protocollo Internet appunto BootP lo ha evoluto e l'ha chiamato DHCP. Attualmente lo usa sui suoi OS della serie di Windows 2K Server e l' ormai vetusto Windows NT server oltre che su ICS (Internet Connection Sharing) service. Oltre a Windows (Linux etc) DHCP viene usato ovunque dai dispositivi di condivisione di connessione a Internet ai router ecc..
Nota: I due numeri magici 192.168.1.1 e 255.255.255.0 prendono rispettivamente il nome di IP number e netmask number (maschera di rete). La netmask a sua volta si suddivide ulteriormente in 2 parti:
- la prima parte della netmask 255.255.255 (che si chiama subnet number) e mi identifica l' indirizzo della rete 192.168.1
- la seconda parte della netmask .0 (cioè il quarto numero dei 4 numeri decimali separati dal punto) che si chiama node number e mi identifica l' indirizzo del particolare host nella rete (in questo esempio il nodo numerato .1)
A differenza dell' indirizzo MAC (che --teoricamente-- è unico al mondo) che viene immesso dal costruttore nel firmware della NIC (dispositivo/scheda di rete) in modo definitivo e vale da quando compriamo il dispositivo fino a quando lo buttiamo, l' indirizzo IP (anch' esso dovrà essere unico necessariamente per identificarci univocamente finché siamo in qualche rete --LAN, Internet, altro--) invece ha bisogno di settaggio software. Noi non possiamo settarlo per come ci pare e piace dobbiamo sottostare a delle regole. In una LAN queste sono:
- tutti i host nella LAN debbono avere la stessa network mask e in particolare lo stesso subnet number.
- Ogni host deve avere un distinto node number.
- Inoltre il nostro host deve conoscere l' indirizzo del suo local gateway (router) e gli indirizzi dei name resolving servers (DNS)
Se la LAN non è connessa a Internet possiamo benissimo assegnare agli host indirizzi IP a nostro piacimento. Esistono parecchi intervalli di indirizzi riservati per le reti private (per convenzione non utilizzati/riconosciuti per uso pubblico). Invece per i siti in Internet gli indirizzi IP sono assegnati da un entità globale chiamata Network Information Center(NIC)
Vediamo come funziona il DHCP:
Vediamo come funziona il DHCP:
- Quando un host nella LAN fa il boot esso manda attraverso broadcast una richiesta (per sapere quale indirizzo IP gli spetta) ad un server DHCP che può essere eseguito in un host della rete o in un router (qui assumo che nella nostra LAN il server DHCP sia nel router come nella stragrande maggioranza dei casi almeno nelle SOHO LAN) o anche in altri dispositivi connessi alla rete.
- Il server DHCP che riceve il broadcast risponde (reply) al host richiedente (ogni host collegato alla rete quando l' accendiamo) con un pacchetto che contiene l' indirizzo IP, la subnet mask, ed altre info utili per lui. Una delle regole che seguono tutti i routers del mondo è di non lasciar passare verso l'esterno i pacchetti broadcast che viaggiano in una LAN se no avverrebbe il chaos totale. Quindi e' solo il nostro server DHCP (e non qualche altro esterno alla nostra rete) nel nostro router che ci da tutte queste info.
- Ora il server DHCP per evitare di assegnare lo stesso indirizzo IP a due host distinti nella stessa LAN tiene conto di quale indirizzo IP ha assegnato-associato a quale MAC . La coppia (IP, MAC) identifica univocamente un host nella LAN). Inoltre e responsabile del riciclo degli indirizzi quando p.e. un host nella rete viene spento (e non utilizza più quel indirizzo) o/e un host collegato alla rete viene acceso. Per gestire questa situazione escogita il cosiddetto address leasing. Lease e' il limite di tempo che un host può usare l' IP assegnatogli. Un po prima della scadenza di tale tempo è il host a contattare il DHCP server richiedendo di rinnovare il suo lease o richiedendo di ottenere un altro indirizzo IP. Tutto ciò e' trasparente a noi e si fa automaticamente.
Curiosita: Ora si capisce una --perché ci stanno anche altre come p.e. Il problema delle collisioni dei pacchetti-- delle ragioni per cui una rete Ethernet (ma in linea di principio vale per ogni architettura di rete) da 10/100/1000 Mbps non potrà mai avere un troughput nominale(Risp: Anche la sua gestione vuole parte di questi Mbps)
- Se Windows viene settato per una configurazione automatica degli IP (spunta in ottieni automaticamente l' indirizzo IP e DNS nelle proprietà di TCP/IP) e il DHCP server non risponde alla sue richieste (perché non esiste, o per qualche ragione è down o malfunziona) entro mezzo minuto o giù di li, Windows stesso si auto-assegna un indirizzo IP (nota che ciò non ha niente a che fare col DHCP) preso dal range 169.254.0.0 - 169.254.255.255 (come qualcuno di noi purtroppo sa già). A differenza del DHCP APIPA oltre al IP non assegna network gateways, domain names, o informazioni sui DNS servers. Tutte queste informazioni ogni host le ottiene in un secondo momento una volta che va in Internet. APIPA è come dire meglio di niente. E' stato fatto tenendo in mente una rete LAN (che più elementare non si può) serverless e senza connessione permanente in Internet
- Dopo di che Windows continua a guardare se arriva un' eventuale risposta dal DHCP server ogni 3 minuti. Nel caso arrivi questa benedetta risposta reietta la sua auto-configurazione precedente e si configura con DHCP. Tutto questo modo di fare fa tardare tanto la fase di avvio del host oltre al fatto che dopo avrà il sovraccarico di ispezionare per l' eventuale risposta del DHCP ogni 3 min.
Per eliminare tutto questo fardello conviene assegnare a mano gli IP (nella schermata di su clik su imposta IP manualmente (IP statico) anziché lasciare a Windows farlo automaticamente ed eventualmente poi clik su avanzate per settare i server DNS (p.e. OpenDNS) anche se basterebbe che mettessimo l'indirizzo del gateway (router) (perché in lui saranno già stati settati i DNS servers del nostro ISP) per ogni host Windows
Nota1: molta gente con il portatile (adesso i vari netbook) si muove fra reti settate con DHCP e con IP statico. A differenza della serie Windows 9x in cui per ogni tipo di rete dovevi riconfigurare manualmente il tutto, da XP in poi c'è la "Alternate Configuration" che ti permette di settare un IP statico quando il DHCP non è presente. Quando invece entri in una rete con DHCP (p.e. in ufficio al lavoro) la configurazione con IP statico si fa da parte e funziona solo il dinamico. Tutto ciò' in modo trasparente (una volta settato all' inizio)
Nota2: Sia IPv4 che IPv6 hanno dei metodi standard per la configurazione automatica di indirizzi dell' interfaccia di rete (address autoconfiguration). IPv4 usa il set di indirizzi 169.254.0.0/16 (link-local) definiti in RFC 3927. Per IPv6, guarda RFC 4862.
La tecnica fu chiamata Link-Local address assignment in RFC 3927. Malgrado ciò, Microsoft la chiama Automatic Private IP Addressing (APIPA) o Internet Protocol Automatic Configuration (IPAC).
Il Windows Internet Naming Service fu introdotto con Windows NT il primo OS di Microsoft che permise il Microsoft File Sharing di operare sul protocollo TCP/IP. L' utenza Windows lo utilizza per identificare i host attraverso nomi fatti di una sola parola (harrykar manuel ecc. ). Le reti che lo usano possono contenere host che usano indifferentemente i protocolli NetBIOS , IPX/SPX, TCP/IP . E' stato sviluppato come un sistema integrato di risoluzione nomi. Il server WINS impara tutti i nomi dei host connessi a ogni rete connessa con esso stesso e poi dispone tali nomi sui host che utilizzano il protocollo TCP/IP.
Quando un nuovo host si connette alla rete il host dapprima si registra col server WINS dopo di che si può identificare verso tutti gli altri host della rete col suo nome (a parola unica) anziché col suo indirizzo IP. Il suo punto forte rispetto a NetBEUI è che a differenza di quest' ultimo WINS comunica con la WAN esterna. Funziona in questo modo:
Quando un nuovo host si connette alla rete il host dapprima si registra col server WINS dopo di che si può identificare verso tutti gli altri host della rete col suo nome (a parola unica) anziché col suo indirizzo IP. Il suo punto forte rispetto a NetBEUI è che a differenza di quest' ultimo WINS comunica con la WAN esterna. Funziona in questo modo:
Il server WINS (come solitamente succede su grandi reti) può essere esterno alla nostra LAN e in questo caso dobbiamo dire al nostro host harrykar dove sta il server WINS in esame. In tal modo un host che usa TCP/IP + WINS può trovare qualsiasi altro host su qualsiasi WAN senza bisogno di fare broadcasting. Quindi WINS + TCP/IP fanno possibile il file sharing fra reti LAN Microsoft divise da una WAN (ricordiamoci il bridging dei pachetti che faceva NetBEUI su un link WAN)
DNS
- www.blogger.com/home > 67.215.65.1 (operazione chiamata risoluzione nomi)
- 67.215.65.1 > www.blogger.com/home (operazione chiamata Inverse DNS)
- cerca prima su WINS e solo se WINS non risponde
- entra in scena il DNS per risolvere il nome. Se anche il DNS fallisce allora
- Windows fa una richiesta broadcast sulla LAN
Se e solo se uno di questi 3 metodi ha successo Windows va avanti ad usare il Microsoft File Sharing per connettersi al server.lavoro.com
Nel '84 IBM ha concepito un API rudimentale per fare il networking dei suoi computer chiamata Network Basic Input/Output System (NetBIOS) che permetteva ad un applicazione in un host di connetteresi e condividere dati con altri host. Il BIOS nel nome suggerisce di considerare NetBIOS come un' estensione per il networking delle chiamate alla standard API BIOS del PC.
Originariamente lavorava su reti Token Ring (una proposta IBM dei contendenti al trono per la LAN di allora che oggi sappiamo essere posseduto dall' Ethernet) e abbisognava un protocollo di trasporto low-level per portare le richieste da un computer a un altro.
Nel '85 IBM ha rilasciato un ulteriore protocollo che ha aggiunto al NetBIOS chiamato NetBEUI (NetBIOS Extended User Interface). NetBEUI è stato progettato per piccole LAN (fino a 255 nodi che nel '85 era un numero di tutto rispetto) e permetteva ad ogni host di avere un nome (fino a 15 caratteri) unico nella rete.
Il protocollo NetBEUI ha inizialmente spopolato nelle applicazioni networking con Windows for Workgroups e successivamente con i protocolli networking IPX di Novell dopo averli implementati su NetBIOS. Ma dato che già allora il TCP(UDP)/IP era uno standard de-facto non è passato molto affinche si implementasse l' API NetBIOS su TCP/IP.
Mentre il TCP(UDP)/IP usava numeri come 192.168.1.6 per rappresentare indirizzi il NetBIOS usava invece solo nomi. Questo fu il problema principale nella fusione dei 2 protocolli. Nel 1987, IETF ha pubblicato i documenti di standardizzazione, RFC 1001 e 1002, che descrivevano come NetBIOS avrebbe dovuto lavorare su una rete TCP/UDP. Queste RFC governano ogni implementazione esistente sinora, incluse quelle fornite da Microsoft con i suoi OS Windows, e altresì con la suite Samba. Da allora lo standard prese il nome NetBIOS over TCP/IP (NBT). Nella letteratura Microsoft lo troviamo invece spesso come NetBT.
Lo standard NBT (RFC 1001/1002) correntemente fornisce tre servizi su una rete:
Originariamente lavorava su reti Token Ring (una proposta IBM dei contendenti al trono per la LAN di allora che oggi sappiamo essere posseduto dall' Ethernet) e abbisognava un protocollo di trasporto low-level per portare le richieste da un computer a un altro.
Nel '85 IBM ha rilasciato un ulteriore protocollo che ha aggiunto al NetBIOS chiamato NetBEUI (NetBIOS Extended User Interface). NetBEUI è stato progettato per piccole LAN (fino a 255 nodi che nel '85 era un numero di tutto rispetto) e permetteva ad ogni host di avere un nome (fino a 15 caratteri) unico nella rete.
Il protocollo NetBEUI ha inizialmente spopolato nelle applicazioni networking con Windows for Workgroups e successivamente con i protocolli networking IPX di Novell dopo averli implementati su NetBIOS. Ma dato che già allora il TCP(UDP)/IP era uno standard de-facto non è passato molto affinche si implementasse l' API NetBIOS su TCP/IP.
Mentre il TCP(UDP)/IP usava numeri come 192.168.1.6 per rappresentare indirizzi il NetBIOS usava invece solo nomi. Questo fu il problema principale nella fusione dei 2 protocolli. Nel 1987, IETF ha pubblicato i documenti di standardizzazione, RFC 1001 e 1002, che descrivevano come NetBIOS avrebbe dovuto lavorare su una rete TCP/UDP. Queste RFC governano ogni implementazione esistente sinora, incluse quelle fornite da Microsoft con i suoi OS Windows, e altresì con la suite Samba. Da allora lo standard prese il nome NetBIOS over TCP/IP (NBT). Nella letteratura Microsoft lo troviamo invece spesso come NetBT.
Lo standard NBT (RFC 1001/1002) correntemente fornisce tre servizi su una rete:
- ¹Un servizio nomi (NetBIOS Naming Service NBNS)
- ²Due servizi di communicazione:
- Datagrammi
- Sessioni
¹ Risolve il problema nome - indirizzo numerico fra NetBIOS e TCP/IP su descritto permettendo la traduzione di un nome unico nella rete ad un indirizzo IP un po come fa oggi Domain Name System (DNS) su Internet. Il WINS Service è semplcemente un' implementazione di NBNS
² Questi servizi sono ambedue protocolli di communicazione secondari che si usano per veicolare dati fra i computer NetBIOS sulla rete.
² Questi servizi sono ambedue protocolli di communicazione secondari che si usano per veicolare dati fra i computer NetBIOS sulla rete.
Come ti chiami?
Nella terminologia NetBIOS il processo, quando un host va on e reclama per il suo nome, si dice name registration. Abbiamo detto che ogni client nello stesso workgroup deve avere un nome distinto. Esistono due differenti approcci per assicurare l' unicità del nome:
- Usare un NBNS per tener traccia degli host che hanno registrato un nome NetBIOS. In questo caso ogni client che fa il boot consulta il NBNS per sapere se c'è qualcuno che e' registrato col suo nome NetBIOS, e l' NBNS gli da la risposta. Questo modo di fare è certamente il più efficiente del secondo. perchè le parti comunicanti sono solo il client richiedente e lo stesso NBNS in una comunicazione point-to-point in antitesi col broadcast. Immaginiamo p.e. il caso di una rete con più di una subnet (sottorete) e considerando anche il caso in cui si usano dei routers che come noto vengono settati per bloccare i pacchetti broadcast in input verso tutti i computer della sottorete
- Permettere a ogni host di diffendere il suo nome nell' eventualità che un altro host tenta di usarlo. In questo caso ogni client che va on fa un broadcast nella rete per assicurarsi di non usare un nome NetBIOS già esistente. Nel qualcaso:
- nessuno obietta sul uso del nome il client tiene il suo nome
il nome sia già in uso gli risponde il host che già ce l'ha (si dice che fa difesa del proprio hostname). Questo modo di fare è :
- positivo quando un client si spegne perchè allora un altro può benissimo riutilizzare quel nome senza incontrare contestazioni negativo per l' overload (intasamento) di rete dovuto al broadcasting (chiamato anche "flooding") per una questione banale come è il processo della registrazione di un nome (name-resolution request o "Name Query" packet) che avviene per ogni nome.
Considerazione di buon senso: E' ovvio che il 'packet flooding' che impegna una rete in stato broadcast non diventa un problema con qualche decina di client con CPU odierne in una LAN Gigabit ma con qualche centinaio (e in previsione di crescita) lo potrebbe benissimo diventare. Comunque niente toglie che è sempre buona regola su reti di dimensione medio-grande di evitare il broadcasting per quanto è possibile
Che tipo di nodo sei?
Che tipo di nodo sei?
La strategia che adotta ogni nodo della rete NBT per il name registration e resolution lo fa categorizzare in:
- b-node: usa solo broadcast per la registrazione e risoluzione di nome
- p-node: usa esclusivamente comunicazioni point-to-point per la registrazione e risoluzione di nome
- m-node: usa dapprima il broadcast per la registrazione che se avvenuta con successo notifica il risultato al NBNS. Se la strategia broadcast invece falisce allora usa NBNS
- h-node: usa dapprima NBNS. Se esso falisce (perchè p.e. NBNS non risponde o non è operativo) usa il broadcast
Nota: I clients Windows si trovano di solito come h-nodes (hybrid-nodes) perchè probabilmente la tipologia 4. fu inventata da Microsoft come miglior metodo fault-tolerant mentre i primi 3 tipi di nodi esistevano già nelle RFC 1001/1002
La tipologia del nodo si può trovare :
- In Windows 95/98/Me dando: winipcfg e cliccando More Info>>
- In Windows XP dando: ipconfig /all e guardando la linea Node Type(tipo nodo)
Lo spazio nomi del NetBIOS e' flat (in antitesi con la struttura gerarchica del DNS p.e. www.samba.org ha 3 livelli sottesi).
Nota: E' sconsigliato l' uso del "." che potrebbe essere non supportato su versioni future di NBT(probabilmente sulla v3.x di Samba )
Tutti i nomi DNS validi sono anche nomi validi per il NetBIOS e questo non e' un caso. Il server Samba può usare un nome DNS non qualificato come nome NetBIOS p.e. roba.varia.com viene usato da Samba come ROBA_ _ _ _ _ _ _ _ _ _ _ (ove ogni _ rappresenta uno spazio in modo che tutto il nome consti di 15 caratteri)
Tipi di risorse
Tipi di risorse
Con NetBIOS ogni host non solo avverte della sua presenza agli altri ma li informa anche che tipo di servizi esso offre. Questo viene fatto aggiungendo un 16esimo byte nel nome chiamato resource type e ha il compito di registrare il nome più volte una per ogni servizio che esso offre. Quindi il resource type da 1-byte (16esimo ) indica un unico servizio che il host con nome offre.
Noi possiamo vedere da Windows quali nomi sono registrati con un particolare NBT host usando l' utility nbtstat:
C:\>nbtstat -a
Tipi Standard di risorse uniche NetBIOS
Named resource----------------------Valore hex 16imo-byte
Workstation Service------------------------------------ 00
Messenger Service--------------------------------------- 03
RAS Server Service------------------------------------- 06
Domain Master Browser Service
Named resource----------------------Valore hex 16imo-byte
Workstation Service------------------------------------ 00
Messenger Service--------------------------------------- 03
RAS Server Service------------------------------------- 06
Domain Master Browser Service
(associated with primary domain
controller)------------------------------------------------1B
Master Browser name---------------------------------1D
NetDDE Service-----------------------------------------1F
Fileserver(including printerserver)-----------------20
RAS Client Service----------------------------------------21
Network Monitor Agent------------------------------ BE
Network Monitor Utility------------------------------ BF
Un dominio sarà quindi un insieme non vuoto di host (clients) controllato da un insieme non vuoto di domain servers (servers di dominio). Quando la nostra macchina fa parte di un dominio e facciamo il login veniamo identificati dal server e siamo automaticamente riconosciuti da tutti i host (Windows XP, 2000, e NT computers ) del intero dominio.
Attenzione permessi per vedere/accedere i file dello share vengono ancora gestiti individualmente da ogni host come in una rete P2P. Il solo punto forte qui è che centralizziamo (attraverso un database utenti comune a tutti i host del dominio) la nostra autenticazione. La localizzazione delle risorse è identica con la tipologia P2P.
controller)------------------------------------------------1B
Master Browser name---------------------------------1D
NetDDE Service-----------------------------------------1F
Fileserver(including printerserver)-----------------20
RAS Client Service----------------------------------------21
Network Monitor Agent------------------------------ BE
Network Monitor Utility------------------------------ BF
NetBIOS unique resource types----------------- Standard
I 4 modi di networking in Windows
Peer-to-Peer (o workgroup) Network
Questo tipo di rete va bene fino a una-due decine di hosts quindi per una elementare home/office LAN. Come dice la parola P2P non c'è un' architettura tradizionale client-server (p.e. un server centrale e tanti client) ma tanti host (win, *nix) ognuno dei quali indifferentemente può fare sia da client che da server. Un po come succede p.e. con un client bittorrent
In una rete tipo P2P ogni host deve avere il proprio database dei nomi utente/pass perchè semplicemente non esiste un controllore centralizzato dei privilegi delle risorse condivise. In questo modo se la rete e' già di media dimensione è facilissimo che ci siano difficoltà di accesso allo share basta dimenticare di fare un account (per il client) sul host (server) che fa lo share.
In una rete tipo P2P ogni host deve avere il proprio database dei nomi utente/pass perchè semplicemente non esiste un controllore centralizzato dei privilegi delle risorse condivise. In questo modo se la rete e' già di media dimensione è facilissimo che ci siano difficoltà di accesso allo share basta dimenticare di fare un account (per il client) sul host (server) che fa lo share.
Microsoft per semplificare la situazione per gli utenti di home lan ha inventato il Simple File Sharing in questo modo se share deve essere per un host che sia share per tutti i hosts collegati alla rete senza incasinarsi con i nomi/pass ed altre difficoltà non banali per un utente comune. Il Simple File Sharing e' per default abilitato in XP home mentre in XP Professional e' giustamente solo opzionale a causa dei problemi sulle questioni di sicurezza che esso pone.
L' amministrazione di una rete Windows P2P si fa individualmente su ogni host. Ognuno di tali host (dopo l' installazione di Windows) avrà almeno un account con privilegi "Administrator" che amministrerà gli utenti locali in quel host. Quindi il network manager della rete deve conoscere tutte le passwords degli Administrators.
Per trovare le risorse condivise in una rete P2P:
Per trovare le risorse condivise in una rete P2P:
- o si deve sapere il nome del host che condivide una risorsa che ci interessa oppure
- usare il browser di rete My Network Places (o Network Neighborhood in precedenti versioni di Windows).
Questo tipo di localizzazione può andare bene su piccole reti di una dozzina di host ma già su reti piu' grandi diventa molto inefficace.
Quando la rete viene gestita da un server Windows 2K/NT (o Samba server) mentre gli altri host (p.e.con XP, *nix) fanno da client abbiamo un' architettura di rete Client-Server chiamata Domain Network. A differenza della rete P2P adesso l' identificazione di ogni utente/pass viene demandata da parte di ogni host (XP, *nix) al Win 2k/Samba server e questa centralizzazione e' un aspetto positivo dal punto di vista di un netadmin.
Un dominio sarà quindi un insieme non vuoto di host (clients) controllato da un insieme non vuoto di domain servers (servers di dominio). Quando la nostra macchina fa parte di un dominio e facciamo il login veniamo identificati dal server e siamo automaticamente riconosciuti da tutti i host (Windows XP, 2000, e NT computers ) del intero dominio.
Attenzione permessi per vedere/accedere i file dello share vengono ancora gestiti individualmente da ogni host come in una rete P2P. Il solo punto forte qui è che centralizziamo (attraverso un database utenti comune a tutti i host del dominio) la nostra autenticazione. La localizzazione delle risorse è identica con la tipologia P2P.
Qui subentra un nuovo figuro il domain administrator che decide chi può e chi non può avere accesso al dominio sfruttando anche i sistemi di Windows profile e Windows policy che portano ai seguenti effetti visibili a occhio nudo:
- L' utente può usare un host qualsiasi del dominio avendo sempre il suo stesso desktop, Control Panel, Miei Documenti e software settings ecc. perchè tutti questi dati stanno su un server centrale anziché su ogni host. Inoltre il network manager viene facilitato sui backup dei dati degli utenti nel sfortunato caso di un crash hardware.
- L'amministratore di dominio può tagliare fortemente sui costi (per l' azienda) di manutenzione e supporto non permettendo (a base individuale) agli utenti di cambiare settaggi sulla rete, sullo schermo sul hw levando dalla loro vista le corrispettive voci dal Panello di controllo
L' Active Directory è un database distribuito. Contiene oltre che i nomi e le locazioni dei host e stampanti, usernames, passwords, appartenenza al groupo, privilegi ed altre info di sicurezza, anche le cosiddette Group Policies (limitazioni di controllo).
Gli sviluppatori invece usano Active Directory per immetere info arbitrarie riguardanti le applicazioni software (tipo locazione e nome del più vicino database server ecc.)
Comuque l' aspetto più importante di AD è la sua struttura gerarchica (la sua unità di categorizzazione si chiama container ) che si può usare (dal network manager) per riflettere la struttura reale di un organizzazione sparsa nel mondo.
Attraverso i containers il network manager può assegnare privilegi basandosi sulla struttura reale dell' organizzazione anzichè perdersi con un assegnazione individuale utente per utente e per tutti gli utenti. Un gran bel passo avanti quindi nella gestione di grandi reti.
Partendo da Domain network e aggiungendo la feature Active Directory i network administrators possono fare oltre a ciò che abbiamo menzionato su anche la delega delle responsabilità di gestione verso livelli più bassi nella catena di controllo e con ogni livello di dettaglio che loro ritengono soddisfacente. Questo si usa su grandissime compagnie tipo Enel, Ansaldo, Eni ecc in cui si può fare una gestione di privilegi compartimentalizzata.
Se siamo in una rete Active Directory l' unica cosa che dobbiamo conoscere è il recapito (tel, mail ecc) dell' amministratore di rete. Noi come utenti di rete non abbiamo alcun potere di personalizzazione. Consumiamo semplicemente ciò che ci danno. In questo caso però la localizzazione delle risorse è molto più sofisticata (facile, unificata) dei due casi precedenti. E' un po come usare Google in Internet
Active Directory è basata sul Lightweight Directory Access Protocol (LDAP), uno standard Internet per interrogare ed ottenere risposte da database gerarchici e su Active Directory Services Interface (ADSI) ; p.e. un programma email può essere progettato per usare LDAP per trovare indirizzi email indipendentemente dal sottostante network system (che può essere Windows, Novell NetWare, or altri sistemi networking)
Windows 2K Server gira un LDAP server su ogni host della rete Active Directory. Variazioni Amministrative alla directory possono occorrere su ogni membro server, Questi cambiamenti poi vengono replicati automaticamente su tutti gli altri server. Solitamente la locazione del più vicino Active Directory server si trova usando il DNS system.
Ciò fa si che un host possa unirsi in un network Active Directory e trovare il suo posto nel mondo senza alcuna configurazione manuale:
- Il DHCP da al computer il suo IP address e l 'indirizzo dei DNS servers
- il DNS a sua volta localizza l' Active Directory, e
- Active Directory a sua volta fornisce il resto di informazione di cui abbisogna il computer per espletare il suo lavoro.
Il Windows Offline/Remote Network
Questo è molto simile ai sist CVS, SVN ecc. Cos' è l' "offline" file? Windows ci permette di marcare files o cartelle per un uso offline e copia essi dal network al nosrto disco rigido. Quando ci disconnettiamo dalla rete noi abbiamo accesso a questa copia, anche se essa ancora ci appare come se appartenesse al computer da cui li abbiamo copiati.
Quando ci riconnettiamo nella rete, Windows automaticamente sincronizza gli offline files con i loro omologhi che stanno sulla rete, copiando ogni modifica noi avessimo fatto indietro alla rete e ricevendo dalla rete nel nostro hard disk ogni file updatato da altri.
Gli Offline files sono simili alla funzione My Briefcase offerta da Windows 9x col vantaggio però che gli offline files, appaiono di stare nelle loro locazioni originali. Windows trasparentemente gestisce le copie offline, noi non dobbiamo disturbarci di fare il dragging di files verso e dalla cartella briefcase.
Servizi di rete (di interesse qui) per il Windows XP ---implementazione
Condivisione di File e Stampante
Il software per il networking è stato originariamente sviluppato per condividere e trasferire files fra computers. Windows XP per default contiene:
- Il client per Microsoft Networks, il quale permette l 'accesso a files e stampanti condivisi che altri (Windows ,OS/2, *nixes ecc.) computers mettono in share.
- File and Printer Sharing for Microsoft Networks, permette a Windows XP Professional di condividere files e stampanti con utenti che utilizzano lo stesso OS o Os compatibili col sharing su protocollo SMB. Windows XP Pro è limitato a 10 simultanee connessioni da parte di altri computers. In altre parole se ho 11 host devo utilizzare la versione Server 2K;
- Web Sharing, fornisce in sicurezza la copia di file verso|da cartelle condivise attraverso Internet, usando l' Hypertext Transfer Protocol del Web. Esso usa tutta la Windows security e la gui Windows Explorer, mentre la tecnologia sottostante è basata sul World Wide Web e sul Internet Information Server (IIS).
- Il client for Novell Networks, fa accedere a files e stampanti in share dai file servers Novell NetWare .
- Print Services for UNIX, permette di usare e condividere stampanti con host usando il protocollo LPR del OS *nix
Nota: Solo Windows 2K Server (ma non XP Pro) ha i tools per condividere o usare files su computers Apple Macintosh.
Configurare una Rete Peer-to-Peer in Windows XP
- configurare la rete manualmente
- configurare la rete tramite wizard(chiamato Network Setup Wizard)
Configurare il protocollo TCP/IP
Nel assegnare un indirizzo IP ad ogni computer ci sono 3 strade possibili:
- Dobbiamo usare il servizio DHCP che può essere in esecuzione o sul router o su un host ICS (E' comunque raccomandabile usare il server DHCP su un router) se nella rete c' è: un host che usa ICS (Internet Connection Sharing) per condividere la sua connessione ad Internet con gli altri host della rete o un router (condiviso da tutti i host della LAN) a cui si connettono tutti i host della rete per andare in Internet (che è il caso più riscontrato) o abbiamo una corporate LAN che gira Windows 2K server
- Assegnare manualmente un indirizzo IP (in tal caso si chiama IP statico) ad ogni host della rete
- In ogni caso se non si applica ne 1. ne 2. Windows si auto-assegna un indirizzo IP (ma questo caso e' meglio evitarlo come si è detto nel & di APIPA , dato il sovraccarico/lentezza che comporta)
Procedura
Componenti opzionali di Windows networking
Per usare la network card, abbiamo bisogno di speciali funzioni nel kernel che conoscano tutti i particolari di accesso al dispositivo. Il software che implementa tali funzioni prende il nome di device driver. Linux ha device drivers per molti tipi di schede di interfaccia di rete : ISA, PCI, MCA, EISA, Parallel port, PCMCIA, USB. Il driver manda comandi e dati verso la scheda di rete, essa fornisce poi tutti i dati che riceve indietro al driver. Nel mondo dei PC IBM questa communicazione avviene attraverso un set di indirizzi I/O che sono mappati ai registri della scheda o a trasferimenti di memoria (direti o condivisi). Tutti i comandi e dati che manda il kernel verso la scheda vanno a tali indirizzi. Tali indirizzi (di I/O e memoria) in genere sono descritti fornendo l' indirizzo iniziale o base. Tipici indirizzi base per Ethernet cards su bus ISA sono 0x280 o 0x300. Invece le network cards per il bus PCI in genere hanno il loro indirizo I/O assegnato in automatico.
Normalmente il kernel a boot time tenta di rilevare la locazione della card attraverso l' auto-probing: Il kernel legge diverse locazioni di memoria e I/O e compara i dati letti con quello che aspetta di vedere se una certa network card fosse installata in quella locazione. Qualche volta non riesce a rilevare la card automaticamente o per mancanza di qualità della card (costruita non rispettando degli standard) o se abbiamo più di una network card per esempio per default rileva solo la prima e non le altre (in tal caso dobbiamo dire noi al kernel in modo esplicito circa le card non rilevate). L' Ethernet HOWTO riporta se un particolare driver utilizza l' auto-probing e in quale ordine cerca nello spazio di indirizzamento I/O per trovare l' hardware.
L'autoprobing ha 3 limitazioni:
Per esempio se vogliamo che Linux installi la seconda scheda di rete Ethernet in 0x300 come eth1, dobbiamo passare i seguenti parametri al kernel nel suo file di configurazione /etc/lilo.conf (per rendere le modifiche permanenti)
Premendo il tasto Tab al prompt, si ottiene una lista di kernels con cui si puo fare il boot. Dobbiamo immetere il kernel desiderato seguito da spazio e i parametri. Quando premiamo Enter(Invio), lilo caricherà il kernel e farà il boot con i parametri che abbiamo fornito) :
Possiamo usare i parametri del kernel per bypassare i risultati dell' autoprobing per eth0:
Possiamo disabilitare l' autoprobing( anche mettendo base_addr a -1) per una scheda Ethernet che abbiamo per esempio temporaneamene scollegata:
Nella maggioranza dei casi il driver rileverà la network card senza un ulteriore nostro intervento. Documentatione per tutti i tipi di schede generalmente si trova in /usr/src/linux/Documentation/networking/ dei sorgenti del Linux kernel.
come moduli (files) separati del kernel(modulare). In questo caso si possono passare dei parametri attraverso il file /etc/modules.conf(or /etc/modules). Linux caricherà i drivers automaticamente allorquando rivela un tentativo di inizializzare una interfaccia di rete. Se per qualsiasi ragione dovessimo fare questo processo manualmente dovremmo dare il commando insmod:
Assegnare indirizzi IP
Se configuriamo software di rete per uso standalone (ossia software che abbisogna usare networking per poter funzionare come eseguire solo il software INN Netnews per esempio) il solo indirizzo IP che abbisognamo è quello della loopback interface, che è sempre 127.0.0.1.
La cosa si complica quando vogliamo conneterci su una rete reale già esistente. Allora dobbiamo disporre un indirizzo IP (dal netadmin o assegnarlo noi stessi). Inoltre se abbiamo più reti fisiche o una rete suddivisa in più sottoreti (subnetting) dobbiamo assegnare loro indirizzi IP differenti.
Se vogliamo un network number pubblico possiamo richiedere una Network Address Application Form diretttamente da hostmaster@internic.net o dal corrispondente ente nazionale NIC(se esiste)
Se invece non vogliamo connettere la nostra LAN ad Internet possiamo scegliere qualsiasi indirizzo legale(pubblico) IP. L' unica nostra preoccupazione sarà di non lasciar passare i pacchetti della nostra LAN verso Internet. Per assicurarci di questo dobbiamo scegliere uno dei network numbers riservati per uso privato. Internet Assigned Numbers Authority (IANA) ha messo a disposizione diversi network numbers nelle classi A, B, e C (il secondo e terzo blocco contengono 16 e 256 networks, rispettivamente) che possiamo usare senza bisogno di registrazione (definiti da RFC 1597). Tali indirizzi sono validi solo dentro la nostra LAN privata e non si usano per l' instradamento dei pacchetti fra siti Internet reali. Gli indirizzi per uso privato consentono anche un accesso più ristretto verso la nostra LAN da Internet se usiamo un singolo host come gateway.
Il gateway sarà accessibile da parte della LAN attraverso il suo indirizzo IP interno, invece il mondo esterno lo conoscerà da un indirizzo IP esterno regolarmente registrato (da parte del nostro ISP).
Creare subnets
Per avere più Ethernets (o altri tipi di rete una volta che il loro driver è disponibile) dobbiamo suddividere la rete in sottoreti.
Il subnetting è richiesto solo quando abbiamo più di una rete broadcast--i point-to-point links sono ininfluenti. Per esempio, se si ha una Ethernet, e uno o più links SLIP verso il mondo esterno, non abbisogna suddividere la nostra rete.
Assumendo che il netadmin del network Brewery usa un network number di classe B come 172.16.0.0, per accomodare due Ethernets e decidendo di usare 8 bit della parte host number come bit per la subnet quindi dai 16 bit iniziali del host number rimangono 8 bit per le subnets(netmask) e altri 8 bits per la nuova parte host number , avendo cosi 2^8=254 hosts su ognuna delle due subnets.
Poi assegna un subnet number 1 per la subnet brewery, e 2 per la subnet winery. I rispettivi indirizzi di rete quindi saranno rispettivamente 172.16.1.0 e 172.16.2.0. La subnet mask è 255.255.255.0. Al vlager, il gateway fra i due networks, viene assegnato un host number 1 su entrambi le subnets, avendo quindi gli indirizzi IP 172.16.1.1 e 172.16.2.1, rispettivamente.
Tutto quanto detto sopra vale anche per una rete di classe C --dato che il subnetting non è limitato da byte boundaries--. Per esempio possiamo usare due ulteriori bits dalla parte host per la netmask, ottenendo 4 possibili subnets ognuna con 2^6=64 hosts (precisamente 62 hosts dato che il primo numero IP del range di ogni subnet rappresenta il suo subnetwork address e l' ultimo IP in ogni subnet è riservato al broadcast address).
Configurare un indirizzo IP statico(Static IP Address)
Tradizionalmente, i server hanno sempre usato l' assegnazione statica dell' indirizzo IP perchè esso assicura che l' indirizzo IP del server non può cambiare arbitrariamente. Questo è molto importante per il maping di hostnames su indirizzi IP (come mail.thiessen.it--> 172.23.45.67) via un DNS server.
Configurare le Interfacce di rete (Network Interfaces)
Dobbiamo far si che il sottosistema networking del kernel (NET-4) sia a conoscenza dei nostri dispositivi hardware di rete.
Per astrarre dalla diversità del equipaggiamento hardware che può essere usato nella rete, TCP/IP definisce una interfaccia astratta attraverso cui tale hardware possa essere acceduto. Tale interfaccia offre un set di operazioni che rimane lo stesso per tutti i tipi di hardware della stessa classe(Ethernet, PPP ecc) e fondamentalmente ha a che fare col emettere e e ricevere pacchetti.
Per ogni dispositivo periferico di rete la corrispondente interfaccia (contraddistinta da un nome) deve essere presente nel kernel. Per esempio:
Ci sono due modalità d'uso:
Le opzioni che servono per attivare una caratteristica sono le stesse per disattivarla precedendola con "-". Le sue opzioni più importanti sono:
Il NIC non assegna indirizzi host per host ma assegna un range (ricodriamoci che l' indirizzo IP si suddivide in un network number, contenuto negli otteti iniziali, ed un host number,che è la parte rimanente) e noi dobbiamo assegnare (a nostro piacimento) gli indirizzi IP validi contenuti in tale range ai host della nostra rete. La dimensione della parte host del network number dipende dalla dimensione della nostra rete. Per accomodare le esigenze più disparate e di conseguenza per poter suddividere in modo diverso gli indirizzi IP sono nate le classi di reti.
Class--Class Address Range--Private Address Range--Netmask
A---1.0.0.0–127.255.255.255---10.0.0.0–10.255.255.255----255.0.0.0
B-128.0.0.0–191.255.255.255--172.16.0.0–172.31.255.255--255.255.0.0
C-192.0.0.0–223.255.255.255--192.168.0.0-192.168.255.255--255.255.255.0
Inoltre ci sono anche le classi D per il multicast (traffico di pacchetti destinato a molti host che aspettano di riceverli, in contemporanea) e la classe E ed F riservata per usi futuri.
NB: Se in Windows abbiamo fatto le cose per come si deve (tipo come fa Linux di default) avremo (eventualmente) in ogni host un account Administrator e tanti accounts Power user. Qui ci servono i privileggi di Administrator. Un modo comodo (alla stregua di sudo) per guadagnarli (per non uscire dal nostro account per andare in quello del Administrator) e' dare da Start > Esegui(ALT-F2) il commando:
immettendo la password di Administrator. Cosi si apre solo il panello di controllo con privilegi di Administrator che una volta poi chiuso alla fine ritorniamo ai privilegi di Power user da qui siamo partiti.
- Start > Panello di controllo > Rete e connessioni Internet > Connessioni di rete ( Network Connections) window > Right-click sull' icona connessione alla rete locale (Local Area Connection) o a seconda connessione rete senza fili (Wireless Connection) > Properties
- Nel tab General (Generale) selezioniamo Internet Protocol (TCP/IP), e click su Proprietà (Properties)
Nota
- se si utilizza ICS dobbiamo prima settare il host che lo gira. In questo caso come detto prima tutti i host si settano per usare il DHCP
- se abbiamo un router hw configuriamo prima lui abilitando il server DHCP scegliendo (nel caso non si faccia automaticamente) il primo IP assegnabile da un numero a nostra scelta (p.e x.x.x.80) in su cosicché gli IP da x.x.x.2-x.x.x.79 possano essere assegnati staticamente.
- se non abbiamo una connessione internet condivisa dobbiamo settare degli IP statici per tutti i host da x.x.x.2-x.x.x.79
- Per ogi host della rete: clik su Use the following IP address (Utilizza il seguente indirizzo IP) e Attenzione: mettere un diverso indirizzo IP su ognuno partendo (nel nosrto es.) da 192.168.x.2 (ove x può essere 0 oppure 1 date un' occhiata alle istruz. del router) a salire fino a 192.168.x.79
- Su Subnet Mask mettiamo 255.255.255.0
- Default Gateway (Gateway Predefinito) lasciamo vuoto o per i più scrupolosi mettiamo 192.168.x.1
- Clik su Obtain DNS server address automatically (ottieni indirizzo server DNS automaticamente) o mettiamo gli indirizzi di OpenDNS (primario:208.67.220.220 secondario 208.67.220.222) o quelli di google. Clik su Advanced (Avanzate) Intanto che ci siamo controllate nel tab Impostazioni IP se i dati immessi sono quelli giusti (errori di battitura possono sempre succedere). Adesso clik sul secondo tab DNS > click su Add (Aggiungi) e immettete pure 192.168.x.1 come ultimo (nel caso improbabile ma non imposssibile di momentanea interruzione del servizio da parte di OpenDNS)
- Se vicino al tab General abbiamo pure il tab Alternate lo usiamo per immetere le impostazioni statiche mentre in generale lasciamo le impostazioni dinamiche. Ciò serve p.e. quando ci spostiamo col laptop dalla rete di ufficio (che presumibilmente usa DHCP) alla rete di casa (che presumibilmente usa IP statici) e viceversa. Nella serie win 9x si doveva reimpostare tutto a mano. Da XP in poi invece una volta settato all' inizio il passaggio fra i due tipi di rete si fa in modo trasparente per ciò che ci riguarda
- Adesso possiamo bellamente chiudere il tutto, Facciamo un check per verificare la seguente:
Nota: E' Importantissimo assegnare lo stesso workgroup name(Gruppo di lavoro) --di nostra invenzione comunque-- a tutti i host della rete pena di non poter far vedere un host all' altro
Configurare il Firewall di Windows
Configurare il Firewall di Windows
Dopo aver fatto girare il Network Setup Wizard dobbiamo verificare se esso ci ha settato il Windows Firewall corretamente perchè ci possiamo trovare in un estremo con una rete LAN accessibile da chiunque da internet o nell' altro estremo in cui la chiusura è tale da non poter fare possibile la condivisione di file e stampanti
Procedura
Procedura
- Start > Control Panel > Security Center > Windows Firewall
- sulla General tab, assicuriamoci che On(Attivato) è spuntato Don't Allow Exceptions(Non consentire eccezioni) normalmente non deve essere spuntato se vogliamo usare la nostra LAN per file and printer sharing
- sulla Exceptions tab, assicuriamoci che la voce File and Printer Sharing sia spuntata. selezionare questa voce e
- click Edit. La finestra del dialogo che appare deve far vedere la voce Subnet quattro volte. Se qualche voce dice Any anzichè Subnet, si deve cambiare (clik sul bottone sotto a sinistra cambia ambito) e selezionare My Subnet Only(solo la rete locale).
- sulla Advanced tab, ogni nome di connessione deve avere una spunta .
- Click OK per chiudere Windows Firewall e la Security Center window.
- Se il nostro host si connette ad Internet solo via LAN, cioè , attraverso una connessione con un router condiviso o mediante qualche altro host nella LAN, possiamo fermarci qui. Altrimenti se il nostro host si connette direttamente a Internet via un modem o un network adapter ci sarà un broadband modem, Windows Firewall non è sufficiente per proteggerci dal hacking che usa lo stesso nostro Internet service provider! dobbiamo seguire i seguenti passi per protteggere noi stessi:
- Apriamo la Network Connections Window
- Per ogni icona che rappresenta una connessione diretta verso Internet (dial-up icons, o Local Area Connections che connettono direttamente verso un broadband modem), right-click l' icona e seleziona Properties
- sulla General tab, assicuriamoci che le sole 2 voci spuntate sono Internet Protocol (TCP/IP) e QoS Packet Scheduler. Assicuriamoci che File e Printer Sharing ed ogni voce tipo "Client for" non siano spuntate. Facciamo questo Check per tutte le connessioni dirette verso Internet.
Questa procedura deve essere ripetuta per ogni host che è connesso nella nostra LAN. Se qualche host gira qualche win arcinoto (9x)abbisognamo del Network Setup Diskette che abbiamo creato eseguendo il Network wizard: Si puo usare pure il CD ROM inserendolo nel win arcinoto ed aspettando che parta il Windows setup program. Poi scegliamo Perform Additional Task e poi Set up home or small office networking.
Altri Controlli
Altri Controlli
Quando win viene installato (o quando mettiamo una scheda Lan successivamente) automaticamente installa la magggior parte del sw di rete neccessario. Cmq noi facciamo il nostro solito giro dei controlli per verificare se è vero.
Network Clients, Services, Protocols
Network Clients, Services, Protocols
Quando la nostra network card e i suoi drivers sono già installari, Windows sa che la scheda è li ma ancora non le ha attaccato nessun networking software. Seguiamo i passi di sotto per fare il binding dei protocoli e servizi networking che noi vogliamo usare col nostro hardware.
- Start > Control Panel > Network and Internet Connections > Network Connections. Double-click su Local Area Connection(o Wireless Connection) e selezioniamo Properties
- Nella tab General devono esserci e spuntate almeno (dovrebbero essere sufficienti per una home o PMI LAN) le seguenti voci:
- Client for Microsoft Networks: esso è la parte client (del sist. Client-Server di condivisione file e stampanti Windows) che ci permette di accedere a risorse messe in condivisione da altri host nella nostra LAN
- File and Printer Sharing for Microsoft Networks: E' la parte server del sist. di share di Windows e ci permette di condividere con altri nella LAN File stampanti o altro (Se p.e.non vogliamo condividere la nostra stampante o le nostre cartelle basta levare la spunta da questa componenete di Windows networking)
- QoS Packet Scheduler: Questa componenete (Quality of Service assegna diverse priorità ai diversi tipi di traffico rete che possono esistere (p.e. può dare precedenza ad un traffico dati streaming tipo la musica che ascoltiamo o su skype a discapito di un traffico dati concorrente in download di un file *.zip). In pratica per le piccole LAN non ha tanto sesso uttilizzarla ma male comunque non fa
- Internet Protocol (TCP/IP): Questo è il protocollo base per tutti i servizi Internet incluso (solitamente perchè qualcuno può anche utilizzare IPX/SPX di Novell. Guarda un po piu giù) il Microsoft file and printer sharing
Componenti opzionali di Windows networking
- Client Service for NetWare e il protocollo NWLink IPX/SPX forniti con Windows, o i loro omologhi nella verione propria di Novell scaricandoli dal sito di Novell
- Il protocollo Network Monitor Driver permette il monitoraggio(per motivi diagnostici) da parte di un supervisore di rete delle communicationi dei computer nella rete. viene installato solo se richiesto dal nostro network administrator
- Il Service Advertising Protocol service è usato su networks Novell ; E' sempre il network administrator che ci dirà se installarlo o no
- "Microsoft TCP/IP version 6" fornisce supporto per IPV6
Fondamenti di Linux networking
- Nel 1992 Ross Biro e altri crearono quel che diventò poi noto come Net-1.
- Dopo che Ross lascio lo sviluppo nel Maggio 1993, Fred van Kempen cominciò a lavorare su una nuova implementazione, riscrivendo la maggior parte del codice. Tale project fu conosciuto come Net-2.
- La prima release pubblica , Net-2d, fu fatta nell' estate del 1993 (come parte del Linux kernel 0.99.10),
- e da allora fu mantenuta ed espansa da diverse persone fra cui il più noto è Alan Cox. Il suo lavoro originale fu conosciuto come Net-2Debugged. Dopo pesante debugging e numerosi miglioramenti al codice, dopo l' uscita di Linux 1.0 lo battezzò Net-3.
- Il codice di Net-3 fu ulteriormente sviluppato per Linux 1.2 e Linux 2.0.
- La release 2.2 e seguenti dei kernels usano la versione Net-4 del supporto alla rete, il quale rimane lo standard che ci viene offerto ancora oggi.
Per tutte le distro Linux
Prima o poi tutto il traffico di rete passa attraverso il kernel. Data la diversità degli host e delle reti attualmente esistenti il kernel di Linux a differenza di quello di Windows ci da la possibilità di configurarlo ottimizandolo per lo specifico sistema che abbiamo fra le mani. La configurazione del kernel può essere fatta
- a boot time
- o anche dopo il boot
La scelta (a livello progetto del OS) di mettere nel kernel il supporto ai protocolli di rete ad alto livello (HTTP, NFS, SMB/CIFS ecc.) porta a due vantaggi:
- Il loro codice gira molto più veloce che se fosse in user-level
- C' una interazione più forte fra le caratteristiche (features) del protocollo e il resto del sistema. Per esempio Linux permette di montare file exports remoti come se essi fossero filesystems locali e questo grazie al supporto kernel-level per i protocolli di rete file-sharing.
La Socket Library: Nei sistemi Unix e di conseguenza in Linux l' interfaccia di programmazione di rete comunemente usata e la Berkeley Socket Library. Il suo nome deriva dal fatto che vede le porte (ports) come zoccoli (sockets) e il "connetere ad una porta" come il connetere lo zoccolo alla presa. Questa libreria di funzioni fornisce la chiamata alla funzione bind per specificare il host, un transport protocol, ed un servizio a cui un programma può connetersi o mettersi in ascolto (usando connect, listen, e accept). La socket library e' qualcosa di più generale in quanto fornisce non solo la classe di sockets TCP/IP (AF_INET sockets), ma anche la classe di sockets che si occupano di connessioni locali alla macchina(AF_UNIX class). Molte implementazioni forniscono anche ulteriori classi di sockets come la XNS (Xerox Networking System) o X.25.
In Linux, la socket library è parte della standard C library (libc). supporta le classi di sockets per il TCP/IP AF_INET e AF_INET6 e AF_UNIX per gli Unix domain sockets. Supporta inoltre AF_IPX per i protocolli di rete di Novell, AF_X25 per il network protocol X.25, AF_ATMPVC and AF_ATMSVC per il protocollo di rete ATM e AF_AX25, AF_NETROM, e AF_ROSE sockets per supportare il protocollo Amateur Radio. Altre famiglie di protocolli sono in sviluppo e andranno ad inserirsi in questa libreria.
- Dynamic Host Configuration Protocol (DHCP)
- Static IP addresses
- Point-to-Point Protocol (PPP)
Caricare i Network Drivers
Per usare la network card, abbiamo bisogno di speciali funzioni nel kernel che conoscano tutti i particolari di accesso al dispositivo. Il software che implementa tali funzioni prende il nome di device driver. Linux ha device drivers per molti tipi di schede di interfaccia di rete : ISA, PCI, MCA, EISA, Parallel port, PCMCIA, USB. Il driver manda comandi e dati verso la scheda di rete, essa fornisce poi tutti i dati che riceve indietro al driver. Nel mondo dei PC IBM questa communicazione avviene attraverso un set di indirizzi I/O che sono mappati ai registri della scheda o a trasferimenti di memoria (direti o condivisi). Tutti i comandi e dati che manda il kernel verso la scheda vanno a tali indirizzi. Tali indirizzi (di I/O e memoria) in genere sono descritti fornendo l' indirizzo iniziale o base. Tipici indirizzi base per Ethernet cards su bus ISA sono 0x280 o 0x300. Invece le network cards per il bus PCI in genere hanno il loro indirizo I/O assegnato in automatico.Normalmente il kernel a boot time tenta di rilevare la locazione della card attraverso l' auto-probing: Il kernel legge diverse locazioni di memoria e I/O e compara i dati letti con quello che aspetta di vedere se una certa network card fosse installata in quella locazione. Qualche volta non riesce a rilevare la card automaticamente o per mancanza di qualità della card (costruita non rispettando degli standard) o se abbiamo più di una network card per esempio per default rileva solo la prima e non le altre (in tal caso dobbiamo dire noi al kernel in modo esplicito circa le card non rilevate). L' Ethernet HOWTO riporta se un particolare driver utilizza l' auto-probing e in quale ordine cerca nello spazio di indirizzamento I/O per trovare l' hardware.
L'autoprobing ha 3 limitazioni:
- ha difficolta di rilevare le schede a bassissimo costo(che non rispettano gli standards)
- Il kernel per default rileva solo una scheda di rete. questo è una scelta di progetto perchè si pensò di dare libertà di scelta all' utente sul binding scheda- interfaccia. Il miglior modo(affidabile) quindi è di configurare le schede di rete manualmente
- Il driver potrebbe non rilevare(probe) correttamente l' indirizzo nel quale è stata configurata la scheda di rete. In genere il driver può autorilevare l' indirizzo, ma talvolta certi indirizzi vengono ignorati per evitare conflitti hardware con altri tipi di hardware che comunemente usano lo stesso indirizzo.
Le schede su bus PCI non hanno di solito problemi di rilevamento ma se si è sfortunati a cadere in una delle limitazioni di autorilevazione si deve fornire manualmente al kernel l' indirizzo base e il nome (a boot time si possono fornire al kernel argomenti che poi verrano letti dai componenti interessati del kernel. Tale meccanismo ci permette di passare informazione al kernel che verrà letta dai driver Ethernet potendo poi esso localizzare l' harware Ethernet bypassando cosi il driver autoprobe)
Un altro parametro che dobbiamo comunicare al kernel è l' interrupt request number (IRQ): I componenti hardware interrompono le operazioni del kernel quando vogliono la sua attenzione (per esempio quando arriva un dato o avviene una condizione particolare) In un bus ISA nei PC ,gli interrupt possono occorere su uno dei 15 canali(vedi quote sotto) interrupt numerati 0-15. L' azione di assegnare un interrupt number su un componente hardware si chiama interrupt request number (IRQ).
Un altro parametro che dobbiamo comunicare al kernel è l' interrupt request number (IRQ): I componenti hardware interrompono le operazioni del kernel quando vogliono la sua attenzione (per esempio quando arriva un dato o avviene una condizione particolare) In un bus ISA nei PC ,gli interrupt possono occorere su uno dei 15 canali(vedi quote sotto) interrupt numerati 0-15. L' azione di assegnare un interrupt number su un componente hardware si chiama interrupt request number (IRQ).
Gli IRQ 2 e 9 sono gli stesi perchè nel progetto IBM PC ci sono 2 cascaded interrupt processors ognuno con 8 IRQs; il processore secondario è connesso al IRQ 2 del processore primarioAbbiamo già detto che il kernel accede un dispositivo hardware di network attraverso un costrutto software chiamato interfaccia(interface).
Le interfacce offrono un insieme astratto di funzioni(operazioni) che sono le stesse per tutti i tipi di hardware e sono identificate da dei nomi.In molti sistemi operativi Unix-like , un interfaccia è implementata come special (o device) file (o node) nella directory /dev/. Se diamo:
harrykar@harrysas:~$ ls -las /dev/ total 4 0 drwxr-xr-x 15 root root 4120 2009-09-14 10:37 . 4 drwxr-xr-x 22 root root 4096 2009-08-18 11:14 .. 0 crw-rw----+ 1 root audio 14, 12 2009-09-14 10:37 adsp 0 crw-rw----+ 1 root audio 14, 4 2009-09-14 10:37 audio 0 drwxr-xr-x 2 root root 800 2009-09-14 10:37 block 0 drwxr-xr-x 3 root root 60 2009-09-14 12:37 bus 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 cdrom -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 cdrom1 -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 cdrw -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 cdrw1 -> sr1 0 drwxr-xr-x 2 root root 3060 2009-09-14 10:37 char 0 crw------- 1 root root 5, 1 2009-09-14 10:37 console 0 lrwxrwxrwx 1 root root 11 2009-09-14 12:37 core -> /proc/kcore 0 crw-rw---- 1 root root 10, 60 2009-09-14 12:37 cpu_dma_latency 0 drwxr-xr-x 5 root root 100 2009-09-14 12:37 disk 0 crw-rw----+ 1 root audio 14, 3 2009-09-14 15:37 dsp 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 dvd -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 dvd1 -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 dvdrw -> sr1 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 dvdrw1 -> sr1 0 crw-rw---- 1 root root 10, 63 2009-09-14 12:37 ecryptfs 0 lrwxrwxrwx 1 root root 13 2009-09-14 12:37 fd -> /proc/self/fd 0 crw-rw-rw- 1 root root 1, 7 2009-09-14 12:37 full 0 crw-rw-rw-+ 1 root fuse 10, 229 2009-09-14 12:37 fuse 0 crw-rw---- 1 root root 10, 228 2009-09-14 12:37 hpet 0 prw------- 1 root root 0 2009-09-14 10:37 initctl 0 drwxr-xr-x 3 root root 100 2009-09-14 12:37 .initramfs 0 -rw-r--r-- 1 root root 0 2009-09-14 12:37 .initramfs-tools 0 drwxr-xr-x 3 root root 240 2009-09-14 10:37 input 0 crw-r----- 1 root kmem 1, 2 2009-08-06 23:56 kmem 0 crw-rw---- 1 root root 1, 11 2009-09-14 12:37 kmsg 0 srw-rw-rw- 1 root root 0 2009-09-14 10:37 log 0 brw-rw---- 1 root disk 7, 0 2009-08-06 23:56 loop0 0 brw-rw---- 1 root disk 7, 1 2009-09-14 12:37 loop1 0 brw-rw---- 1 root disk 7, 2 2009-09-14 12:37 loop2 0 brw-rw---- 1 root disk 7, 3 2009-09-14 12:37 loop3 0 brw-rw---- 1 root disk 7, 4 2009-09-14 12:37 loop4 0 brw-rw---- 1 root disk 7, 5 2009-09-14 12:37 loop5 0 brw-rw---- 1 root disk 7, 6 2009-09-14 12:37 loop6 0 brw-rw---- 1 root disk 7, 7 2009-09-14 12:37 loop7 0 drwxr-xr-x 2 root root 60 2009-09-14 12:37 mapper 0 crw-r----- 1 root kmem 1, 1 2009-09-14 12:37 mem 0 crw-rw----+ 1 root audio 14, 0 2009-09-14 10:37 mixer 0 drwxr-xr-x 2 root root 60 2009-08-06 23:56 net 0 crw-rw---- 1 root root 10, 59 2009-09-14 12:37 network_latency 0 crw-rw---- 1 root root 10, 58 2009-09-14 12:37 network_throughput 0 crw-rw-rw- 1 root root 1, 3 2009-08-06 23:56 null 0 crw-rw-rw- 1 root root 195, 0 2009-09-14 10:37 nvidia0 0 crw-rw-rw- 1 root root 195, 255 2009-09-14 10:37 nvidiactl 0 crw-rw---- 1 root root 1, 12 2009-09-14 12:37 oldmem 0 drwxr-xr-x 2 root root 60 2009-09-14 12:37 pktcdvd 0 crw-r----- 1 root kmem 1, 4 2009-09-14 12:37 port 0 crw------- 1 root root 108, 0 2009-08-06 23:56 ppp 0 crw-rw---- 1 root root 10, 1 2009-09-14 12:37 psaux 0 crw-rw-rw- 1 root tty 5, 2 2009-09-14 23:16 ptmx 0 drwxr-xr-x 2 root root 0 2009-09-14 12:37 pts 0 brw-rw---- 1 root disk 1, 0 2009-09-14 12:37 ram0 0 brw-rw---- 1 root disk 1, 1 2009-09-14 12:37 ram1 0 brw-rw---- 1 root disk 1, 10 2009-09-14 12:37 ram10 0 brw-rw---- 1 root disk 1, 11 2009-09-14 12:37 ram11 0 brw-rw---- 1 root disk 1, 12 2009-09-14 12:37 ram12 0 brw-rw---- 1 root disk 1, 13 2009-09-14 12:37 ram13 0 brw-rw---- 1 root disk 1, 14 2009-09-14 12:37 ram14 0 brw-rw---- 1 root disk 1, 15 2009-09-14 12:37 ram15 0 brw-rw---- 1 root disk 1, 2 2009-09-14 12:37 ram2 0 brw-rw---- 1 root disk 1, 3 2009-09-14 12:37 ram3 0 brw-rw---- 1 root disk 1, 4 2009-09-14 12:37 ram4 0 brw-rw---- 1 root disk 1, 5 2009-09-14 12:37 ram5 0 brw-rw---- 1 root disk 1, 6 2009-09-14 12:37 ram6 0 brw-rw---- 1 root disk 1, 7 2009-09-14 12:37 ram7 0 brw-rw---- 1 root disk 1, 8 2009-09-14 12:37 ram8 0 brw-rw---- 1 root disk 1, 9 2009-09-14 12:37 ram9 0 crw-rw-rw- 1 root root 1, 8 2009-09-14 12:37 random 0 lrwxrwxrwx 1 root root 4 2009-09-14 12:37 rtc -> rtc0 0 crw-rw---- 1 root root 254, 0 2009-09-14 12:37 rtc0 0 lrwxrwxrwx 1 root root 3 2009-09-14 12:37 scd0 -> sr0 0 lrwxrwxrwx 1 root root 3 2009-09-14 10:37 scd1 -> sr1 0 brw-rw---- 1 root disk 8, 0 2009-09-14 12:37 sda 0 brw-rw---- 1 root disk 8, 1 2009-09-14 12:37 sda1 0 brw-rw---- 1 root disk 8, 2 2009-09-14 12:37 sda2 0 brw-rw---- 1 root disk 8, 3 2009-09-14 12:37 sda3 0 brw-rw---- 1 root disk 8, 16 2009-09-14 12:37 sdb 0 brw-rw---- 1 root disk 8, 17 2009-09-14 12:37 sdb1 0 brw-rw---- 1 root disk 8, 26 2009-09-14 10:37 sdb10 0 brw-rw---- 1 root disk 8, 21 2009-09-14 10:37 sdb5 0 brw-rw---- 1 root disk 8, 22 2009-09-14 10:37 sdb6 0 brw-rw---- 1 root disk 8, 23 2009-09-14 10:37 sdb7 0 brw-rw---- 1 root disk 8, 24 2009-09-14 10:37 sdb8 0 brw-rw---- 1 root disk 8, 25 2009-09-14 10:37 sdb9 0 crw-rw----+ 1 root audio 14, 1 2009-09-14 10:37 sequencer 0 crw-rw----+ 1 root audio 14, 8 2009-09-14 10:37 sequencer2 0 crw-rw---- 1 root disk 21, 0 2009-09-14 12:37 sg0 0 crw-rw---- 1 root disk 21, 1 2009-09-14 12:37 sg1 0 crw-rw----+ 1 root cdrom 21, 2 2009-09-14 12:37 sg2 0 crw-rw----+ 1 root cdrom 21, 3 2009-09-14 10:37 sg3 0 drwxrwxrwt 2 root root 140 2009-09-14 22:49 shm 0 crw-rw---- 1 root root 10, 231 2009-09-14 12:37 snapshot 0 drwxr-xr-x 2 root root 200 2009-09-14 10:37 snd 0 lrwxrwxrwx 1 root root 24 2009-09-14 12:37 sndstat -> /proc/asound/oss/sndstat 0 brw-rw----+ 1 root cdrom 11, 0 2009-09-14 12:37 sr0 0 brw-rw----+ 1 root cdrom 11, 1 2009-09-14 10:37 sr1 0 lrwxrwxrwx 1 root root 15 2009-09-14 12:37 stderr -> /proc/self/fd/2 0 lrwxrwxrwx 1 root root 15 2009-09-14 12:37 stdin -> /proc/self/fd/0 0 lrwxrwxrwx 1 root root 15 2009-09-14 12:37 stdout -> /proc/self/fd/1 0 crw-rw-rw- 1 root tty 5, 0 2009-09-14 17:00 tty 0 crw--w---- 1 root root 4, 0 2009-09-14 12:37 tty0 0 crw------- 1 root root 4, 1 2009-09-14 10:37 tty1 0 crw--w---- 1 root tty 4, 10 2009-09-14 12:37 tty10 0 crw--w---- 1 root tty 4, 11 2009-09-14 12:37 tty11 0 crw--w---- 1 root tty 4, 12 2009-09-14 12:37 tty12 0 crw--w---- 1 root tty 4, 13 2009-09-14 12:37 tty13 0 crw--w---- 1 root tty 4, 14 2009-09-14 12:37 tty14 0 crw--w---- 1 root tty 4, 15 2009-09-14 12:37 tty15 0 crw--w---- 1 root tty 4, 16 2009-09-14 12:37 tty16 0 crw--w---- 1 root tty 4, 17 2009-09-14 12:37 tty17 0 crw--w---- 1 root tty 4, 18 2009-09-14 12:37 tty18 0 crw--w---- 1 root tty 4, 19 2009-09-14 12:37 tty19 0 crw------- 1 root root 4, 2 2009-09-14 10:37 tty2 0 crw--w---- 1 root tty 4, 20 2009-09-14 12:37 tty20 0 crw--w---- 1 root tty 4, 21 2009-09-14 12:37 tty21 0 crw--w---- 1 root tty 4, 22 2009-09-14 12:37 tty22 0 crw--w---- 1 root tty 4, 23 2009-09-14 12:37 tty23 0 crw--w---- 1 root tty 4, 24 2009-09-14 12:37 tty24 0 crw--w---- 1 root tty 4, 25 2009-09-14 12:37 tty25 0 crw--w---- 1 root tty 4, 26 2009-09-14 12:37 tty26 0 crw--w---- 1 root tty 4, 27 2009-09-14 12:37 tty27 0 crw--w---- 1 root tty 4, 28 2009-09-14 12:37 tty28 0 crw--w---- 1 root tty 4, 29 2009-09-14 12:37 tty29 0 crw------- 1 root root 4, 3 2009-09-14 10:37 tty3 0 crw--w---- 1 root tty 4, 30 2009-09-14 12:37 tty30 0 crw--w---- 1 root tty 4, 31 2009-09-14 12:37 tty31 0 crw--w---- 1 root tty 4, 32 2009-09-14 12:37 tty32 0 crw--w---- 1 root tty 4, 33 2009-09-14 12:37 tty33 0 crw--w---- 1 root tty 4, 34 2009-09-14 12:37 tty34 0 crw--w---- 1 root tty 4, 35 2009-09-14 12:37 tty35 0 crw--w---- 1 root tty 4, 36 2009-09-14 12:37 tty36 0 crw--w---- 1 root tty 4, 37 2009-09-14 12:37 tty37 0 crw--w---- 1 root tty 4, 38 2009-09-14 12:37 tty38 0 crw--w---- 1 root tty 4, 39 2009-09-14 12:37 tty39 0 crw------- 1 root root 4, 4 2009-09-14 10:37 tty4 0 crw--w---- 1 root tty 4, 40 2009-09-14 12:37 tty40 0 crw--w---- 1 root tty 4, 41 2009-09-14 12:37 tty41 0 crw--w---- 1 root tty 4, 42 2009-09-14 12:37 tty42 0 crw--w---- 1 root tty 4, 43 2009-09-14 12:37 tty43 0 crw--w---- 1 root tty 4, 44 2009-09-14 12:37 tty44 0 crw--w---- 1 root tty 4, 45 2009-09-14 12:37 tty45 0 crw--w---- 1 root tty 4, 46 2009-09-14 12:37 tty46 0 crw--w---- 1 root tty 4, 47 2009-09-14 12:37 tty47 0 crw--w---- 1 root tty 4, 48 2009-09-14 12:37 tty48 0 crw--w---- 1 root tty 4, 49 2009-09-14 12:37 tty49 0 crw------- 1 root root 4, 5 2009-09-14 10:37 tty5 0 crw--w---- 1 root tty 4, 50 2009-09-14 12:37 tty50 0 crw--w---- 1 root tty 4, 51 2009-09-14 12:37 tty51 0 crw--w---- 1 root tty 4, 52 2009-09-14 12:37 tty52 0 crw--w---- 1 root tty 4, 53 2009-09-14 12:37 tty53 0 crw--w---- 1 root tty 4, 54 2009-09-14 12:37 tty54 0 crw--w---- 1 root tty 4, 55 2009-09-14 12:37 tty55 0 crw--w---- 1 root tty 4, 56 2009-09-14 12:37 tty56 0 crw--w---- 1 root tty 4, 57 2009-09-14 12:37 tty57 0 crw--w---- 1 root tty 4, 58 2009-09-14 12:37 tty58 0 crw--w---- 1 root tty 4, 59 2009-09-14 12:37 tty59 0 crw------- 1 root root 4, 6 2009-09-14 10:37 tty6 0 crw--w---- 1 root tty 4, 60 2009-09-14 12:37 tty60 0 crw--w---- 1 root tty 4, 61 2009-09-14 12:37 tty61 0 crw--w---- 1 root tty 4, 62 2009-09-14 12:37 tty62 0 crw--w---- 1 root tty 4, 63 2009-09-14 12:37 tty63 0 crw--w---- 1 root root 4, 7 2009-09-14 12:37 tty7 0 crw--w---- 1 root tty 4, 8 2009-09-14 10:37 tty8 0 crw--w---- 1 root tty 4, 9 2009-09-14 12:37 tty9 0 crw-rw---- 1 root dialout 4, 64 2009-09-14 12:37 ttyS0 0 crw-rw---- 1 root dialout 4, 65 2009-09-14 12:37 ttyS1 0 crw-rw---- 1 root dialout 4, 66 2009-09-14 12:37 ttyS2 0 crw-rw---- 1 root dialout 4, 67 2009-09-14 12:37 ttyS3 0 drwxr-xr-x 6 root root 140 2009-09-14 17:01 .udev 0 crw-rw-rw- 1 root root 1, 9 2009-09-14 10:37 urandom 0 crw-rw---- 1 root root 252, 1 2009-09-14 12:37 usbdev1.1_ep00 0 crw-rw---- 1 root root 252, 0 2009-09-14 12:37 usbdev1.1_ep81 0 crw-rw---- 1 root root 252, 7 2009-09-14 12:37 usbdev1.2_ep00 0 crw-rw---- 1 root root 252, 4 2009-09-14 12:37 usbdev1.2_ep02 0 crw-rw---- 1 root root 252, 6 2009-09-14 12:37 usbdev1.2_ep81 0 crw-rw---- 1 root root 252, 5 2009-09-14 12:37 usbdev1.2_ep86 0 crw-rw---- 1 root root 252, 3 2009-09-14 12:37 usbdev2.1_ep00 0 crw-rw---- 1 root root 252, 2 2009-09-14 12:37 usbdev2.1_ep81 0 crw-rw---- 1 root root 253, 0 2009-09-14 12:37 usbmon0 0 crw-rw---- 1 root root 253, 1 2009-09-14 12:37 usbmon1 0 crw-rw---- 1 root root 253, 2 2009-09-14 12:37 usbmon2 0 crw-rw---- 1 root tty 7, 0 2009-09-14 12:37 vcs 0 crw-rw---- 1 root tty 7, 1 2009-09-14 10:37 vcs1 0 crw-rw---- 1 root tty 7, 2 2009-09-14 10:37 vcs2 0 crw-rw---- 1 root tty 7, 3 2009-09-14 10:37 vcs3 0 crw-rw---- 1 root tty 7, 4 2009-09-14 10:37 vcs4 0 crw-rw---- 1 root tty 7, 5 2009-09-14 10:37 vcs5 0 crw-rw---- 1 root tty 7, 6 2009-09-14 10:37 vcs6 0 crw-rw---- 1 root tty 7, 7 2009-09-14 10:37 vcs7 0 crw-rw---- 1 root tty 7, 8 2009-09-14 12:37 vcs8 0 crw-rw---- 1 root tty 7, 128 2009-09-14 12:37 vcsa 0 crw-rw---- 1 root tty 7, 129 2009-09-14 10:37 vcsa1 0 crw-rw---- 1 root tty 7, 130 2009-09-14 10:37 vcsa2 0 crw-rw---- 1 root tty 7, 131 2009-09-14 10:37 vcsa3 0 crw-rw---- 1 root tty 7, 132 2009-09-14 10:37 vcsa4 0 crw-rw---- 1 root tty 7, 133 2009-09-14 10:37 vcsa5 0 crw-rw---- 1 root tty 7, 134 2009-09-14 10:37 vcsa6 0 crw-rw---- 1 root tty 7, 135 2009-09-14 10:37 vcsa7 0 crw-rw---- 1 root tty 7, 136 2009-09-14 12:37 vcsa8 0 prw-r----- 1 syslog adm 0 2009-09-14 10:37 xconsole 0 crw-rw-rw- 1 root root 1, 5 2009-09-14 12:37 zero
vedremmo quali sono i device files nel nostro sistema(l:long list, a:show hidden files, s:sort by file size). Nella seconda colonna (file permissions) vediamo che molti device files cominciano con una lettera che identifica il tipo del dispositivo. Il più comune tipo di dispositivo è:
I drivers risiedono nel sistema. in una delle due forme (dipende da come abbiamo compilato il kernel modalità monolitica o modulare) :
come parte integrale del kernel(monolitico). In questo caso il caricamento dei drivers, interfacce rilevate avviene quando si carica il kernel stesso (a boot time). Per qualche network card (specialmente quando il sistema ha interfacce di rete multiple) però potrebbe essere necessario passare dei parametri al driver attraverso le opzioni di kernel durante il boot.
- b (block device) che vuol dire che il dipositivo può gestire interi blocchi di dati alla volta per ogni operazione di lettura/scrittura
- c(character device) che vuol dire che il dipositivo può gestire un carattere alla volta
- major device number: l' attuale disositivo con cui il device file è associato. Ogni device driver registra nel kernel un unico major number.
- minor device number: Ogni istanza(instance) di tale dispositivo registra un unico minor number per questo major device.
- un major number 4
- ma /dev/tty1 ha un minor number 1, e /dev/tty2 ha un minor number 2.
Le interfacce SLIP si manipolano in modo diverso dalle altre perchè esse sono assegnate dinamicamene. Allorquando la connessione SLIP fosse stabilita , un interfaccia è assegnata alla porta seriale.Senza dubbio alcuno l' optimum da questo punto di vista sarebbe compilare da se il kernel perchè con i kernel precompilati delle varie distribuzioni arrivano un sacco di dispositivi che noi magari non useremo mai ma che occupano spazio su disco e RAM.
I drivers risiedono nel sistema. in una delle due forme (dipende da come abbiamo compilato il kernel modalità monolitica o modulare) :
come parte integrale del kernel(monolitico). In questo caso il caricamento dei drivers, interfacce rilevate avviene quando si carica il kernel stesso (a boot time). Per qualche network card (specialmente quando il sistema ha interfacce di rete multiple) però potrebbe essere necessario passare dei parametri al driver attraverso le opzioni di kernel durante il boot.
$ ether=irq,base_addr,[param1],[param2],name
- Se configuro tutti i valori numerici (irq, base_addr, name) a 0(zero) si fa l' autorilevazione.
- Il primo parametro configura l' IRQ assegnato al dispositivo. Per esempio il driver 3c503 ha una proprietà speciale che seleziona un IRQ libero dalla lista 5, 9, 3, 4 e configura la scheda di rete per usare la linea interrupt.
- Il parametro base_addr riporta l' I/O base address dell' hardware;
- Differenti drivers usano i prossimi due parametri in modo differente. Per shared-memory cards, come la WD80x3 per esempio, tali parametri specificano l' indirizzo iniziale e finale della shared memory area. Altri tipi di schede di rete invece usano il parametro opzionale param1 per settare il livello di dettaglio con cui la debugging information deve apparire. Valori fra 1 - 7 aumentano il levello di verbosità, mentre 8 toglie ogni debugging information; 0 denota il default (autorilevazione). Il driver 3c503 usa param2 per scegliere fra internal transceiver (default 0) o external transceiver (valore 1). Il primo usa il BNC connector della scheda ; L'ultimo usa la sua AUI port.
- Il primo argomento non numerico viene interpretato dal kernel come nome di interfaccia del dispositivo. Dobbiamo dare un nome di dispositivo per ogni scheda Ethernet che descriviamo. Nel caso di 2 schede Ethernet Linux di default autorileva la prima e passa alla seconda i parametri dal prompt del bootloader (lilo, grub). Dobbiamo assicurarci che il kernel non trovi accidentalmente per prima la seconda scheda di rete nel qualcaso la prima non verrà neanche registrata. Tale controllo lo facciamo attraverso la sua opzione reserve la quale dice esplicitamente al kernel di evitare il probing dell I/O space occupato dalla seconda scheda.
Per esempio se vogliamo che Linux installi la seconda scheda di rete Ethernet in 0x300 come eth1, dobbiamo passare i seguenti parametri al kernel nel suo file di configurazione /etc/lilo.conf (per rendere le modifiche permanenti)
Dopo aver modificato il file di configurazione dobbiamo rieseguire lilo affinchè lui possa rilleggerlo(per grub invece questo step non è necessario)o nel prompt di lilo (ad ogni boot perché le modifiche in questo modo si perdono fra un boot e il susccessivo) che ottengo premendo Control, Alt o Shift quando si fa il boot.
boot:
Premendo il tasto Tab al prompt, si ottiene una lista di kernels con cui si puo fare il boot. Dobbiamo immetere il kernel desiderato seguito da spazio e i parametri. Quando premiamo Enter(Invio), lilo caricherà il kernel e farà il boot con i parametri che abbiamo fornito) :
reserve=0x300,32 ether=0,0x300,eth1
Possiamo usare i parametri del kernel per bypassare i risultati dell' autoprobing per eth0:
reserve=0x340,32 ether=0,0x340,eth0
Possiamo disabilitare l' autoprobing( anche mettendo base_addr a -1) per una scheda Ethernet che abbiamo per esempio temporaneamene scollegata:
ether=0,-1,eth0
Nella maggioranza dei casi il driver rileverà la network card senza un ulteriore nostro intervento. Documentatione per tutti i tipi di schede generalmente si trova in /usr/src/linux/Documentation/networking/ dei sorgenti del Linux kernel.
come moduli (files) separati del kernel(modulare). In questo caso si possono passare dei parametri attraverso il file /etc/modules.conf(or /etc/modules). Linux caricherà i drivers automaticamente allorquando rivela un tentativo di inizializzare una interfaccia di rete. Se per qualsiasi ragione dovessimo fare questo processo manualmente dovremmo dare il commando insmod:
# insmod nome_driver
Se il modulo del kernel fallisce a caricarsi automaticamente possiamo forzarlo con un comando in un script di startup /etc/rc.d/rc.local o /etc/rc.d/boot.local.
Se la nostra connessione utilizza PPP, SLIP(CSLIP PSLIP), o qualche altro protocollo software su una porta di comunicazione legacy non tradizionalmente di rete come la seriale/parallela dobbiamo caricare i driver anche per tale porta.
Se la nostra connessione utilizza PPP, SLIP(CSLIP PSLIP), o qualche altro protocollo software su una porta di comunicazione legacy non tradizionalmente di rete come la seriale/parallela dobbiamo caricare i driver anche per tale porta.
Il principale vantaggio del protocollo PPP sul suo omologo SLIP oltre ad essere un protocollo più recente, è anche più avanzato perchè mentre SLIP trasporta solo datagram IP, PPP invece è stato progettato per trasportare datagrams di qualsiasi protocolloQuindi in questo caso sono neccessari due drivers:
- un driver a basso livello per il hardware della porta ed
- un driver per il protocollo di rete.
Qualche volta uno di questi può richiedere driver addizionali p.e. un modem USB può richiedere 2-3 driver in più per essere in grado di funzionare
Usare un DHCP Client
Usare un DHCP Client
Si deve usare un DHCP client per configurare Linux a ottenere automaticamente il suo indirizzo IP dal omonimo server. Questo client manda un messagio broadcast sul suo segmento di LAN per trovare un DHCP server. Se un DHCP server risponde, e la negoziazione va bene, avremo un sistema con un indirizzo IP (e informazione accessoria --gateway address, DNS addresss, opzionalmente NIS address-- annessa) assocciato, perfettamente configurato per usare la connessione. Tutto ciò si fa in automatico.
NOTA:---Se vogliamo che il nostro computer funzioni (attraverso i network settings o in molte disto durante l' installazione) come un DHCP server è neccessario configurare il DHCP server(ciò vale per ogni server) con un indirizzo IP statico. Se invece vogliamo riconfigurarre il computer dopo l' installazione, conviene usare un tool di configurazione dotato di GUI, come Linuxconf (Red Hat, Mandrake), COAS (Caldera), o YaST, YaST2 (SuSE).
Sfortunatamente, la configurazione DHCP non fila sempre cosi liscia. Potenziali problemi possono essere:
- Clients DHCP Incompatibili col DHCP server— Comunemente ci sono 4 DHCP clients sui sistemi Linux: pump, dhclient, dhcpxd, e dhcpcd (non confondere questi ultimi 2 con dhcpd, che è il server DHCP). Sebbene tutti vadano bene, qualche network usa servers DHCP che possono avere problemi con qualcuno dei suddetti DHCP clients. In tal caso si deve sostituire il DHCP client package con un altro.
- Incompatibilità delle opzioni DHCP— In pratica questo caso può essere difficile distinguersi da quello di un client DHCP incompatibile, la soluzione sta nel editare (ovviamente si deve conoscere ben bene il proprio DHCP client per sapere in quali opzioni mettere mano in tal caso RTFM) il DHCP startup script per cambiare tali opzioni.
- Configurazioni Multi-NIC— Se il nostro computer ha più network interface cards (NICs), e noi dobbiamo fare in modo che il DHCP client ottenga il suo indirizzo IP solo da una di esse , oppure che reietti alcune informazioni (come l' indirizzo del gateway) per qualche NIC, in primis , è neccessario editare il DHCP client startup script , o si potrebbe voler creare un script custom(all' uopo) per correggere una configurazione automatica.
Assegnare indirizzi IP
Se configuriamo software di rete per uso standalone (ossia software che abbisogna usare networking per poter funzionare come eseguire solo il software INN Netnews per esempio) il solo indirizzo IP che abbisognamo è quello della loopback interface, che è sempre 127.0.0.1.
La cosa si complica quando vogliamo conneterci su una rete reale già esistente. Allora dobbiamo disporre un indirizzo IP (dal netadmin o assegnarlo noi stessi). Inoltre se abbiamo più reti fisiche o una rete suddivisa in più sottoreti (subnetting) dobbiamo assegnare loro indirizzi IP differenti.
Se vogliamo un network number pubblico possiamo richiedere una Network Address Application Form diretttamente da hostmaster@internic.net o dal corrispondente ente nazionale NIC(se esiste)
Se invece non vogliamo connettere la nostra LAN ad Internet possiamo scegliere qualsiasi indirizzo legale(pubblico) IP. L' unica nostra preoccupazione sarà di non lasciar passare i pacchetti della nostra LAN verso Internet. Per assicurarci di questo dobbiamo scegliere uno dei network numbers riservati per uso privato. Internet Assigned Numbers Authority (IANA) ha messo a disposizione diversi network numbers nelle classi A, B, e C (il secondo e terzo blocco contengono 16 e 256 networks, rispettivamente) che possiamo usare senza bisogno di registrazione (definiti da RFC 1597). Tali indirizzi sono validi solo dentro la nostra LAN privata e non si usano per l' instradamento dei pacchetti fra siti Internet reali. Gli indirizzi per uso privato consentono anche un accesso più ristretto verso la nostra LAN da Internet se usiamo un singolo host come gateway.
Il gateway sarà accessibile da parte della LAN attraverso il suo indirizzo IP interno, invece il mondo esterno lo conoscerà da un indirizzo IP esterno regolarmente registrato (da parte del nostro ISP).
Creare subnets
Per avere più Ethernets (o altri tipi di rete una volta che il loro driver è disponibile) dobbiamo suddividere la rete in sottoreti.
Il subnetting è richiesto solo quando abbiamo più di una rete broadcast--i point-to-point links sono ininfluenti. Per esempio, se si ha una Ethernet, e uno o più links SLIP verso il mondo esterno, non abbisogna suddividere la nostra rete.
Assumendo che il netadmin del network Brewery usa un network number di classe B come 172.16.0.0, per accomodare due Ethernets e decidendo di usare 8 bit della parte host number come bit per la subnet quindi dai 16 bit iniziali del host number rimangono 8 bit per le subnets(netmask) e altri 8 bits per la nuova parte host number , avendo cosi 2^8=254 hosts su ognuna delle due subnets.
Poi assegna un subnet number 1 per la subnet brewery, e 2 per la subnet winery. I rispettivi indirizzi di rete quindi saranno rispettivamente 172.16.1.0 e 172.16.2.0. La subnet mask è 255.255.255.0. Al vlager, il gateway fra i due networks, viene assegnato un host number 1 su entrambi le subnets, avendo quindi gli indirizzi IP 172.16.1.1 e 172.16.2.1, rispettivamente.
Tutto quanto detto sopra vale anche per una rete di classe C --dato che il subnetting non è limitato da byte boundaries--. Per esempio possiamo usare due ulteriori bits dalla parte host per la netmask, ottenendo 4 possibili subnets ognuna con 2^6=64 hosts (precisamente 62 hosts dato che il primo numero IP del range di ogni subnet rappresenta il suo subnetwork address e l' ultimo IP in ogni subnet è riservato al broadcast address).
Configurare un indirizzo IP statico(Static IP Address)
Tradizionalmente, i server hanno sempre usato l' assegnazione statica dell' indirizzo IP perchè esso assicura che l' indirizzo IP del server non può cambiare arbitrariamente. Questo è molto importante per il maping di hostnames su indirizzi IP (come mail.thiessen.it--> 172.23.45.67) via un DNS server.
- E' possibile assegnare lo stesso indirizzo a un computer in diversi istanti di tempo via DHCP.
- Esistono anche dei servizi DNS dinamici (dyndns, noip ecc.) che fanno il mapping di un hostname su un indirizzo IP dinamico (gli IP dinamici rappresentano la maggioranza).
Configurare le Interfacce di rete (Network Interfaces)
Dobbiamo far si che il sottosistema networking del kernel (NET-4) sia a conoscenza dei nostri dispositivi hardware di rete.
Per astrarre dalla diversità del equipaggiamento hardware che può essere usato nella rete, TCP/IP definisce una interfaccia astratta attraverso cui tale hardware possa essere acceduto. Tale interfaccia offre un set di operazioni che rimane lo stesso per tutti i tipi di hardware della stessa classe(Ethernet, PPP ecc) e fondamentalmente ha a che fare col emettere e e ricevere pacchetti.
Per ogni dispositivo periferico di rete la corrispondente interfaccia (contraddistinta da un nome) deve essere presente nel kernel. Per esempio:
- le interfacce PPP ( Point-to-Point Protocol) in Linux si chiamano ppp0, ppp1 etc.
- le interfacce FDDI si chiamano fddi0, fddi1 etc.
Questi nomi di interfaccia si usano esclusivamente a proposito di configurazione quando vogliamo specificare un particolare dispositivo fisico in un commando di configurazione. Prima di poter esser usata l'interfaccia dal networking TCP/IP le si deve assegnare un indirizzo IP per poterla identificare univocamente quando communica col resto del mondo.
Per fare un parallelo l''indirizzo IP differisce dal nome dell' interfaccia per quanto differisce la targhetta appesa ad una porta dalla porta stessa.Inoltre devono essere configurati diversi parametri di dispositivo come la Maximum Transfer Unit (MTU) che sarebbe la max dimensione dei datagrams che devono essere processati da un particolare dispositivo. Fortunatamente molti attributi possegono valori di default adeguati. Se non si specificano esplicitamente si applicano i valori di default.
Per esempio la netmask di default deriva dalla classe della rete a cui appartiene l' indirizzo IP:Per disporre di un interfaccia di rete:
- 255.255.0.0 per un IP di classe B
- 255.255.255.0 per un IP di classe C ecc.
- il primo passo in assoluto è caricare il suo driver.
- Per usare poi l' interfaccia si deve assegnare un indirizzo IP più altre informazioni tipo la subnet mask( netmask). Questo è compito dell' utility ifconfig la quale fornisce informazioni sull' interfaccia o cambia la configurazione dell' interfaccia in funzione di come si usa. In altre parole fa accessibile (assegna tra altri parametri l' indirizzo IP e attiva l'interfaccia ---quest' ultimo conosciuto anche come interface "bringing up"---. Attivare qui vuol dire che il kernel può mandare e ricevere IP datagrams attraverso l' interfaccia) un interfaccia al networking layer del kernel:
#ifconfig [interface] [options]
#ifconfig interface [address [parameters]]
- interface è il nome d' interfaccia
- address è l'indirizzo IP che viene assegnato all' interfaccia. IP può essere nella forma dotted quad notation(x.x.x.x) o un nome che viene risolto dal file /etc/hosts dentro cui va a guardare ifconfig
Ci sono due modalità d'uso:
- ifconfig se usato senza parametri è un buon tool diagnostico che mi indica lo stato (la configurazione) di tutte le interfacce di rete correntemente attive nel sistema(se lo forziamo con -a indica anche quelle innative). Se invece diamo p.e. ifconfig eth1 ci da informazioni solo per quella interfaccia:
- Il valore del campo metric viene usato da molti OS per calcolare il costo di una route ma prima Linux non lo usava anche se lo riportava solo per compatibilità.
- I campi RX e TX indicano quanti pacchetti(In un altra line ci sono pure i bytes) senza errori sono stati trasmessi o ricevuti , quanti errori sono occorsi, quanti pacchetti sono stati scartati (probabilmente a causa di poca memoria RAM), quanti pacchetti son persi a causa di un overrun (L' overrun sul ricevente sovente si ha quando i pacchetti arrivano più velocemente di quanto il kernel possa servire l'ultimo interrupt).
- I valori dei flag (UP BROADCAST RUNNING MULTICAST POINTOPOINT NOARP ALLMULTI ecc.) riportati da ifconfig il più delle volte non corrispondono ai nomi delle opzioni che diamo alla linea di comando.
- ifconfig con parametri invece può modificare l' interfaccia (In molti casi questa forma del comando è sufficiente per attivare l' interfaccia)
harrykar@harrysas:~$ ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:04:4b:18:ec:df inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::204:4bff:fe18:ecdf/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4603962 errors:0 dropped:0 overruns:0 frame:0 TX packets:3859020 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:3281281730 (3.2 GB) TX bytes:3137925457 (3.1 GB) Interrupt:253 Base address:0xa000
Le opzioni che servono per attivare una caratteristica sono le stesse per disattivarla precedendola con "-". Le sue opzioni più importanti sono:
- up address— Attiva(o riattiva se precedentemente temporaneamente disattivata ) un interfaccia rendendola accessibile al IP layer e associa l' indirizzo IP specificato con questa interfaccia. Se non specifichiamo una opzione netmask, ifconfig di default assegna una netmask basata sulla classe dell' indirizzo. In qualche caso si può omettere la keyword up; ifconfig address di default assume che l' opzione sia up se diamo solo un nome di interfaccia ed un indirizzo IP. Quest' opzione è importantissima in quanto un computer la usa per determinare come indirizzare i pacchetti in uscita, se facciamo un errore di battitura qui il risultato sarà che molti computers diventeranno inaccessibili. Quest' opzione corrisponde ai flag UP e RUNNING
- down— E' opposta all' up; disattiva l' interfaccia rendendola inaccessibile al IP layer disabilitando cosi tutto il traffico IP attraverso l' interfaccia. Inoltre cancella automaticamente tutte le routing entries che usano tale iinterfaccia.
- netmask nm— assegna la network mask che deve esere usata dall' interfaccia, ossia determina quanti bits dell' indirizzo IP corrispondono al network address e quanti identificano un specifico computer (node number) su una rete. Se omettiamo tale opzione, ifconfig setta la netmask ad un valore di default come su riportato. Possiamo fornire la netmask come il numero di bits dell' indirizzo di rete anche dentro l' opzione up come abbiamo detto poch'anzi; la notazione più compatta può essere p.e.172.23.45.67/24 al posto della 172.23.45.67 con netmask 255.255.255.0 oppure meglio in esdecimale(hex: 255=FF) 0xFFFFFF0 che le è equivalente.
- pointopoint address— si usa per collegamenti(links) punto-punto (point-to-point) per configurare interfacce SLIP o PLIP. Se è stato configurato un indirizzo point-to-point l' output di ifconfig mostra il flag POINTOPOINT
- broadcast address— Si ottiene di solito dal network number settando a 1 tutti i bits della sua parte host. Molte implementazioni(come i sistemi derivati da BSD 4.2) usano invece lo schema opposto settando tutti i bits della host part pari a 0. L' opzione broadcast pone rimedio a questi ambienti strani. Se viene configurata un indirizzo broadcast ifconfig mostra il flag BROADCAST
- irq— si usa per configurare la linea IRQ specialmente per dispositivi PLIP ma può essere utile anche per certe schede Ethernet.
- metric number—opzione usata per assegnare un valore per la metrica alla routing table entry creata per l'interfaccia. Questa metrica è usata dal Routing Information Protocol (RIP) per generare routing tables per la rete (RIP sceglie il percorso ottimo per un dato host basandosi sulla "lunghezza" del percorso che calcola sommando tutti i valori del campo metric per ogni link host-to-host. Per default un hop ha lunghezza 1 ma può essere ogni intero positivo ;la default metric usata da ifconfig e zero. Se non eseguiamo un RIP daemon, non abbiamo bisogno di questa opzione; Se invece lo eseguiamo raramente avremo bisogno di cambiare il valore della metrica.
- [-]promisc— Normalmente, una scheda di rete accetta o solo quei pacchetti che sono diretti verso di essa, o quelli verso tutti i sistemi nel suo segmento di rete. Quest' opzione attiva (promisc) o disattiva (-promisc) promiscuous mode, nel quale la scheda di rete legge tutti i pacchetti che attraversano il suo segmento di rete locale. Promiscuous mode è neccessario per packet sniffers(tcpdump), i quali si usano come tools diagnostici di rete (analisi di traffico usando packet filters conosciuto anche come Ethernet snooping). (I crackers usano pure i packet sniffers invece per acquisire passwords che viaggiano senza criptazione nella rete. Si può evitare ciò impedendo la connessione dei loro PC alla LAN o con la crittografia e l' uso di protocolli sicuri di autenticazione come Kerberos o la suite openssh) Inoltre molti programmi autonomamente possono pure abilitare il promiscuous mode. Il default è di attivare una interfaccia in non promiscuous mode. Il flag corrispondente è PROMISC
- mtu bytes— configura la Maximum Transmission Unit (che è il massimo numero di ottetti per transizione che l' interfaccia è capace di gestire) su una interfaccia. Per le Ethernet, la default MTU è 1,500 (che per specifica è la max dimensione che può avere un pacchetto Ethernet) ma può assumere qualsiasi valore; per interfacce SLIP invece 296 è un buon compromesso. Molti routers e protocolli fanno uso di MTU più piccole, il che può degradare le performance se nel nostro sistema l'MTU viene settata ad un valore più alto, perché i nostri grandi pacchetti devono prima essere frammentati in più pacchetti e poi essere inviati. Inoltre anziché un operazione di un solo invio di un grande pacchetto avrà luogo un operazione di tanti invii di tanti pacchetti più piccoli.Tutto ciò ovviamente porta overhead.
- [-]arp— E' un opzione specifica per broadcast networks (p.e. Ethernets) o per packet radio. Abilita l'uso di Address Resolution Protocol (ARP) per la rivelazione di indirizzi fisici(MAc's) di hosts connessi al network. Per broadcast networks è attivata per defaul. Se ARP è disabilitato ifconfig ci fa vedere il flag NOARP. -arp disabilita l' uso di ARP in una data interfaccia
- [-]allmulti— Gli indirizzi Multicast sono come gli indirizzi broadcast in Ethernet, eccetto che anzichè includere automaticamente tutti gli host i soli host che ricevono pacchetti con indirizzi multicast sono quelli programmati per tenersi in loro ascolto. Questo è utile per applicazioni tipo Ethernet-based videoconferencing o network audio, in cui solo gli host interessati possono riceverli. Il Multicast addressing è supportato da molti ma non tutti i drivers Ethernet. Quando è abilitato il Multicast l' interfaccia riceve e passa pacchetti multicast per ulteriore processamento. Il flag corrispondente è ALLMULTI.
- del address/prefixlength— E' l' opzione opposta di add; Essa togli un indirizzo IPv6 dall' interfaccia.
- media type— Molte network cards includono due o più media connectors (p.e. connettori per 10Base-2 e 10Base-T cabling). Con questa opzione possiamo specificare quale connettore vogliamo usare.
- hw class address— Ci permette di controllare l' indirizzo hardware della scheda di rete. E' utile p.e. quando noi rimpiazziamo una network card con un' altra ma vogliamo usare il vecchio indirizzo hardware per continuare a ricevere lo stesso indirizzo IP da un server DHCP. Inoltre i costruttori di schede di rete occasionalmente distribuiscono un gran numero di esse con identici indirizzi hardware il che può portare problemi se ci capita di usare almeno due schede di uno stesso lotto sulla stessa rete. Quest' opzione richiede due sottopzioni: la classe del dispositivo di rete (come ether per Ethernet o ARCnet per ARCnet) e l' indirizzo hardware (MAC). Questa funzione non si applica per tutte le network cards.
- txqueulen length— imposta la lunghezza della coda di trasmissione, che è il numero di pacchetti che l'interfaccia tenta di accodare prima di spedirli. Il valore di default (che normalmente funziona bene) per dispositivi Ethernet è 1000. settare una più bassa txqueulen su connessioni lente può migliorare le performance interattive (cosi si ottiene una migliore performance interattiva per una sessione Telnet o SSH).
Normalmente i commandi per configurare l' interfaccia di rete e inizializzare la tabella di instradamento si fanno da un script di inizializzazione di rete ogniqualvolta facciamo il boot del sistema.
Classi di indirizzi IP
Classi di indirizzi IP
Il NIC non assegna indirizzi host per host ma assegna un range (ricodriamoci che l' indirizzo IP si suddivide in un network number, contenuto negli otteti iniziali, ed un host number,che è la parte rimanente) e noi dobbiamo assegnare (a nostro piacimento) gli indirizzi IP validi contenuti in tale range ai host della nostra rete. La dimensione della parte host del network number dipende dalla dimensione della nostra rete. Per accomodare le esigenze più disparate e di conseguenza per poter suddividere in modo diverso gli indirizzi IP sono nate le classi di reti.
Class--Class Address Range--Private Address Range--Netmask
A---1.0.0.0–127.255.255.255---10.0.0.0–10.255.255.255----255.0.0.0
B-128.0.0.0–191.255.255.255--172.16.0.0–172.31.255.255--255.255.0.0
C-192.0.0.0–223.255.255.255--192.168.0.0-192.168.255.255--255.255.255.0
Inoltre ci sono anche le classi D per il multicast (traffico di pacchetti destinato a molti host che aspettano di riceverli, in contemporanea) e la classe E ed F riservata per usi futuri.
Gli indirizzi 224.0.0.0 --- 254.0.0.0 sono o sperimentali o riservati per usi speciali tipo multicast e non devono essere utilizzati per l' indirizzamento normale delle reti
- Nella classe A il network number è contenuto nel primo ottetto fornendo un host number di 24-bit. In altre parole permette 127-1=126 networks aventi ognuno fino a 2^24 = 1.6 milioni di hosts.
- Nella classe B il network number è contenuto nei primi due ottetti fornendo un host number di 16-bit. In altre parole permette 16320 networks aventi ognuno fino a 2^16 = 65024 hosts.
- Nella classe C il network number è contenuto nei primi tre ottetti fornendo un host number di 8-bit. In altre parole permette 2 milioni di networks aventi ognuno fino a 2^8= 254 hosts.
Dentro i range di ottetti validi del host number ci sono dei valori di ottetti speciali non allocabili agli host. Per esempio:
- il valore .0 (tutti i bits del host number sono degli 0 ) si riferisce all' intera rete e non ad un particolare host
- il valore .255 (tutti i bits del host number sono degli 1 ) si riferisce al broadcast address: ossia si riferisce a tutti gli host della rete simultaneamente. Quindi 149.76.255.255 non è un valido indirizzo IP di un particolare host ma si riferisce contemporaneamente a tutti gli host della rete 149.76.0.0
- Oltre agli indirizzi privati (designati alle reti private --intranet o piccole LAN-- e quindi non usate per l'instradamento su Internet) che stanno dentro i range di indirizzi validi ci sono anche gli indirizzi 0.0.0.0 e 127.0.0.0 che sono anch' essi speciali e si riferiscono rispettivamente alla default route e al loopback address.
- 127.0.0.0 viene riservato per traffico IP locale al nostro host. Di solito 127.0.0.1 viene assegnato ad una speciale interfaccia del host chiamata loopback interface che si comporta come un circuito chiuso. Ogni pacchetto IP (TCP o UDP) gestito da tale interfaccia parte da essa e ritorna di nuovo ad essa come se fosse mandato da qualche altra rete. Questo permete di sviluppare e testare software di rete senza usare un network "reale". Il loopback network quindi permette di usare il networking software su un standalone host. Questo serve per esempio nei sites UUCP che non hanno bisogno di connettività IP, ma gli serve eseguire per esempio solo l' INN news system che per operare correttamente richiede appunto la loopback interface.
Malgrado l'assegnazione delle netmask dopo il 1990 in realtà ci sono state parecchie deviazioni rispetto agli standard. Questo è stato causato dallo schema di allocazione iniziale degli indirizzi IP che e' stato molto sbilanciato. Nel senso che conteneva tantissime reti di classe A e pochissime di classe C. Le deviazioni dalle netmask della tabella di sopra si basano sul cosiddetto Classless Inter-Domain Routing (CIDR) --What Is CIDR? Why Do We Need CIDR?--che permette l' assegnazione arbitraria delle netmask ai range degli indirizzi IP. Cosi un ISP può richiedere un po di range di indirizzi di classe C e prendere indirizzi che tradizionalmente apparterrebbero alla classe A come p.e. 10.34.56.0/24 e 10.34.57.0/24. Dividendo in questo modo il parco di indirizzi IP esistenti non si fa altro che estendere ulteriormente questo range di indirizzi rispetto al aderire strettamente al modo rigido di suddivisione a classi. L'aspetto negativo di questo discorso per ciò che riguarda l' admin è che si deve fare molta attenzione quando si specifica la netmask per questi indirizzi. Se lasciamo settare la netmask automaticamente da ifconfig p.e per 10.34.56.78, la netmask verrà settata a 255.0.0.0 il che ovviamente è errato perché probabilmente dovrebbe essere 255.255.255.0.
Configurare interfacce (multiple) di rete
Questi comandi configurano l' interfaccia eth0 sull' indirizzo 192.168.1.1 (presumibilmente per una rete privata locale), ed eth1 su 172.23.45.67, usando una netmask 255.255.255.0. Una volta fatto ciò entrambe le interfacce possono funzionare. Come fa però il computer a conoscere a quale interfaccia deve mandare un pacchetto? p.e. supponiamo che un programma cerca di contattare il computer al indirizzo 10.9.8.7. Su quale interfaccia Linux dovrebbe mandare questo pacchetto? E' compito della routing table di rispondere a questa domanda. In effetti tale domanda è importante anche per un computer a interfaccia singola.
Tuning della Routing Table
La routing table dirige il traffico dei pacchetti in due modi:
Struttura della Routing table
La routing table consiste di una serie di campi che specificano cosa fare per spedire pacchetti verso certi range di indirizzi IP. Quando un programma manda un pacchetto in uscita verso il kernel, il kernel compara l' indirizzo destinazione con i range degli indirizzi di destinazione che si trovano nella routing table, cominciando la comparazione con i range degli indirizzi di destinazione più specifici (ossia, quelli che definiscono le reti più piccole). Se il campo destinazione dei pacchetti coincide con uno di tali range, esso viene spedito per come è specificato dalla regola della routing table. Se invece non coincide,viene esaminata la regola seguente e cosi via. Normalmente, la regola più generale nella routing table conosciuta come default route, coincide con qualsiasi indirizzo destinazione IP. La default route normalmente dirige i pacchetti attraverso il gateway della rete locale. Vediamo un esempio:
Configurare interfacce (multiple) di rete
# ifconfig eth0 up 192.168.1.1 # ifconfig eth1 up 172.23.45.67/24
Questi comandi configurano l' interfaccia eth0 sull' indirizzo 192.168.1.1 (presumibilmente per una rete privata locale), ed eth1 su 172.23.45.67, usando una netmask 255.255.255.0. Una volta fatto ciò entrambe le interfacce possono funzionare. Come fa però il computer a conoscere a quale interfaccia deve mandare un pacchetto? p.e. supponiamo che un programma cerca di contattare il computer al indirizzo 10.9.8.7. Su quale interfaccia Linux dovrebbe mandare questo pacchetto? E' compito della routing table di rispondere a questa domanda. In effetti tale domanda è importante anche per un computer a interfaccia singola.
Tuning della Routing Table
La routing table dirige il traffico dei pacchetti in due modi:
- Essa dice a Linux su quale interfaccia mandare il traffico. Questo può sembrare ovvio in un computer a interfaccia singola, ma non dimentichiamo che Linux supporta anche una speciale interfaccia virtuale conosciuta come localhost o loopback interface. Questa interfaccia usa la rete 127.0.0.0/8, ma e' di solito indirizzata usando solo uno indirizzo IP : 127.0.0.1. Siccome tale interfaccia esiste su tutti i computers, può essere usata dai programmi quando loro abbisognano di usare protocolli di rete per interfacciarsi verso altri programmi locali. Inoltre e' anche molto più veloce rispetto all' uso di interfacce di rete fisiche (hardware) del computer. Devono esistere delle regole per dirigere propriamente il traffico verso l'interfaccia localhost o verso l' interfaccia fisica (o verso una particolare interfaccia fisica, se un computer ne ha più di una).
- Il secondo compito della routing table è di dirigere il traffico che è indirizzato verso altri computer sul network locale, in contrapposizione che verso computers situati su networks remoti che ad ogni caso deve essere instradato(routed). Nel caso del traffico sulla rete locale , Linux può usare il protocollo Address Resolution Protocol (ARP) per comunicare direttamente col sistema destinazione, ma i sistemi remoti abbisognano della gestione da parte di un sistema router o gateway—in pratica un computer che passa pacchetti da un network ad un altro. In molti sistemi Linux la routing table riporta solamente un computer gateway , ma configurazioni più sofisticate usano più gateways. Per configurare la routing table usiamo il commando route.
NOTA: Il path (percorso) fra due computers arbitrari su Internet tipicamente include una dozina o più di routers, ma il nostro computer abbisogna di conoscere solo l' indirizzo del primo di essi, e l' indirizzo del host di destinazione. Il primo router poi sa come raggiungere il prossimo, e cosi via finchè non viene raggiunto il computer contraddistinto dall' indirizzo IP della destinazione finale.
Il commando route ci permette di aggiungere o rimuovere delle routes dalla routing table del kernel:
Il commando route ci permette di aggiungere o rimuovere delle routes dalla routing table del kernel:
# route [add|del] [-net|-host] target [if]
Gli argomenti:
Struttura della Routing table
La routing table consiste di una serie di campi che specificano cosa fare per spedire pacchetti verso certi range di indirizzi IP. Quando un programma manda un pacchetto in uscita verso il kernel, il kernel compara l' indirizzo destinazione con i range degli indirizzi di destinazione che si trovano nella routing table, cominciando la comparazione con i range degli indirizzi di destinazione più specifici (ossia, quelli che definiscono le reti più piccole). Se il campo destinazione dei pacchetti coincide con uno di tali range, esso viene spedito per come è specificato dalla regola della routing table. Se invece non coincide,viene esaminata la regola seguente e cosi via. Normalmente, la regola più generale nella routing table conosciuta come default route, coincide con qualsiasi indirizzo destinazione IP. La default route normalmente dirige i pacchetti attraverso il gateway della rete locale. Vediamo un esempio:
harrykar@harrykar-desktop:~$ route
Kernel IP routing table
Destination-----Gateway-----------Genmask------- Flags--Metric-- Ref--Use-------Iface
192.168.1.0---------*-------------255.255.255.0---U-------0--------0----0-------eth0
default------192.168.1.1-------0.0.0.0-------UG------0--------0----0-------eth0
o in versione numerica:harrykar@harrykar-desktop:~$ route -n
Destination---------Gateway------------Genmask------------Flags-- Metric--------Ref-----Use---Iface
192.168.1.0--------0.0.0.0-----------255.255.255.0------- U----------0---------0-------0------eth0
0.0.0.0----------192.168.1.1----------0.0.0.0-------------UG----------0---------0-------0------eth0
Osserviamo che le entries nella routing table vanno dal net più specifico a quello meno specifico.
- La prima enrty (linea) per destianzione 192.168.1.0, rapresenta il traffico nella rete locale (come sappiamo gli indirizzi di rete terminano con 0) per reti che hanno netmask 255.255.255.0. Gateway: 0.0.0.0 oppure * vuol dire che il gateway non prende parte (non viene coinvolto) nel traffico locale. Iface:eth0 vuol dire che il traffico si svolge sull' interfaccia eth0. Un computer con una sola interfaccia di rete avrebbe solo questa entry.
- La seconda e ultima entry (nello specifico esempio) per una destinazione 0.0.0.0, è la default route. Quest'indirizzo insieme alla netmask 0.0.0.0, vuol dire ogni IP da ogni rete. Ossia rivela ogni traffico che non è stato ancora rivelato. Il Gateway: 192.168.1.1 vuol dire che in questo caso il gateway e' coinvolto nel traffico.
- Eventualmente ci potrebbe essere un ulteriore entry con Destination: 255.255.255.255 che e' l'indirizzo speciale per i broadcast
Quando attiviamo un' interfaccia con con ifconfig tale utility immette automaticamente nella routing table una entry (che corrisponderà alla local network route per l' interfaccia, cioè alla route con netmask 255.255.255.0) per l' interfaccia. I default startup scripts di Linux automaticamente immettono la entry per l' interfaccia localhost. Un' eventuale entry per i broadcast (255.255.255.255) non e' neccessaria su molti sistemi, anche se molte utility possono far uso di tale entry. Per un normale funzionamento, quella che invece è necessaria è la entry per la default route.
route Sintassi ed Uso basilare
Come buona parte di commandi se usato senza parametri e' solo informativo ma se usato con parametri può modificare la routing table:
route Sintassi ed Uso basilare
Come buona parte di commandi se usato senza parametri e' solo informativo ma se usato con parametri può modificare la routing table:
route add | del [-net | -host] target [netmask nm] [gateway gw][metric m] [mss m] [window W] [[dev] interface]
- add | del— Per immettere una route, o eliminarla. In ogni caso si devono avere delle informazioni sulla route prima di agire con questi comandi
- [-net | -host]— Possiamo specificare un indirizzo di un singolo computer (-host) o di una intera rete (-net) come target del comando. In molti casi, route può trovare tutto ciò di per se, ma qualche volta aspetterà che lo specifichiamo noi. Questa seconda vale in particolare quando dobbiamo immettere una route per un secondo gateway (come un gateway che gestisce solo una piccola subnet, anzichè il gateway delle default routes )
- target— L' indirizzo target è il computer o network i cui pacchetti devono essere definiti dalla route. Nel caso della default route, esso dovrebbe essere 0.0.0.0, o la keyword equivalente, default. Questo parametro viene richiesto quando noi immettiamo o cancelliamo una route.
- [netmask nm]— se il nostro network target segue la tradizionale struttura a classi per gli indirizzi di rete, Linux può determinare automaticamente quale dovrebbe essere la sua netmask. Se invece il nostro network non segue questo schema di indirizzamento, dobbiamo esplicitamente includere il parametro netmask nm. (Possiamo anche usare la forma ridotta IP/numero bit)
- [gateway gw]— Se immettiamo una route in cui non è coinvolto nessun gateway, possiamo benissimo fare a meno di questo parametro che ovviamente serve quando c'è un gateway nella route. Possiamo usarlo per definire il default gateway o ogni altro sistema che fa da gateway.
- [metric m]— La collona Metric dell' precedente esempio mostra la metrica di routing per ogni particolare route—si può pensare come una stima di "costo" della consegna dei pacchetti, il quale normalmente e' assocciato col tempo. Le routes lente dovrebbero avere alte metriche, imvece le routes veloci dovrebbero avere basse metriche. Possiamo settare questa feature col parametro metric m . Questa feature normalmente è soltanto usata sui router.
- [mss m]— Quest' opzione setta la Maximum Segment Size (MSS). Come la metric m questa option riguarda primariamente i routers.
- [window W]— The TCP Window Size è l' ammontare di dati che un computer può mandare prima di richiedere un acknowledgment dal computer ricevente. Se impostiamo troppo piccolo questo valore , i tresferimenti nella rete possono diventare più lenti perchè il sistema può finire di aspettare troppo per acknowledgments prima di mandare nuovi dati. Se invece lo settiamo troppo alto, corriamo il rischio di ri-mandare un saccco di dati nel caso di un errore del sistema ricevente. Fra questi due casi estremi come regola generale, il settaggio di default (accettabile) di Linux per TCP Window size è di 64KB. Se il nostro sistema usa una connessione veloce ma ha latenza molto alta, come in una connessione broadband satellitare, possiamo aumetare questo valore a 128KB o giù di li.
- [[dev] interface]— Normalmente, Linux può capire quale interfaccia usare per l' indirizzo IP destinazione o quello del sistema gateway. qualche volta però falisce, e in tal caso noi possiamo forzarlo usando il parametro dell' interfaccia [dev]. (La keyword dev è opzionale, ed interface è il nome dell' interfaccia, come eth0 o tr1)
Solitamente si usa route per immettere la default route dopo aver messo a posto l' interfaccia primaria di rete usando ifconfig:
NOTE:
Interfaccia Ethernet
Configurare il DNS
Molti protocolli TCP/IP richiedono che i computers identifichino loro stessi l' uno verso l' altro per nome. Le applicazioni di rete aspettano che noi scegliamo un nome per il host locale. Solitamente tale settaggio si fa durante la procedura di boot. Per semplificare la configurazione dei programmi individuali, Linux mantiene un settaggio globale sui hostnames. Tale configurazione può essere consultata o cambiata col comando hostname:
Il comando netstat
netstat è un utile strumento (in realtà è un insieme di strumenti messi assieme) di controllo delle attività e di configurazione della rete.
Visualizzare la Routing Table
Allo stesso modo di route per il host dell' esempio vstout netstat produce:
# route add 0.0.0.0 gw 10.92.68.1
Se vogliamo possiamo sostituire la keyword default con 0.0.0.0; Raramente capita di usare la specificazione -net , device name, o altre options.
Interfacce Multiple ed un Gateway
Sappiamo già che ogni qualvolta immettiamo un interfaccia con ifconfig, l' utility immette una entry alla nostra routing table per tale interfaccia. Questo sfortunatamente non vale anche per un gateway. Quindi la configurazione richiesta su computers che hanno interfacce multiple consiste in due tipi di intervento:
- Eseguire ifconfig per ogni interfaccia del computer.
- Eseguire route una volta per immettere la default route nella routing table.
Questi due passi sono adeguati per un piccolo router, come un computer Linux che funziona come un router per un piccolo dipartimento all'interno di una grande organizzazione. Per un router, dobbiamo abilitare pure il routing abilitando l' IP forwarding attraverso il commando:
# echo "1" > /proc/sys/net/ipv4/ip_forward
NOTE:
- Se il computer ha due interfacce ma non deve lavorare come router, non dobbiamo abilitare l' IP forwarding. p.e. se un computer esiste in due reti che non devono comunicare l' una con l' altra, o se il host usa qualche altro computer come router.
- Solitamente le funzioni di routing non devono essere espletate da un computer che fa anche un altro lavoro. In questo caso il lavoro non-routing ovviamente consuma tempo CPU e bandwidth che sicuramente degraderebbero le performance del router. Inoltre ci sarebbero anche potenziali problemi di sicurezza; I routers di oggi spesso includono anche un firewall, ed eseguire software non strettamente necessario su un firewall non è affatto una buona idea perché lascia un fianco aperto agli attacchi.
Interfacce Multiple con Gateways Multipli
Questo tipo di configurazione in cui un computer può usare più gateways è più complessa della precedente. La maggior parte di sistemi usa un solo gateway, il quale è associato con la default route. Il gateway come sappiamo unisce la rete locale con altre reti, e (oggi quasi esclusivamente) all' Internet.
Consideriamo adesso un ambiente nel quale una organizazione ha due subnetworks (ufficio1, ufficio2) connesse via routers.
la Loopback Interface
La primissima interfaccia da essere attivata è la loopback interface:
Questo tipo di configurazione in cui un computer può usare più gateways è più complessa della precedente. La maggior parte di sistemi usa un solo gateway, il quale è associato con la default route. Il gateway come sappiamo unisce la rete locale con altre reti, e (oggi quasi esclusivamente) all' Internet.
Consideriamo adesso un ambiente nel quale una organizazione ha due subnetworks (ufficio1, ufficio2) connesse via routers.- I computers in entrambi gli uffici possono essere configurati facilmente —loro abbisognano solo di puntare verso i loro routers locali che per loro rappresentano i loro gateways.
- Inoltre, il router in ufficio 2 può puntare verso il router in ufficio 1 come suo gateway system, amesso che il router del ufficio 2 ha due interfacce. Una verso la sua LAN e un altra verso il router del ufficio 2.
- Il router in ufficio 1, però, richiede una configurazione più complessa. La sua default route punta a Internet, ma in esso deve anche essere configurata una route verso il router dell' ufficio 2 per il traffico indirizzato verso la rete 172.20.0.0/16. Si deve usare il commando route per ottemperare a tale scopo:
# route add -net 172.20.0.0 netmask 255.255.0.0 gw 172.21.1.1
NOTA----Una configurazione come quella sopra è appropriata quando ufficio 1 ed ufficio 2 sono separati geograficamente (da una WAN) e sono poi collegati con qualche protocollo di rete long-distance. E' ovvio che se gli uffici fossero vicini, si potrebbero collegare in un singolo hub o switch ed essere serviti da un singolo router.
- Questo commando assume che il router dell' ufficio 2 communica col suo omologo del ufficio 1 usando l' indirizzo 172.21.1.1. (Nota che quest' indirizzo non fa propriamente parte della rete del ufficio 2; contraddistingue invece una distinta network card del router in ufficio 2 da parte del ufficio 1)
- Il risultato di tale commando come pure del comando per la normal route per definire la default route porta ad una routing table che include due gateways: uno per la default route ed uno per dirigere il traffico indirizzato ai sistemi dell' ufficio 2. A nessuno dei computers che si collegano al router dell' ufficio 1 interesserà tutto questo che abbiamo finora detto; Loro devono solo sapere che questo router 1 è il gateway per la default route.
- Ci sono anche altre situazioni in cui la suddetta configurazione potrebbe essere richiesta. p.e. se l' ufficio 1 usa un secondo router per connettersi all' Internet, tutti i computers nel ufficio 1 abbisognerebbero la definizione di due gateways: uno per la default route che punta al sistema che porta verso Internet, ed una seconda route che punta verso il router che porta verso l' ufficio 2. (In alternativa, i normali sistemi dovrebbero riportare un solo router, il quale passa il traffico verso l'altro router quando abbisogna, ma questo incrementerà il traffico nella rete locale.)
Dal momento che una rete con due routers implica anche una configurazione piuttosto complessa per tutti i computers della rete, è sempre meglio (quando possibile) usare un singolo router su ogni subnet.
la Loopback Interface
La primissima interfaccia da essere attivata è la loopback interface:
# ifconfig lo 127.0.0.1
Occasionamente, possiamo vedere il dummy hostname localhost anzichè l' IP address. ifconfig guarda il nome dal file hosts, ove una linea dovrebbe dichiararlo come hostname per 127.0.0.1:
# Sample /etc/hosts entry for localhost localhost 127.0.0.1
Per esaminare la configurazione di una interfaccia, si può invocare ifconfig, dandogli come argomento il nome d' interfaccia :
harrykar@harrysas:~$ ifconfig lo lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:519 errors:0 dropped:0 overruns:0 frame:0 TX packets:519 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:86326 (86.3 KB) TX bytes:86326 (86.3 KB)
Come si può notare alla loopback interface è stata assegnata una netmask of 255.0.0.0, dal momento che 127.0.0.1è un indirizzo di classe A. Manca una entry nella routing table (che indica quale IP può usare questa interfaccia come route verso la destinazione 127.0.0.1) e si può cominciare a giocare col nostro mini-network.
# route add 127.0.0.1
Adesso si può usare localhost anzichè l' ordinario IP address, ammesso che se l'abbia inserito anche in /etc/hosts. Si può testare se il tutto funziona a dovere usando ping.
Ping nel networking è l' equivalente di un dispositivo sonar. Si usa per verificare che un dato indirizzo IP è attualmente raggiungibile e per misurare il delay (ritardo) che intercorre fra il momento di emmissione del test datagram e il momento che la risposta ad esso ritorna indietro. Tale tempo è anche noto come "round-trip time":
harrykar@harrysas:~$ ping localhost PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 ttl=64 time=0.027 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=2 ttl=64 time=0.027 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=3 ttl=64 time=0.035 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=4 ttl=64 time=0.034 ms 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=5 ttl=64 time=0.034 ms ^C --- localhost.localdomain ping statistics --- 5 packets transmitted, 5 received, 0% packet loss, time 3998ms rtt(round-trip time) min/avg/max/mdev = 0.027/0.031/0.035/0.006 ms
- l CTRL-C(^C) serve per fermare l' emmissione infinita dei pacchetti.
- I risultati della penultima riga indicano che l' interfaccia lo e' stata configurata perfettamente. Ogni altra schermata differente indicherebbe la presenza di problemi. In tal caso controlliamo:
- se i binari di ifconfig e route sono compatibili con la release del nostro kernel
- che il kernel è stato compilato col supporto al networking attivato(se c'è la directory /proc/net siamo a posto)
- se si ottiene "Network unreachable," probabilmente c' èqualcosa che non va col comando route assicuriamoci di usare lo stesso indirizzo che ci indica ifconfig
Dopo aver aggiunto tutte le linee necessarie al script di inizializzazione di rete ed essere assicurati che esso si esegua a boot time, possiamo fare il boot e usare diverse applicazioni:
#telnet localhost
dovrebbe stabilire una connessione telnet dandoci un prompt di login: Non scordiamoci che la loopback interface oltre ad essere usata per testing e debugging è neccessaria affinchè molte applicazioni possano funzionare per cui noi la dobbiamo sempre configurare che fossimo attaccati ad una rete o no.
Per esempio tutte le applicazioni basate su RPC usano la loopback interface per autoregistrarsi col daemon portmapper in fase di startup. Tali applicazioni includono NIS e NFS.
Interfaccia Ethernet
La sua configurazione è molto simile a quella della loopback interface; richiede qualche parametro in più quando si attua il subnetting.
Nel esempio di rete Virtual Brewery, abbiamo fatto il subnetting dell' IP network, che originariamente era un network di classe B, e dopo il subnetting diventarono subnetworks di classe C. Per far si che l' interfaccia le riconosca diamo:
Nel esempio di rete Virtual Brewery, abbiamo fatto il subnetting dell' IP network, che originariamente era un network di classe B, e dopo il subnetting diventarono subnetworks di classe C. Per far si che l' interfaccia le riconosca diamo:
# ifconfig eth0 vstout netmask 255.255.255.0
ifconfig assegna all' interfaccia eth0 l' indirizzo IP address di vstout (172.16.1.2). Se ommetessimo la netmask, ifconfig la dedurebbe (di default e in modo sbagliato nel nostro caso che sarebbe 255.255.0.0). Controlliamo:
# ifconfig eth0 eth0 Link encap 10Mps Ethernet HWaddr 00:00:C0:90:B3:42 inet addr 172.16.1.2 Bcast 172.16.1.255 Mask 255.255.255.0 UP BROADCAST RUNNING MTU 1500 Metric 1 RX packets 0 errors 0 dropped 0 overrun 0 TX packets 0 errors 0 dropped 0 overrun 0
- Osserviamo che ifconfig automaticamente configura l' indirizzo broadcast(campo Bcast) al valore corretto, che è il network number del host con tutti i bits host 1.
- Inoltre, la maximum transmission unit (la dimensione max dei datagrams che il kernel può generare per tale interfaccia) è stata configurata pari alla dimensione max dei pacchetti Ethernet: 1500 bytes.
# route add -net 172.16.1.0
- A prima vista non è chiaro come route rileva quale interfaccia deve attraversare. Semplicemente il kernel controlla tutte le interfacce che sono state configurate e compara l' indirizzo destinazione (172.16.1.0 nel nostro caso) con la network part del interface address (facendo un bitwise AND fra interface address e netmask). L' unica interfaccia che trova è eth0.
- L' opzione -net si usa perchè route si occupa sia di routes verso reti sia di routes verso singoli hosts (come feccimo prima con localhost). Quando guarda un indirizzo x.x.x.x, route cerca di capire se è un network o un hostname guardando ai bits della parte host. Se essa è zero, route assume che è un network; altrimenti, route lo considera come host address. Quindi nel esempio, route assumerebbe che 172.16.1.0 è un host address anzichè un network number, perchè route non potrebbe conoscere che noi usiamo il subnetting. Dobbiamo perciò dichiarare al route esplicitamenteche si tratta di un network, attraverso il -net flag. Per tutto ciò il commando route porta un po di confusione.
# route add brew-net
Con questo abbiamo finito la configurazione base e possiamo controllare se il tutto funziona. Scegliamo un host nell' Ethernet, per esempio vlager, e diamo:
# ping vlager PING vlager: 64 byte packets 64 bytes from 172.16.1.1: icmp_seq=0. time=11. ms 64 bytes from 172.16.1.1: icmp_seq=1. time=7. ms 64 bytes from 172.16.1.1: icmp_seq=2. time=12. ms 64 bytes from 172.16.1.1: icmp_seq=3. time=3. ms ^C ----vstout.vbrew.com PING Statistics---- 4 packets transmitted, 4 packets received, 0 round-trip (ms) min/avg/max = 3/8/12Come per loopback se non vediamo questa schermata qualcosa è andato storto.
- se abbiamo perdita di pacchetti, probabilmente abbiamo un problema hardware
- se non riceviamo nessun reply, dobbiamo controllare la configurazione dell' interfaccia con netstat
- Dalle statistiche dei pacchetti possiamo controllare l' emmissione dei pacchetti dall' interfaccia. Se possiamo accedere anche al host remoto possiamo controllare anche su di esso le statistiche di interfaccia potendo cosi più facilmente determinare dove esattamente c'è la perdita dei pacchetti
Possiamo controllare le informazioni di routing con route per vedere se ambedue i hosts hanno le entry corrette:
# route -n Kernel routing table Destination Gateway Genmask Flags Metric Ref Use Iface 127.0.0.1 * 255.255.255.255 UH 1 0 112 lo 172.16.1.0 * 255.255.255.0 U 1 0 10 eth0I flags attivati per ogni interfaccia vogliono dire:
- U è sempre settato per interfacce attivate
- H dice che l' indirizzo destinazione denota un host. Se il flag H viene setato per un route che intendiamo come network route, dobbiamo ridare il comando route con l' opzione -net
- Per controllare se un route viene usato o no, controlliamo il campo Use per vedere se esso incrementa fra due invocazioni di ping
Configurare il DNS
Una volta che abbiamo attivato l' interfaccia e settato un gateway. un computer può spedire e ricevere traffico di rete verso ogni nodo della sua LAN o verso ogni altra rete connessa direttamente o indirettamente (attraverso routers) col gateway. Il traffico viene indirizzato attraveso i' indirizzo IP come ormai sappiamo. E' compito del Domain Name System (DNS) del sistema Linux (di fornire un' interfaccia user-friedly per convertire i nomi con caratteri alfanumerici (come www.google.com) usati da noi persone verso indirizzi IP usati dai computers. --Per inciso il DNS può fare anche la conversione inversa--) Il DNS è un database distribuito nel globo , e per accedere ad esso ogni computer abbisogna di conoscere solo uno indirizzo IP: l' indirizzo di un singolo DNS server. Molte organizzazioni ed ISPs forniscono l' indirizzo di due o tre DNS server. Quando possediamo quest'informazione, la dobbiamo mettere dentro il file di configurazione /etc/resolv.conf.
WARNING---Sebbene la opzione search ci fa risparmiare sulla battitura omettendo la specifica dei nomi di dominio quando si accede alla rete, tale opzione la dobbiamo utilizzare solo di rado.
Setting del Hostname
Tale file può avere fino a tre linee che cominciano con la keyword nameserver e finiscono con l'indirizzo IP di un DNS server. Nel file si può anche specificare il default domain di un sistema Linux (attraverso la keyword domain) ed un numero arbitrario di domini su cui si deve ricercare quando ommettiamo un domain name (p.e. se specifichiamo mail anzichè mail.yahoo.com) usando la keyword search.Vediamo un esempio di editing del file /etc/resolv.conf:
domain primo.com search secondo.com terzo.com nameserver 10.98.17.34 nameserver 172.20.13.109
WARNING---Sebbene la opzione search ci fa risparmiare sulla battitura omettendo la specifica dei nomi di dominio quando si accede alla rete, tale opzione la dobbiamo utilizzare solo di rado.
- Il problema è che due domini possono avere computers con lo stesso nome, e questo è da evitare. p.e. se entrambi secondo.com e terzo.com hanno Web servers chiamati www, un utente che batte www in un Web browser su un computer con l' /etc/resolv. conf suddetto può ottenere un Web server e credere che è il Web server dell' altro dominio.
- Inoltre queste ricerche sono mangiatempo, il che porta ad un rallentamento dei name lookups. Normalmente anche quando specifichiamo un nome completo, il sistema cerca prima nei domini specificati nelle linee con domain e search. p.e. se un utente scrive www.abc.com, con la configurazione suddetta /etc/resolv.conf fa si che il sistema prima cerchi per www.abc.com.primo.com, www.abc.com.secondo.com, e www.abc.com.terzo.com, e solo dopo va alla ricerca di www.abc.com. Per far si che il sistema cerchi per primo il dominio di interesse www.abc.com dobbiamo mettere un punto alla fine del nome di dominio, cioè www.abc.com.
Setting del Hostname
Molti protocolli TCP/IP richiedono che i computers identifichino loro stessi l' uno verso l' altro per nome. Le applicazioni di rete aspettano che noi scegliamo un nome per il host locale. Solitamente tale settaggio si fa durante la procedura di boot. Per semplificare la configurazione dei programmi individuali, Linux mantiene un settaggio globale sui hostnames. Tale configurazione può essere consultata o cambiata col comando hostname:
- senza nessun parametro mi da il hostname corrente.
- Facendolo invece seguire da un nome imposta il hostname al nome da noi specificato.
# hostname harrykar-desktop.primo.com
- Possiamo anche memmorizzare il hostname in un file e passare tale file al comando hostname col opzione -F o --file, come in:
#hostname -f /etc/HOSTNAME
- Molte distribuzioni operano cosi automaticamente a boot time, anche se la locazione del hostname varia da una distro all' altra. In Ubuntu risiede in /etc/hostname
Sebbene l' ottimo sarebbe settare il hostname una sola volta sfortunatamente ciò non è sempre possibile. Molti programmi user-level—in particolare e-mail clients e Usenet news readers—permettono agli utenti di scavalcare il settaggio di default del hostname. Allora noi o i nostri utenti possono abbisognare di settare il hostname in tali programi, in particolare se non abbiamo mai cambiato il hostname.
Siccome il hostname locale si usa spesso per trovare l' indirizzo IP del host dobbiamo assicurarci che la resolver library sia capace di esaminare l' IP del host. Ossia solitamente si dovrebbe settare il hostname anche in /etc/hosts. Questo file di configurazione file esiste come un metodo alternativo al DNS per la risoluzione di nomi. Esso consiste di linee che iniziano con un indirizzo Ip e continuano con una lista di hostnames
Siccome il hostname locale si usa spesso per trovare l' indirizzo IP del host dobbiamo assicurarci che la resolver library sia capace di esaminare l' IP del host. Ossia solitamente si dovrebbe settare il hostname anche in /etc/hosts. Questo file di configurazione file esiste come un metodo alternativo al DNS per la risoluzione di nomi. Esso consiste di linee che iniziano con un indirizzo Ip e continuano con una lista di hostnames
Comunemente, il primo hostname è un Fully-Qualified Domain Name (FQDN)—che include il nome della macchina e il dominio al quale essa appartiene, come in harrykar-desktop.primo.com. e i hostnames che seguono sulla stessa linea sono dei "nicknames"—normalmente abbreviazioni come harrykar-desktop.
Se le imostazioni DNS nel nostro sistema sono corrette, e se il nostro computer ha campi appropriati nel nostro DNS server di rete, non è neccessario creare un' entry in /etc/hosts per il computer. Se invece i nostri DNS servers della rete, o il network path verso tali servers, sono inaffidabili, creare una entry per il nostro computer in /etc/hosts può solo migliorare l'affidabilità generale.
Inoltre potremmo voler assicurarci che l' indirizzo 127.0.0.1 è rappresentato con i hostnames localhost.localdomain e localhost. p.e.:192.168.1.20 harrykar-desktop.primo.com harrykar-desktop 127.0.0.1 localhost.localdomain localhost
TIP---Se il computer tarda per diversi secondi o anche minuti duante il boot, in particolare quando si avvia Sendmail, ci sono buone probabilità che sia necessario settare entries come su nel nostro file /etc/hosts, o altrimenti è necessario correggere le entries per il nostro computer nel nostro DNS server della rete. Molti programmi, incluso sendmail, si mettono in pausa per lunghi periodi di tempo se non possono assocciare (via DNS, /etc/hosts, o altrimenti) i loro hostnames a indirizzi IP.
Se un computer ha interfacce di rete multiple, possiamo settare un hostname usando il comando hostname , ma normalmente si usa creare hostnames multipli , uno per ogni interfaccia, nel file /etc/hosts , sebbene ciò non sia richiesto. (In questo caso i nostri DNS servers della rete possono normalmente avere anche due o più nomi per il computer.)
TIP---Su una piccola rete privata, possiamo usare /etc/hosts (questo si deve fare per ogni pc nella rete) per gestire tutti i nostri hostnames locali , ovviando cosi al bisogno di eseguire un DNS server solo per pochi computers locali. Questo metodo diventa tedioso quando la rete comincia a crescere di dimensione. Appunto per questa ragione su reti medio-grandi si usa un DNS server centrale.
Il comando netstat
netstat è un utile strumento (in realtà è un insieme di strumenti messi assieme) di controllo delle attività e di configurazione della rete.
Visualizzare la Routing Table
Allo stesso modo di route per il host dell' esempio vstout netstat produce:
# netstat -nr Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 127.0.0.1 * 255.255.255.255 UH 0 0 0 lo 172.16.1.0 * 255.255.255.0 U 0 0 0 eth0 172.16.2.0 172.16.1.1 255.255.255.0 UG 0 0 0 eth0
- L' opzione -n forza netstat di visualizzare indirizzi come numeri IP anzichè nella loro forma simbolica con network names. Questa opzione è utile quando non vogliamo fare lookups (risoluzione nomi) sulla rete(attraverso DNS o NIS servers)
- La colonna Gateway dell' output di netstat indica il gateway verso cui la routing entry punta. Se non si usa un gateway viene indicato un asterisco.
- La colonna Genmask indicaca la "generalità" della route, come la network mask per tale route. Quando dato un IP address si cerca di trovare un buon route, il kernel esamina ogni entry nella routing table, facendo il bitwise AND degli indirizzi con la genmask prima ella comparazione col target della route.
- La colonna Flags indica i flags che descrivono la route:
G: La route usa un gateway.U: L' interfaccia usata è up.H: Solo un singolo host è raggiungibile attraverso la route (come per la loopback entry 127.0.0.1)D: La route è creata dinamicamene. Esso viene settato se la table entry è stata da un routing daemon come gated o da un messaggio ICMP redirect
M: Questo rpute viene impostato se la table entry è stata modificata da un ICMP redirect message
Le prossime 3 collone MSS, Window, irtt si applicano a connessioni TCP stabilite attraverso questa route.!: rappresenta una route reiettata il che vuol dire che i datagrams saranno scartati
- MSS è il Maximum Segment Size. Ossia la dimensione piu grande datagram che il kernel può costruire per trasmettere lungo questa route.
- Window è il max ammontare di dati per volta che il sistema può accettare da un host remoto .
- L' acronimo irtt ("initial round trip time")
Per la maggior parte di tipi di rt il valore di default va bene, ma per qualcun altra tale valore è troppo piccolo (per esempio sulle reti amateur packet radio) causando ritrasmissioni non nesccessarie
Visualizzare le connessioni
Ringraziamenti-Dediche
- Il valore di irtt si può configurare usando il comando route. Se in questi campi c' è il valore zero allora viene usato il valore di default
- L' ultimo campo indica l' interfaccia di rete che una certa route utilizza
Visualizzare le connessioni
Nel nostro esempio invocando netstat -ta su vlager produce il seguente output:
$ netstat -ta Active Internet Connections Proto Recv-Q Send-Q Local Address Foreign Address (State) tcp 0 0 *:domain *:* LISTEN tcp 0 0 *:time *:* LISTEN tcp 0 0 *:smtp *:* LISTEN tcp 0 0 vlager:smtp vstout:1040 ESTABLISHED tcp 0 0 *:telnet *:* LISTEN tcp 0 0 localhost:1046 vbardolino:telnet ESTABLISHED tcp 0 0 *:chargen *:* LISTEN tcp 0 0 *:daytime *:* LISTEN tcp 0 0 *:discard *:* LISTEN tcp 0 0 *:echo *:* LISTEN tcp 0 0 *:shell *:* LISTEN tcp 0 0 *:login *:* LISTEN
notiamo che molti servers sono "in ascolto", nella quarta linea invece notiamo una connessione SMTP in entrata* da vstout, e nella sesta linea una connessione telnet in uscita* verso il host vbardolino.
* possiamo dire che una connessione è in uscita (outgoing) dai numeri di porta. Il numero di porta per il host chiamante (calling host) deve essere sempre un semplice intero. Sul host chiamato, si deve usare una porta di un well-known service per la quale netstat usa il nome simbolico come smtp, che trova in /etc/services.
Il flag -a inoltre visualizza tutti i sockets di tutte le famiglie
Controllare le ARP Tables
In qualche occasione è utile vedere o alterare il contenuto delle tabelle ARP del kernel per esempio quando si sospeta che un indirizzo Internet duplicato è la causa di qualche problema di intermittenza di rete. L' arp tool è stato fatto per situazioni del genere. Le sue opzioni sono:
Controllare le ARP Tables
In qualche occasione è utile vedere o alterare il contenuto delle tabelle ARP del kernel per esempio quando si sospeta che un indirizzo Internet duplicato è la causa di qualche problema di intermittenza di rete. L' arp tool è stato fatto per situazioni del genere. Le sue opzioni sono:
arp [-v] [-t hwtype] -a [hostname] arp [-v] [-t hwtype] -s hostname hwaddr arp [-v] -d hostname [hostname...]
Tutti glia argomenti hostname possono essere o hostnames symbolici o IP addresses x.x.x.x.La prima invocazione visualizza l' ARP entry per l' IP address o host specificato, o tutti i hosts conosciuti se non si da nessun hostname. Nel nostro esempio, invocando arp su vlager avremo:
# arp -a IP address HW type HW address 172.16.1.3 10Mbps Ethernet 00:00:C0:5A:42:C1 172.16.1.2 10Mbps Ethernet 00:00:C0:90:B3:42 172.16.2.4 10Mbps Ethernet 00:00:C0:04:69:AA
- L' opzione -s si usa per aggiungere permanentemente hostnames di indirizzi Ethernet nelle ARP tables. L' argomento hwaddr specifica l' indirizzo hardware che per default si aspetta fosse un indirizzo Ethernet specificato come sei bytes hex separati da : . Possiamo configurare l' indirizzo hardware anche per altri tipi di equipaggiamento usando l' opzione -t.
Le ARP queries(richieste) per il host remoto per qualche ragione talvolta falliscono, per esempio quando il suo ARP driver contiene dei bug o esiste un altro host nella rete che erroneamente identifica se steso in modo identico al host remoto da noi voluto; Per risolvere tale problema dobbiamo manualmente (Hard-wiring IP addresses in the ARP table) immettere un IP address nella ARP table. Questa "manualità" è anche una misura molto drastica per protteggere noi stessi da quelli host sulla Ethernet che vogliono sembrare come fossero altri.
- Invocare arp usando lo switch -d cancella tutte le ARP entries relative a un dato host. Si può usare anche per forzare l' interfaccia di ritentare di ottenere l' Ethernet address per l' IP address in questione. Questo è utile quando un sistema malconfigurato ha fatto il broadcasting di informazioni ARP sbagliate (ovviamente prima si deve riconfigurare il host malconfigurato)
- L' opzione -s si usa anche per implementare un proxy ARP. Questa è una tecnica speciale attraverso cui un host, diciamo gate, agisce come un gateway verso un altro host chiamato fnord pretendendo che entrambi i suoi indirizzi riferiscono lo stesso host gate. Questo si fa mettendo un' ARP entry per fnord che punta alla propria Ethernet interface. Adesso quando un host manda una ARP query per fnord gate deve ritornare una reply contenente il proprio Ethernet address. Il host chiamante manderà tutti i datagrams verso gate il quale a sua volta li inoltrerà verso fnord. Tutti questi contorsionismi possono diventare necessari quando vogliamo accedere a fnord da un host DOS con implementazione TCP cintenebte bugs che non capisce molto bene il routing. Quando usiamo un proxy ARP, apparirà verso la macchina DOS come se fnord fosse sul subnet locale cosi non deve sapere come instradare attraverso il gateway.
- Un altra applicazione utile di proxy ARP è quando uno dei nostri hosts agisce come gateway verso altri solo temporaneamente (per esempio attraverso una connessione dial-up). In un esempio precedente incontrammo il laptop vlite che fu connesso con vlage attraverso un link PLIP una volta tantum. Ovviamente il tutto funzionerà solo se l' indirizzo del host che deve fare da proxy ARP è sullo stesso IP subnet ove sta il gateway.
vstout fa da proxy ARP per ogni host sulla subnet (172.16.1.0) Brewery , ma mai per un host sulla subnet (172.16.2.0) Winery. L' invocazione corretta per fornire proxy ARP per fnord è (ovvio che l' Ethernet address dato deve essere quello di gate):
# arp -s fnord 00:00:c0:a1:42:e0 pub
L' entry proxy ARP può essere rimossa di nuovo invocando:
Fare le nostre modifiche permanenti
# arp -d fnord
Fare le nostre modifiche permanenti
- Editare i file di configurazione /etc/hosts o /etc/resolv.conf fa si che tali modifiche divengano permanenti finchè tali files non vengano corroti o finchè non reinstalliamo Linux.
- Quando invece eseguiamo ifconfig, route, o hostname per cambiare qualche carateristica del sistema tale modifica è transiente e vale finchè il computer è acceso o finchè non viene sostituita da un' altra azione. Se facciamo reboot le modifiche vengono perse.
- Per farle diventare permanenti dobbiamo editare un qualche startup script o file di configurazione attraverso un text editor o un GUI configuration tool (se la nostra distro lo dispone. Se no per tutte le distro esiste il più che valido Webmin project un Web-based administration tool).
Risorse
- Upgrading and Repairing Networks, Fourth Edition, ISBN: 0-7897-2817-6, Que
- Practical Network Cabling, ISBN: 0-7897-2233-X, Que
- Practical Network Peer Networking, ISBN: 0-7897-2247-X, Que
- Practical Firewalls, ISBN: 0-7897-2416-2, Que
- Advanced Linux Networking, ISBN: 0-201-77423-2, Addison Wesley
- Linux Network Administrator's Guide 2nd Edition(June 2000), by Olaf Kirch & Terry Dawson, ISBN:1-56592-400-2, 506 pages, OReilly
- Internetworking with TCP/IP, by Douglas R. Comer Prentice Hall (three-volume set)
- TCP/IP Network Administration by Craig Hunt, O'Reilly
- Running Linux by Matt Welsh, O'Reilly
Charles Spurgeon's Ethernet web site
Anatomy of the Linux networking stack
What Is CIDR? Why Do We Need CIDR?
Anatomy of the Linux networking stack
What Is CIDR? Why Do We Need CIDR?
Ringraziamenti-Dediche
- Un Grande OS che mi ha servito dal finire degli anni ottanta fino a oggi e che contribuisce a "buscare" il pane quotidiano
- Al esimio Daniele Giacomini http://informaticalibera.net/
No comments:
Post a Comment