Riorganizzazione Rete TCP/IP Italiana

Presentazione sul tema: "Riorganizzazione Rete TCP/IP Italiana"— Transcript della presentazione:

1 Riorganizzazione Rete TCP/IP Italiana
Coordinamento Nazionale TCP/IP Ampr Italia Meeting “Trasmissioni Digitali” Limbiate 26 Maggio 2007

2 Obiettivi 1. Creare una rete TCP/IP unitaria indipendentemente dal protocollo di trasporto; 2. Consentire una navigazione “trasparente” per gli utenti accedendo unicamente al proprio “Punto di Presenza”; 3. Creare servizi di interesse per gli utenti: web, nntp, cluster via TCP/IP, gateway bollettini AX.25, ecc.. 3. “Educare” i SysOp ad una cultura di collaborazione pienamente rispondente ai nostri valori HAM; 4. Superare i limiti derivanti da appartenenza a diverse associazioni.

3 Azioni da intraprendere
1. Costituire un gruppo di lavoro possibilmente composto da persone appartenenti a zone differenti; 2. Rendere noto alla comunità mondiale TCP/IP e al Coordinatore Mondiale Brian Kantor che l'Italia ha deciso di attuare un progetto di riorganizzazione; 3. Censire i Server TCP/IP esistenti e loro servizi attivi; 4. Redigere una lista di utenti che realmente opera in TCP/IP divisi per Server di appartenenza; 5. Coadiuvare i SysOp nell'apportare le configurazioni che si renderanno opportune; 6. Bonifica della “Zona Italia” nel DNS mondiale *.ampr.org, inserendo SOLO i server e gli utenti davvero attivi.

4 Struttura della nuova rete
Introduzione Il progetto di riorganizzazione del Routing TCP/IP per la rete /16 (Subnet italiana) prevede la costituzione di un Router Nazionale sito a Modena il cui compito sara' quello di gestire tutto il traffico nazionale (su IP/IP) ed agire da default gateway per l'accesso alla rete mondiale AMPRNet. I Gateway italiani dovranno dismettere il tradizionale sistema Encap ed utilizzare esclusivamente una rotta statica verso il Router Nazionale, default gateway per la rete /8 ad eccezione delle subnet regionali o interregionali raggiunte via radio. Dalla discussione sviluppatasi sull’argomento sono emerse alcune proposte di modifica all'impianto originale del progetto fortemente caratterizzato dalla filosofia "default is radio" (versione 1.0). Gli interventi di IZ6CUS, I7IGX, IZ4EFN hanno messo in luce un effetto negativo e arrestante che potrebbe verificarsi se il progetto partisse gia' con una impostazione rigida e di chiusura verso l'uso piu' permissivo di Internet. Bisogna tener conto che parecchie regioni non sono coperte da una rete radio (AX.25 o Wifi) capillare in grado di consentire il traffico TCP/IP. Anzi in alcune regioni la rete packet tradizionale e' in completo stato di abbandono e rimane in esercizio finche‘ reggono le apparecchiature. Per queste ragioni la filosofia "default is radio", se applicata con rigore potrebbe fermare l'interesse di gruppi, di sezioni, di singoli radioamatori che vogliono sperimentare il TCP/IP, ma che non hanno reti di accesso disponibili o capaci di veicolare tale traffico.

5 Nell'ottica quindi di diffondere questa tecnica e favorire il nascere di stazioni server o semplici stazioni personali si e' ritenuto opportuno introdurre modifiche al progetto originale. E' importante ribadire che l'obiettivo rimane quello di tendere allo sviluppo di una rete Radio TCP/IP, sia essa di tipologia AX.25 (packet tradizionale) o Wifi. Quindi si auspica che i nuovi interessati al TCP/IP (gruppi di appassionati o sezioni associative) dopo un primo periodo di collaudo possano, in accordo con altri gruppi o sezioni, partecipare alla costruzione di una rete radio regionale o interregionale. In questa opera riceveranno il supporto del Coordinatore/Numeratore Regionale, Coordinatore Nazionale e dei colleghi del "Gruppo AMPR ITA".

6 I soggetti della nuova rete
Router Nazionale AMPR Il Router Nazionale sito in Modena presso la Server Farm della Sez. A.R.I. di Modena gestira' il traffico nazionale (su IP/IP) consentendo l'accesso ai Gateway nella Rete AMPR Mondiale. La Server Farm progettata secondo standard professionali offre banda garantita sufficiente per effettuare tale servizio. Nella fase successiva allo start-up saranno studiate soluzioni per garantire la continuità di funzionamento del server. Il Router fara' parte del routing "encap“ presentandosi con la rotta: route addprivate /16 encap xxx.xxx.xxx.xxx unica per l'Italia.

