VoIP and Hacking | Consulenza Documentazione

Realizzare una soluzione telefonica, basata su Asterisk e puramente VoIP, e che si possa definire pienamente soddisfacente, è sempre una operazione delicata, ed uno dei suoi prerequisiti essenziali consiste certamente nel poter contare su una connettività Internet stabile e adeguatamente dimensionata. Questo è tanto più vero e l’obiettivo difficile da raggiungere quando il numero delle utenze della LAN locale diventa elevato, come tipicamente avviene in ambito aziendale.
La forzata (ed infelice) convivenza di traffico VoIP e traffico molto eterogeneo destinati a condividere la stessa connettività esterna spingono spesso a comportamenti drastici.

Ho notato, ad esempio, in più occasioni che i responsabili IT, almeno quelli già consapevoli del problema, tendono a far predisporre collegamenti di tipo SHDSL, talora in sostituzione di semplici ADSL che fino a quel momento avevano ben lavorato, pensando (giustamente per la verità) che sia importante per il VoIP avere una capacità di upstream pari a quella di downstream. Il problema, con questa adozione, è che il downstream, che costituisce la maggior parte del traffico non VoIP, viene fortemente limitato, e di conseguenza la competizione tra traffico realtime e traffico eterogeneo diviene ancora più critica, e il malcontento degli utenti, diffuso.
La soluzione classica consiste nell’implementare qualche forma di QoS o almeno traffic-shaping per priorizzare (ma in questo caso funziona solo in EGRESS) il traffico VoIP. In genere così la qualità della telefonia migliora (più o meno) ma il malcontento, riguardo alla peggiorata efficienza delle altre tecnologie, è semmai destinato ad aumentare.

Personalmente ritengo che un approccio alternativo possa essere preferibile.

Facciamo l’ipotesi che la azienda Pinco Pallino, (potrebbe trattarsi di un concessionario di auto o di un grossista di alimentari), abbia una decina di persone, tra impiegati, venditori e magazzino, abilitati ad accedere ad Internet. Ipotizziamo anche che chi si occupa dell’ IT sia una persona competente e magari, avendo implementato un cache dns server e un proxy tipo Squid, sia sempre riuscito a garantire un buon livello di accesso ad Internet tramite una normale ADSL aziendale. Coerentemente, progetti poi di implementare un sistema di telefonia VoIP basato su Asterisk.

Se adottare il modo visto sopra, probabilmente si troverebbe nei guai, ma potrebbe pure adottare una soluzione alternativa, anche discretamente più economica, semplicemente richiedendo l’installazione di una seconda ADSL aziendale, dedicata esclusivamente al traffico VoIP gestito dal server Asterisk, fondamentalmente quello scambiato con il VoIP Service Provider che si sarà scelto.
Un possibile schema è quello riportato qui sotto:

                                       +-----------------+
                                       |      gw 1       | ADSL1 provider1
                            +----------+   (default)     +------+
                            |          | NNN.NNN.NNN.NNN |      |
                     +------+-------+  +-----------------+      |
+-------------+      |     eth1     |                           |
|             |  eth0|              |                           |
| Rete Locale +-+----+ Linux router |                           | Internet
|             | |    |              |                           |
+-------------+ |    |     eth2     |                           |
+---------------+-+  +------+-------+  +-----------------+      |
|                 |         |          |      gw 2       |      |
| Asterisk Server |         +----------+     (VOIP)      +------+
|                 |                    | ZZZ.ZZZ.ZZZ.ZZZ | ADSL2 provider2
+-----------------+                    +-----------------+

Il server Asterisk è semplicemente un elemento della rete locale, nello stesso spazio di indirizzamento IP. La connettività Internet è filtrata da un router Linux. La eth1 di quest’ultimo è connessa tramite gw1 all’ ADSL provider1, mentre la eth2, tramite gw2, con l’ADSL2 provider2.

Il problema del router è solo quello di fornire appunto un semplicissimo routing differenziato.
Ipotizzando che il default gateway originale fosse gw1, dovremo ora fare in modo che qualsiasi traffico in ingresso su eth2 ottenga risposta sempre tramite eth2, e non tramite eth1, come invece avverrebbe normalmente.

Bisogna per prima cosa essere certi che il kernel Linux del router fornisca il supporto al “policy routing”.
Ad esempio, durante un eventuale ricompilazione del kernel, occorrerebbe effettuare le scelte sottostanti:

# cd /usr/src/linux
# make menuconfig
Selezionare "Networking --->"
Selezionare "Networking options --->"
[*] TCP/IP networking
[*] IP: advanced router
Scegliere IP: FIB lookup algorithm (FIB_HASH)
[*] IP: policy routing
[*] IP: use netfilter MARK value as routing key

A questo punto viene in soccorso il tool iproute2

Occorre innanzitutto creare una nuova voce nella policy routing table definita in /etc/iproute2/rt_tables.
Numerandola #1, chiamiamola “VOIP” (servirà proprio al routing del traffico VoIP attraverso eth2).

Dal prompt di root:

# echo 1 VOIP >> /etc/iproute2/rt_tables

Il passo successivo sarà quello di impostare una route con una singola regola per la table VOIP:

# ip route add default via ZZZ.ZZZ.ZZZ.ZZZ dev eth2 table VOIP
# ip rule add from table VOIP

Da ora in avanti i pacchetti in arrivo dal server Asterisk verranno sottoposti alla routing table VoIP dove, essendo presente una default route, verranno passati al gateway gw2. mentre i pacchetti che arrivano da tutti gli altri nodi locali continueranno ad utilizzare la main routing table.
E tutti vissero felici e contenti

Send post as PDF to