Total Pageviews

Search: This Blog, Linked From Here, The Web, My fav sites, My Blogroll

09 April 2009

internetworking Windows-Linux in una rete SMB/CIFS ... ed altro

➪ (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:
  1. 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.
  2. 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).


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
allora ... continuate pure a leggere... ;)

Ruoli del PC

I nostri computer possono adempiere uno dei seguenti ruoli:
  • 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).


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:
  1. 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. 
  2. 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:
  1. Ripassino sul networking
  2. Internet protocols


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)
  • risolve i nomi di host (tipo marco, harrykar ecc.) in indirizzi fisici (MAC) e logici (IP )
  • 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.
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):
# /etc/networks for the Virtual Brewery
brew-net 172.16.1.0
wine-net 172.16.2.0
In ogni caso tale metodo di gestione diventa difficile quando il numero di host aumenta.
    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:
  1. 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.
  2. 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:
  1. 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 ) 
  2. 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.
Microsoft supporta due servizi di risoluzione nomi: WINS e DNS

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 :
  1. 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.
  2. 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.

    BootP /DHCP protocol
    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:
    1. la prima parte della netmask 255.255.255 (che si chiama subnet number) e mi identifica l' indirizzo della rete 192.168.1 
    2. 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:
    1. 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.
    2. 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.
    3. 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)


    Link-Local address assignment o APIPA
    1. 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
    2. 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:
      1. Il nostro host chiamato harrykar manda un broadcast al server WINS chiedendo "Può per favore un server WINS dirmi che IP ha il host chiamato harrykar?"
      2. E il server WINS gli da l'info.
        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)
        Nota: Sebbene Microsoft supporta ancora WINS (usando come gestori(server) di rete, Windows XP o Windows 2000 Server) Windows può utilizzare per lo stesso scopo lo standard Internet DNS per la risoluzione nomi.

        DNS
        Domain Name Service è una specie di un DBMS distribuito che fa le seguenti trasformazioni:
        • www.blogger.com/home > 67.215.65.1 (operazione chiamata risoluzione nomi)
        • 67.215.65.1 > www.blogger.com/home (operazione chiamata Inverse DNS)
        Quando noi scriviamo su Explorer  
        \\server.lavoro.com 
        Explorer
          1. cerca prima su WINS e solo se WINS non risponde
          2. entra in scena il DNS per risolvere il nome. Se anche il DNS fallisce allora
          3. 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

        Cos'è il...NetBIOS
        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:
        1. ¹Un servizio nomi (NetBIOS Naming Service NBNS) 
        2. ²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.

        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:
        1. 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
        2. 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?
          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)


          Nomi NetBIOS
          Lo spazio nomi del NetBIOS e' flat (in antitesi con la struttura gerarchica del DNS p.e. www.samba.org ha 3 livelli sottesi).
          1. I nomi dei host (chiamati machine o resource name) sono stringhe (parole) uniche dentro ogni workgroup o dominio e devono essere o dei caratteri alfanumerici (a-z, A-Z, 0-9) oppure ! @ # $ % ^ & ( ) - ' { } . ~
          2. non devono superare i 15 caratteri.
            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
            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  
            (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
            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.
                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:
            • 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.


            Domain(Dominio) Network 
            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:
              1. Il DHCP da al computer il suo IP address e l 'indirizzo dei DNS servers
              2. il DNS a sua volta localizza l' Active Directory, e
              3. 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
            Windows ci da 2 scelte per ottemperare questo compito :
            1. configurare la rete manualmente
            2. configurare la rete tramite wizard(chiamato Network Setup Wizard)
            Importante: Il Network Setup Wizard lo dobbiamo far eseguire almeno una volta all' inizio perchè  dopo SP2 il win networking e' inizialmente disabilitato per proteggerci dall' Internet hacking. Il Network Setup Wizard abilita infatti la condivisione di file e stampanti dopo essersi prima assicurato che la connessione Internet è sicura. Quindi anche se decidiamo di configurare la rete manualmente è necessario eseguire prima il Network Setup Wizard

            Configurare il protocollo TCP/IP
            Nel assegnare un indirizzo IP ad ogni computer ci sono 3 strade possibili:
            1. 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
            1. Assegnare manualmente un indirizzo IP (in tal caso si chiama IP statico) ad ogni host della rete 
            2. 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
            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:
            runas /user:Administrator "control panel"
            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
                1. 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
                2. 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.
                3. 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:
                  • tasto col segno di win + tasto Pausa/interr per vedere le propr. di sistema
                  • clik sul secondo tab Nome computer e verifichiamo il Gruppo di lavoro che deve essere lo stesso per tutti i host della rete (per cambiarlo dobbiamo avere i privilegi di Administrator)
                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
                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

                • 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
                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
                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:
                1. 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 
                2. 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) 
                3. 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 
                4. 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

                  Se si usano Novell NetWare servers, dobbiamo invece aggiungere:
                  • 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


                  Breve storia 
                  1. Nel 1992 Ross Biro e altri crearono quel che diventò poi noto come Net-1
                  2. 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
                  3. La prima release pubblica , Net-2d, fu fatta nell' estate del 1993 (come parte del Linux kernel 0.99.10), 
                  4. 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
                  5. Il codice di Net-3 fu ulteriormente sviluppato per Linux 1.2 e Linux 2.0. 
                  6. 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
                  In molti casi è necessario ricompilare il kernel per attivare un opzione o disattivare un altra che da problemi sulle prestazioni o sull' affidabilità del sistema.
                      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:
                  1. Il loro codice gira molto più veloce che se fosse in user-level
                  2. 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 LibraryNei 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.

                  Configurazione di rete TCP/IP
                  Si fa attraverso 3 metodi:
                  • Dynamic Host Configuration Protocol (DHCP)
                  • Static IP addresses
                  • Point-to-Point Protocol (PPP)
                  Prima del loro uso si devono caricare gli appropriati network drivers.

                  Caricare i Network Drivers
                  imagePer 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:
                  1. ha difficolta di rilevare le schede a bassissimo costo(che non rispettano gli standards) 
                  2. 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
                  3. 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).
                    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 primario
                    Abbiamo 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 è:
                    • 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 
                    Al posto in cui normalmente si vede la dimensione del file(appena prima del tempo di ultima modifica del file) vediamo invece 2 numeri chiamati major e minor device numbers. Questi indicano rispettivamente:
                    1. major device number: l' attuale disositivo con cui il device file è associato. Ogni device driver registra nel kernel un unico major number.  
                    2. minor device number: Ogni istanza(instance) di tale dispositivo registra un unico minor number per questo major device. 
                    Le interfacce tty, /dev/tty*, sono dei disositivi di tipo carattere( "c") e ognuna ha:
                    1. un major number 4
                    2. ma /dev/tty1 ha un minor number 1, e /dev/tty2 ha un minor number 2.
                    I files di dispositivo sono utili , ma possono portare confusione quando per esempio cerchiamo di trovare un dispositivo non usato per poterlo aprire. In Linux i nomi di interfaccia sono definiti internamente al kernel e non sono file di dispositivo nella directory /dev. L' assegnamento di interfacce ai dispositivi di solito dipende dal ordine nel quale i dispositivi sono stati configurati. Per esempio la prima Ethernet card installata diventa eth0, e la prossima eth1 ecc.  
                    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.
                    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 protocollo 
                    Quindi in questo caso sono neccessari due drivers:
                    1. un driver a basso livello per il hardware della porta ed
                    2. 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
                      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 serverComunemente 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 Ethernet in Linux si chiamano eth0, eth1 etc.
                      • 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:
                      • 255.255.0.0 per un IP di classe B 
                      • 255.255.255.0 per un IP di classe C ecc. 
                      Per disporre di un interfaccia di rete:
                      1. il primo passo in assoluto è caricare il suo driver.
                      2. 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:
                      1. 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à. 
                      2. 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). 
                      3. 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.
                      • add address/prefixlength— Quest' opzione è l'equivalente di up e netmask, per il IPv6. IPv6 permette avere molti più indirizzi IP rispetto al suo predeccessore IPv4.
                      • 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

                      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 
                      1. 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.
                      2. 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.
                      3. 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

                      # 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:
                      1. 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).
                      2. 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:

                      # route [add|del] [-net|-host] target [if]
                      Gli argomenti:
                      • add e del determinano l' aggiunta o rimozione della route verso target 
                      • -net e -host informano il comando route se il target è un network o un host (se non lo specifichiamo si assume che sia un host) 
                      • if permette di specificare verso quale interfaccia di rete deve essere diretto il traffico routed

                      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.
                      1. 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.
                      2. 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. 
                      3. 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 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.
                      • [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:
                      # 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:
                      1. Eseguire ifconfig per ogni interfaccia del computer.
                      2. 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.
                      Se disponiamo di un solo indirizzo IP esterno ma vogliamo connettere più computers in Internet, possiamo usare uno speciale tipo di routing conosciuto come Network Address Translation (NAT). I passi base sono come per un router ordinario , ma il NAT ci richiede l' esecuzione di qualche comando extra per permettere al router di traslare indirizzi in modo da far sembrare (da parte del mondo esterno alla nostra rete) la nostra rete come se fosse un singolo computer.

                      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.
                      • 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: 
                        # 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.
                        Come fecimo per la loopback interface, dobbiamo adesso installare una routing entry che informa il kernel circa la rete che deve essere raggiunta attraverso eth0. Per il Virtual Brewery
                        # 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. 
                        Un approccio più conveniente e di usare nomi di rete attraverso il file /etc/networks. Con tale approccio route diventa molto più leggibile e anche il -net flag si può ommettere perchè adesso route sa che 172.16.1.0 denota un network:
                        # 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/12
                        Come 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    eth0
                          I 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.
                            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.
                            Dopo aver editato per come ci conviene il /etc/resolv.conf le modifiche si applicano immediattamente e Linux comincia subito ad usare i name servers e ricercare sui domini ivi specificati.

                            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
                            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
                            1. 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)
                            2. 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. 
                            3. 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.
                            4. 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
                              !: rappresenta una route reiettata il che vuol dire che i datagrams saranno scartati
                              Le prossime 3 collone MSS, Window, irtt si applicano a connessioni TCP stabilite attraverso questa route. 
                              • 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") 
                              Il protocollo TCP assicura che i dati sono recapitati in modo affidabile fra i hosts ritrasmettendo un datagram se esso viene perso. Inoltre tiene conto di quanto tempo impiega un datagram per essere consegnato dal ricevente e quanto tempo impiega il rispettivo acknowledgement per essere ricevuto dal mittente originario in modo da sapere quanto deve aspettare prima dell' eventuale ritrasmissione. questo tempo viene chiamato round-trip time. Il valore iniziale del round-trip time viene utilizzato dal protocollo TCP quando si stabilisce una nuova connessione.
                                  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
                              • 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
                              netstat ha delle opzioni per visualizzare i sockets attivi o passivi.
                              • -t, -u, -w, -x visualizzano i sockets di connessioni attive TCP, UDP, RAW, or Unix
                              • Il flag -a inoltre visualizza, i sockets che sono in attesa di una connessione (tipo listening). Questo in pratica ci da una lista di tutti i servers che vengono correntemente eseguiti nel nostro sistema.
                                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: 
                                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
                                che ci indica le Ethernet addresses di vlager, vstout and vale.
                                • Possiamo limitare la visualizzazione sul tipo di hardware specificato usando l' opzione -t. Questa può essere ether, ax25, o pronet, che stanno per 10 Mbps Ethernet, AMPR AX.25, and IEEE 802.5 token ring hardware, rispettivamente.
                                • 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: 
                                # arp -d fnord


                                Fare le nostre modifiche permanenti

                                1. 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. 
                                2. 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. 
                                3. 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

                                Bibliografia
                                  • 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


                                Webografia

                                Ringraziamenti-Dediche
                                Dedico questi Appunti a:
                                  1. Un Grande OS che mi ha servito dal finire degli anni ottanta fino a oggi e che contribuisce a "buscare" il pane quotidiano
                                  2. Al esimio Daniele Giacomini http://informaticalibera.net/

                                        No comments:

                                        Post a Comment