Questo è il secondo di tre articoli che descrivono un’implementazione di reti di accesso neutrali basata sul policy routing di Linux. Ne descrivo il funzionamento facendo riferimento allo schema architetturale introdotto nel post del primo settembre (che riproduco di seguito per comodità):

L’architettura di esempio mostrata in figura ha una struttura ad albero: gli utenti sono le foglie, le isole di accesso sono i rami, la dorsale è il tronco e il gateway di smistamento (o policy router) è la radice. Per consentire agli utenti di accedere ai servizi pubblicati nella sottorete servizi è sufficiente l’impostazione dei default gateway delle sottoreti.

Le cose si complicano un po’ quando l’indirizzo da raggiungere non appartiene alla rete di accesso o alla sottorete servizi, ma è un qualunque IP pubblico. La complicazione è duplice. Innanzitutto occorre bloccare l’accesso se l’utente non è autenticato (e l’indirizzo non appartiene alla white list di indirzzi virtualmente interni). In secondo luogo occorre smistare il traffico verso Internet per permettere ad ogni utente di utilizzare l’edge router del provider che preferisce. Queste due funzioni sono svolte dal captive portal e dal gateway di smistamento (o policy router).

Captive portal

Il captive portal e’ rappresentato dal rettangolo grigio pubblicato all’indirizzo 172.20.2.2 della sottorete servizi ed e’ definito come default gateway del policy router. Quando un utente che non ha ancora scelto uno degli edge router disponibili per la navigazione Internet tenta di raggiungere una pagina web esterna alla sottorete servizi e alle eventuali white list, il captive portal lo ridirige su una landing page dalla quale e’ possibile accedere ai servizi interni o scegliere uno degli edge router. La scelta dell’edge router comporta l’impostazione dinamica di un’apposita regola nel policy router.

Policy router

Il policy router smista il traffico generato dagli utenti sugli edge router scelti da ciascuno. Questa funzione di smistamento puo’ essere implementata utilizzando il supporto per il routing avanzato del kernel di Linux. In particolare il file rt_tables installato sul policy router contiene la lista delle tabelle di routing disponibili, con le rispettive priorita’. Nell’implementazione proposta, ad ogni policy router e’ dedicata una tabella di routing. Nel nostro esempio, chiamando ISP_A e ISP_B le tabelle dedicate ai due edge router A e B, il file rt_table conterra’ le righe:

1 ISP_A
2 ISP_B

Ogni tabella contiene a sua volta almeno una regola, che specifica come default gateway l’edge router corrispondente. Altre regole potrebbero essere aggiunte per ottimizzare il traffico. Nel seguente esempio viene specificata una seconda regola per permettere di raggiungere i servizi locali direttamente dal policy router senza passare per l’edge router:

# table ISP_A
ip route add default via 172.20.2.10 dev eth1 table ISP_A
ip route daa 172.20.2.0/24 via 172.20.2.1 table ISP_A

Poiche’ la definizione delle tabelle non ne comporta l’applicazione, tutte le tabelle associate agli edge router possono essere definite in anticipo (una volta per tutte) e applicate dinamicamente in base alle scelte operate dall’utente attraverso la landing page del captive portal.

Immaginiamo che la landing page del captive portal contenga “bottoni” associati agli edge router disponibili. Quando l’utente 172.16.1.23 preme il bottone corrispondente all’edge router A, la sua scelta viene registrata su una database come richiesta in attesa di essere processata. Un demone che gira sul policy router interroga periodicamente il database e processa le richieste pendenti lanciando i comandi necessari a creare le corrispondenti politiche di routing. In questo caso il comando e’ il seguente:

ip route add from 172.16.1.23 table ISP_A

che crea una nuona regola di source-based policy routing il cui effetto e’ l’applicazione della tabella ISP_A a tutto il traffico originato dall’indirizzo 172.16.1.23.

Un meccanismo analogo e’ utilizzato per rimuovere o sostituire le regole.

Continua…

Riferimenti:

• Andrea Seraghiti and Alessandro Bogliolo, “Neutral Access Network Implementation Based on Linux Policy Routing”, in Proceedings of INTERNET-2009, 2009. [paper] [slides]
• M. G. Marsh, Policy Routing Using Linux, SAMS, 2006.

Abbiamo visto che le reti di accesso neutrali (che indichiamo con l’acronimo NAN, dall’inglese Neutral Access Network) devono:

• consentire agli utenti di associarsi liberamente alla NAN;
• permettere ai service provider (SP) di esporre i propri servizi all’interno della NAN;
• permettere agli Internet Service Provider (ISP) di offrire banda Internet ai propri clienti attraverso la NAN;
• offrire le stesse condizioni di utilizzo a tutti gli utenti e a tutti i provider (SP e ISP);
• permettere di incrementare la copertura senza limiti tecnologici;
• gestire in modo neutrale il traffico tra gli utenti, i servizi dei SP e i gateway degli ISP.

Inoltre, per evidenti ragioni di ordine pratico, dovrebbero essere semplici e indipendenti dalla tecnologia di accesso adottata (WiFi, xDSL, WiMAX, …).

Qualche giorno fa è stata presentata a Cannes una soluzione che soddisfa questi requisiti utilizzando solo comuni distribuzioni di Linux per la gestione della NAN. Ne descrivo brevemente il funzionamento, rimandando al paper e alle slides per eventuali approfondimenti.

Per ragioni di leggibilità divido la descrizione in tre post: in questo presento solo lo schema di massima e l’architettura, mentre nel prossimo descrivo i principi di funzionamento e nel terzo discuto estensioni e problemi aperti.

La figura precedente mostra lo schema di massima di una NAN (o di una open access network, OAN), che si frappone tra gli utenti (rappresentati in basso) e Internet (in alto). Sono evidenziati gli edge router (o gateway di frontiera) degli ISP e dei SP, la dorsale neutrale (operator neutral backbone) e le isole di accesso (access islands) che offrono connessione agli utenti. Ogni isola di accesso puo’ essere gestita da operatori diversi e differenziarsi dalle altre per tecnologia o per copertura territoriale. La distinzione tra dorsale e isole di accesso non è indispensabile, ma conferisce flessibilità e generalità al modello.

La figura precedente mostra una soluzione architetturale per l’implementazione di una NAN. Ad ogni isola d’accesso è associata una sottorete il cui default gateway (access router) è il gateway verso la dorsale. Alla dorsale è associata una sottorete separata. Inoltre è definita una ulteriore sottorete nella quale vengono pubblicati i servizi e gli edge router degli ISP. Il gateway posto tra la dorsale e la sottorete servizi è detto gateway di smistamento, o policy router, ed è il default gateway della dorsale. A titolo esemplificativo vengono specificati gli indirizzi IP assegnati agli utenti, alle sottoreti e ai gateway.

Continua…

Riferimenti:

• Andrea Seraghiti and Alessandro Bogliolo, “Neutral Access Network Implementation Based on Linux Policy Routing”, in Proceedings of INTERNET-2009, 2009. [paper] [slides]