7 Stazione Gateway E' la stazione che effettua un "ponte" tra la rete TCP/IP (44) via Radio e la rete TCP/IP (44) via Internet IP/IP. Questa tipologia di stazione puo' gestire una o piu' subnet a seconda della effettiva copertura radio (a partire da una subnet provinciale fino a tutte le subnet assegnate alla Regione). I Gateway offrono servizi TCP/IP via Radio ai propri utenti cosi' come i server provinciali. E' auspicabile che la dislocazione delle stazioni Gateway sia studiata con accuratezza avvalendosi della collaborazione del Coordinatore/Numeratore Regionale. Le stazioni Gateway sono direttamente connesse al Router Nazionale attraverso la seguente rotta statica: ip route add /8 via xxx.xxx.xxx.xxx dev tunl0 onlink (xxx.xxx.xxx.xxx = l'IP sara' presto definito)

8 Stazione Server provinciale
E' la stazione che offre servizi TCP/IP via Radio ai propri utenti su base provinciale. Il Server provinciale gestisce la subnet provinciale di competenza o anche piu' subnet ove non esistano altri server nelle province limitrofe e sia soddisfatta la copertura radio delle stesse. Il Server provinciale e' connesso al Gateway presente nella propria regione con link Radio. Tuttavia ove non esistano o siano in costruzione/progettazione link radio tra Gateway e Server, ovvero il Server sia ubicato in posizione poco favorevole per link radio di "backbone" e' possibile una connessione via Internet (IP/IP) direttamente al Router Nazionale. Per tale configurazione le Stazioni Server dovranno utilizzare la rotta statica: ip route add /8 via xxx.xxx.xxx.xxx dev tunl0 onlink (xxx.xxx.xxx.xxx = l'IP sara' presto definito)

9 Stazione OM individuale
In via sperimentale potra' realizzarsi il collegamento di singole stazioni OM al Router Nazionale. Saranno presi in considerazione i casi di OM residenti in zone in cui non esiste una rete Packet/TCP/IP ovvero non sono presenti Server/Gateway. In tutti gli altri casi il traffico TCP/IP tra Stazione OM e Stazione Server provinciale/Gateway avviene via radio. Dopo una prima fase di sperimentazione si auspica che gli OM possano iniziare a fare traffico via radio con collegamento al proprio server provinciale o gateway limitrofo. Sara' fondamentale il ruolo del Coordinatore/Numeratore Regionale che dovra' sensibilizzare i gruppi di OM o sezioni associative al fine di realizzare Server o installare nuovi Digipeater per ampliare la copertura radio. L'accesso di singoli OM e' in fase di sperimentazione gia' su alcuni server tedeschi (es. DB0FHN) che utilizzano modalita' di accesso sicure e capaci di garantire l'identita' di chi accede (es. OpenVpn con certificati).

10 Come funziona il sistema Encap ?
Encap significa incapsulare. Nel nostro caso vengono incapsulati datagram IP in datagram IP, cioe' i pacchetti con mittente e destinatario 44.*.*.* sono incapsulati in pacchetti destinati alla rete pubblica. Solitamente per consentire questo tipo di traffico attraverso i comuni firewall/router adsl bisogna consentire il passaggio del protocollo IPIP numero 94. Specifiche piu' dettagliate sono reperibili sul sito: (punto 6.8) Recentemente VE4KLM, N1URO e altri radioamatori hanno sviluppato un prototipo di IP/UDP per ovviare al problema del filtro su IP/IP che alcuni provider operano. Attualmente i maggiori provider Italiani consentono ancora il traffico IP/IP.

11 Il sistema ENCAP nasce per consentire di creare una rete globale che possa essere fruita in maniera indipendente dal mezzo fisico di trasporto (cavo, radio). In parole semplici tramite l'ENCAP viene realizzata una sorta di VPN molto rudimentale poiche' il traffico e' in chiaro e non esistono server che centralizzano il traffico, bensì abbiamo centinaia di rotte statiche punto-punto. Esempio: speed:/etc/init.d# netstat -nr | grep tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0 UGH tunl0

12 Ogni SysOp di Gateway indica, tramite un robot, su un file encap
Ogni SysOp di Gateway indica, tramite un robot, su un file encap.txt le proprie subnet 44 in riferimento al proprio indirizzo ip pubblico statico. Il sistema e' gestito da James Fuller - Esempio di file encap.txt: route addprivate /24 encap route addprivate /24 encap >> IW5DAM route addprivate /24 encap route addprivate /32 encap >> IR5PIT route addprivate /23 encap >> IR9PAT route addprivate /32 encap route addprivate /20 encap >> IQ4AX (Modena) route addprivate /20 encap route addprivate /22 encap >> IK1ZNW (Torino) route addprivate /20 encap >> IW2OHX (Rho) route addprivate /23 encap >> IW7ATL (Trani) route addprivate /24 encap >> IW6NDX (Sulmona) route addprivate /32 encap route addprivate /32 encap >> I6QPL (L'Aquila)

