Progetto di riorganizzazione Rete AMPR/HamNet Italia

Riorganizzazione Rete TCP/IP
Italiana
Coordinamento Nazionale TCP/IP Ampr Italia
Meeting “Trasmissioni Digitali” Limbiate
26 Maggio 2007
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.
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.
Struttura della nuova rete
Introduzione
Il progetto di riorganizzazione del Routing TCP/IP per la rete 44.134.0.0/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 44.0.0.0/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.
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".
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 44.134.0/16 encap xxx.xxx.xxx.xxx
unica per l'Italia.
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 44.0.0.0/8 via xxx.xxx.xxx.xxx dev tunl0 onlink
(xxx.xxx.xxx.xxx = l'IP sara' presto definito)
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 44.0.0.0/8 via xxx.xxx.xxx.xxx dev tunl0 onlink
(xxx.xxx.xxx.xxx = l'IP sara' presto definito)
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).
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:
http://tldp.org/HOWTO/NET3-4-HOWTO-6.html (punto 6.8)
http://www.fuller.net/Gateways/updates.html
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.
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
44.153.54.20
200.80.238.185 255.255.255.255 UGH
00
0 tunl0
255.255.255.255 UGH
00
0 tunl0
24.138.74.225 255.255.255.255 UGH
00
0 tunl0
00
0 tunl0
44.131.94.240 82.33.62.185
44.135.34.4
44.131.93.240 82.33.62.185
255.255.255.255 UGH
44.134.208.241 146.48.126.28 255.255.255.255 UGH
00
0 tunl0
44.135.96.17
132.213.22.244 255.255.255.255 UGH
00
0 tunl0
44.88.40.11
64.194.250.201 255.255.255.255 UGH
00
0 tunl0
44.88.8.2
65.126.240.2
255.255.255.255 UGH
00
0 tunl0
44.137.25.101 80.100.252.147 255.255.255.255 UGH
44.88.8.4
44.102.56.1
65.126.240.14 255.255.255.255 UGH
00
00
209.142.208.90 255.255.255.255 UGH
0 tunl0
0 tunl0
00
0 tunl0
44.131.93.130 82.33.62.185
255.255.255.255 UGH
00
0 tunl0
44.131.95.128 82.33.62.185
255.255.255.255 UGH
00
0 tunl0
80.100.252.147 255.255.255.255 UGH
00
0 tunl0
44.137.25.52
44.130.177.135 213.239.233.155 255.255.255.255 UGH
00
0 tunl0
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 - http://www.fuller.net/Gateways/
Esempio di file encap.txt:
route addprivate 44.134.208/24 encap 146.48.126.26
route addprivate 44.134.209/24 encap 146.48.126.26 >> IW5DAM
route addprivate 44.134.210/24 encap 146.48.126.26
route addprivate 44.134.208.241/32 encap 146.48.126.28 >> IR5PIT
route addprivate 44.134.112/23 encap 147.163.7.250 >> IR9PAT
route addprivate 44.134.33.168/32 encap 160.80.2.11
route addprivate 44.134.196/20 encap 195.43.189.178 >> IQ4AX (Modena)
route addprivate 44.134.128/20 encap 213.254.1.202
route addprivate 44.134.144/22 encap 213.254.1.202 >> IK1ZNW (Torino)
route addprivate 44.134.160/20 encap 213.254.1.202 >> IW2OHX (Rho)
route addprivate 44.134.64/23 encap 213.254.1.202 >> IW7ATL (Trani)
route addprivate 44.134.48/24 encap 81.73.149.82 >> IW6NDX (Sulmona)
route addprivate 44.134.52.1/32 encap 88.213.131.134
route addprivate 44.134.52.2/32 encap 88.213.131.134 >> I6QPL (L'Aquila)
Esempio di configurazione Tunnel in Linux
echo "Start tunnelling..."
echo " enabling tunl0 device"
#modprobe ipip
ifconfig tunl0 44.134.130.2 mtu 576 up
# Amprnet routing...
echo " deleting 44.0.0.0/8 and setting default route to mirrorshades.ucsd.edu"
ip route del 44.0.0.0/8
echo " downloading encap.txt from Fuller.net:"
rm /etc/init.d/gateways
rm /etc/init.d/encap.txt
cd /etc/init.d/
wget ftp://gateways:[email protected]/gateways
wget ftp://gateways:[email protected]/encap.txt
/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
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 v960307."
echo "#"
echo "# Misc user routes"
echo "#"
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 "#"
echo "# default the rest of amprnet via mirrorshades.ucsd.edu"
echo "ip route add 44.0.0.0/8 via 128.54.16.18 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
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.
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 {44.134.130.1; };
};
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 {44.134.130.1; };
forward only;
};
44.134.130.1 e' ik1znw.ampr.org = Gateway di Zona (nord-ovest)
Questa semplice guida può essere di aiuto: http://www.zytrax.com/books/dns/ch4/
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.
FINE
IW2OHX – Marco – Ampr e-mail: [email protected]