Dns bind view
Da Fabwiki.
Indice |
Obiettivi
Naturalmente, l' obiettivo è quello di rendere accessibili tutti i servizi sia da internet sia dalla lan
Problematiche
Analizziamo i problemi riscontrati in questo scenario.
Fino a quando avevo il modem, tutto funzionava egregiamente: gli veniva assegnato un indirizzo ip statico dal provieder, via pppoa e stop.
Con il router, invece, la cosa è un po' diversa perchè, a diffrenza del modem, introduce il concetto di "interno" ed "esterno" (lan o wan) Questo significa che la configurazione attuale "as is" ha grossi limiti derivati dal fatto che, proprio per via di questo concetto "interno" - "esterno" introdotto dall' uso del router", da qualsiasi pc della lan interna non potevo visualizzare i siti risiedenti sul server e pubblicati su internet (esempio, questo).
Prima soluzione
Naturalmente, esistono varie soluzioni per ovviare a questo problema. La piu' immediata è quella di avere un router che supporti la funzione nat loopback In pratica, tale funzione, assegna un ip pubblico alla rete locale. In questo modo, digitando http://www.fabreg.it da una delle macchine locali, si vedrà correttamente il sito.
Seconda soluzione
Questa, in realtà, è un accrocchio. Su ogni macchina client sia essa windows o linux, è necessario modificare il file hosts in questo modo:
192.168.1.2 www.fabreg.it 192.168.1.2 www.altrosito.com 192.168.1.2 www.altrositoancora.com
Immaginate di usare un pc portaile, collegato alla vostra lan: fate la modifica al file hosts e tutto funziona benone. E domani, quando sarete da un cliente o comunque all' esterno della vostra lan ? Dovrete ripulire il file hosts (altrimenti, logicamente, se digiterete http://www.fabreg.it dall' esterno della vostra lan, non funzionerà) E quando tornate a casa e ricollegate il pc in lan? Dovrete modificare nuovamente il file...
Terza soluzione
Questa è la soluzione che ho usato. Implica l' uso di un dns, nel mio caso bind9.
Come dicevo prima, tutto quello che sta prima del router, viene visto come locale. Per cui, dimenticatevi per un attimo di avere un indirizzo ip statico e se in precedenza, come nel mio caso, avevate l' ip pubblico cablato all' interno dei VirtualHost di apache, sostituitelo con l' indirizzo privato.
A questo punto, fatta questa modifica, chi visita il nostro sito lo vedrà correttamente ma purtroppo, chi sta in rete locale non lo vedrà ancora.
Il problema in questo caso diventa il dns. Perchè? Perchè attualmente il dns risolve l' indirizzo ip pubblico e dato che in precedenza abbiamo modificato il pubblico in privato, non è piu' in grado di risolvere nessun nome.
Quindi ora l' obiettivo diventa fare in modo che il dns che usavo prima per risolvere gli indirizzi ip pubblici, risolva anche quelli locali.
Leggendo un po' di documentazione mi sono accorto che per fare ciò che desideravo, bind9 mette a disposizione le "viste" (view) che non sono altro che un modo per fare risolvere al dns la richiesta in base all' indirizzo di provenienza.
Mi spiego meglio:
dal pc (192.168.1.3) chiedo al dns di risolvere http://www.fabreg.it, lui si accorge che la mia richiesta arriva dall' iterno e usa la zona interna per risolvere fabreg.it Dal pc (192.168.1.3) chiedo al dns di risolvere http://www.debian.org, lui si accorge che debian.org non è locale e quindi chiede l' informazione a quello pubblico.
In questo caso abbiamo risolto il problema e potremmo tranquillamente visualizzare tutti i siti, locali e non, che desideriamo.
Riporto il file /etc/named.conf modificato per usare le view:
acl internals {
127.0.0.0/8;
192.168.1.0/24;
192.168.0.0/24;
};
view "internal" {
allow-recursion { 192.168.1.0/24; 192.168.0.0/24; localhost; };
match-clients { internals; };
zone "." {
type hint;
file "/etc/bind/db.root";
};
// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "fabreg.it" IN {
type master;
file "/etc/bind/interno/fabreg.it";
allow-query { any; };
view "external" {
recursion no;
match-clients { any; };
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "fabreg.it" IN {
type master;
file "/etc/bind/esterno/fabreg.it";
allow-query { any; };
allow-transfer { 193.205.245/24; };
};
};
Naturalmente, dovrete creare due files di zona: nel mio caso /etc/bind/interno/fabreg.it
è quello che contiene la zona "locale" mentre /etc/bind/esterno/fabreg.it contiene la zona "pubblica" cioè quella con l' ip reale.
Questo è il file di zona interno /etc/bind/interno/fabreg.it
$ORIGIN .
$TTL 3600 ; 1 hour
fabreg.it IN SOA dns.fabreg.it. fabreg.fabreg.it. (
2007113001 ; serial
86400 ; refresh (1 day)
1800 ; retry (30 minutes)
604800 ; expire (7 days)
3600 ; minimum (1 hour)
)
$TTL 86400 ; 1 day
NS dns.fabreg.it.
NS dns2.nic.it.
A 192.168.1.2
MX 10 mail.fabreg.it.
$ORIGIN fabreg.it.
@ IN TXT "v=spf1 a mx ip4:192.168.1.2 mx:mail.fabreg.it -all"
dns A 192.168.1.2
ftp A 192.168.1.2
mail A 192.168.1.2
www A 192.168.1.2
jofw A 192.168.1.2
e questo invece è quello esterno:
$ORIGIN .
$TTL 3600 ; 1 hour
fabreg.it IN SOA dns.fabreg.it. fabreg.fabreg.it. (
2007113001 ; serial
86400 ; refresh (1 day)
1800 ; retry (30 minutes)
604800 ; expire (7 days)
3600 ; minimum (1 hour)
)
$TTL 86400 ; 1 day
NS dns.fabreg.it.
NS dns2.nic.it.
A 79.14.247.194
MX 10 mail.fabreg.it.
$ORIGIN fabreg.it.
@ IN TXT "v=spf1 a mx ip4:79.14.247.194 mx:mail.fabreg.it -all"
dns A 79.14.247.194
ftp A 79.14.247.194
mail A 79.14.247.194
www A 79.14.247.194
jofw A 79.14.247.194
A questo punto, tutto dovrebbe funzionare correttamente.
Ciao!
--Fabrizio