13 Esempio di configurazione Tunnel in Linux
echo "Start tunnelling..." echo " enabling tunl0 device" #modprobe ipip ifconfig tunl mtu 576 up # Amprnet routing... echo " deleting /8 and setting default route to mirrorshades.ucsd.edu" ip route del /8 echo " downloading encap.txt from Fuller.net:" rm /etc/init.d/gateways rm /etc/init.d/encap.txt cd /etc/init.d/ wget wget /etc/init.d/tunnel-munge.sh < /etc/init.d/encap.txt > /etc/init.d/ipip.routes cat /etc/init.d/ipip.routes|sed s/add/del/ > /etc/init.d/del.ipip.routes source /etc/init.d/ipip.routes

14 Script Tunnel-munge.sh
speed:~# cat /etc/init.d/tunnel-munge.sh #!/bin/sh # echo "#" echo "# IP tunnel route table built by $LOGNAME on `date`" echo "# by tunnel-munge script v " echo "# Misc user routes" echo "# remote routes" fgrep encap | grep "^route" | grep -v " XXX.XXX.XXX.XXX" | \ awk '{ printf "ip route add %s via %s dev tunl0 onlink\n"\ ,$3,$5 }' echo "# default the rest of amprnet via mirrorshades.ucsd.edu" echo "ip route add /8 via dev tunl0 onlink" echo "# the end” Script Tunnel-munge.sh che converte il file encap.txt (formato *nos) in elenco di rotte per GNU/Linux

15 Proposta di variazione dominio da *.zona.it.ampr.org a *.ampr.org
L'idea lanciata anni fa da Tiziano IW2MLN di costituire delle zone italiane sotto il dominio ampr.org e' sicuramente stata una bella idea e condivisibile dal punto di vista tecnico. Pero', ritengo, che ogni servizio tcpip deve essere valutato tenendo conto della sua utilita' reale poiche' implica un consumo di risorse e di manutenzione. Ci sono una serie di ragioni sia politiche/organizzative che tecniche che propendono per la abolizione: politiche: - da quando abbiamo adottato lo standard zona.it.ampr.org ci siamo allontanati dallo standard mondiale ed il coordinatore mondiale (forse offeso!) ci ha letterlamente ignorato per anni. Addirittura non abbiamo neanche i "poteri" per effettuare modifiche sul DNS ampr.org; organizzative: - chiediamoci se il servizio DNS (nel senso trasferimento zone) sia realmente utile considerando il numero di OM che REALMENTE fa TCP/IP; - a parte qualche eccezione, la maggior parte dei gestori di DNS regionali non effettua la manutenzione ordinaria e non aggiorna la zona di competenza; - il 90% degli host(s) inseriti nei file zonali non operano oppure non hanno mai operato in TCP/IP; tecniche: - allo stato dei fatti non c'e' una integrazione tra DNS ampr.org e DNS italiani rappresentativi delle singole zone, poiche' non vengono trasferite le zone italiane sul DNS ampr.org. Avviene che se un utente americano vuole contattare un utente di zona 2 non potra' farlo cercando di risolvere ik2xyz.2.it.ampr.org poiche' non c'e' alcuna entry nel dns ampr.org.....potra' contattarlo solo se conosce l'IP...ovviamente; - come anzi detto credo che un servizio tcpip debba essere tenuto in piedi solo se e' veramente necessario anche se puo' essere interessante dal punto di vista tecnico. Per quanti sono gli utenti TCP/IP nazionali e per quanti sono i Server che erogano il servizio, ritengo che il DNS, così concepito, non sia utile.

16 La soluzione da me proposta è la seguente ispirata al principio di economia delle risorse e perfettamente integrata con l'idea di rete unitaria prima esposta. Ancora una volta giocheranno un ruolo fondamentale i Gateway di Zona poichè saranno responsabili di gestire le richieste DNS provenienti dai DNS/Server Regionali e provinciali. I Gateway di Zona, in quanto connessi ad Internet, non avranno alcun problema ad interfacciarsi con il DNS mondiale *.ampr.org. Per consentire questi passaggi i SysOp dovranno configurare i propri DNS come semplici relay per la zona ampr.org. Esempio: // zone section fragment of named.conf zone "ampr.org" IN { type forward; forwarders { ; }; }; Oppure nel caso in cui il DNS sia usato solo per scopi ampr e gli unici utenti sono i radioamatori si può utilizzare la configurazione di “Global forwarding”: // options section fragment of named.conf // forwarders can have multiple choices options { directory "/var/named"; forwarders { ; }; forward only; }; e' ik1znw.ampr.org = Gateway di Zona (nord-ovest) Questa semplice guida può essere di aiuto: Il compito del neo-costituito gruppo di lavoro sarà quello di bonificare la “Zona Italiana” del DNS mondiale ampr.org. Saranno inseriti ESCLUSIVAMENTE gli hostname appartanenti ad O.M. che effettuano REALMENTE l'attività TCP/IP, oltre naturalmente agli hostname dei DNS/Router provinciali/regionali e dei Gateway di Zona. Sarà fatta pulizia del vecchiume di oltre 10 anni! Sarà richiesta la collaborazione dei Numeratori Regionali....e di tutta la comunità TCP/IP.

17 IW2OHX – Marco – Ampr e-mail: iw2ohx@iw2ohx.ampr.org
FINE IW2OHX – Marco – Ampr