Starten wir mit dem Push des Nameservers:
Es gibt dazu nun verschiedene Ansätze,
1. Man pflegt einen Nameserver auf dem Gateway in zen und übergibt ihn den anderen Clients wo gewünscht, z.B. fi1. In diesem Fall muss man dem Nameserver auf dem fi1-Gateway den Nameserver des zen-Gateways als ersten Forwarder eintragen, damit die Netzwerkteilnehmer in fi1 eine Namensauflösung bekommen. Der Nameserver in zen muss dann aber auch fi1 enthalten. Ist der VPN aber offline, hat fi1 keine lokale Namensauflösung.
2. Man konfiguriert den Nameserver auf dem fi1-Gateway als Slave von zen. Damit werden alle Zonen auch auf fi1 abgebildet, Änderungen an zens Nameserver übertragen.
3. Man pflegt beide Nameserver nach eigenem Gusto
4. Ein push an einen ho-Client ist ohne weitere Massnahmen möglich und sinnvoll. Meldet sich ein Client/Laptop unter ho1 an, bekommt er den Nameserver von zen und kann sofort auf alle erlaubten Ressourcen mit seinen FQDN’s zugreifen. Meldet er sich wieder ab, werden alle Anfragen wieder an den Nameserver des lokalen Netzwerkes geleitet.
Neu ist an dieser Stelle nur die Nummer mit dem Slave. Dazu reicht es bei Bind9 aus, die named.conf Dateien von zen nach fi1 zu kopieren und wie folgt zu bearbeiten:
root@gateway:/etc/bind# cat named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
1.1.1.1; 1.0.0.1;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on port 53 { 127.0.0.1; 10.0.0.1; 10.0.1.1; };
listen-on-v6 { none; };
// Accept requests for internal network only
allow-query { 127.0.0.1; 10.0.0.0/24; 10.0.1.0/24; 10.1.0.0/16; }; mit 10.1.0.0/16 erlauben wir nun allen VPN-Subnetzen den Zugriff
};
root@gateway:/etc/bind# cat named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
zone "erstes.netz" {
type master;
file "/etc/bind/erstes.netz.db";
notify yes;
allow-transfer { 10.0.3.1; };
};
zone "0.0.10.in-addr.arpa" {
type master;
file "/etc/bind/0.0.10.in-addr.arpa";
notify yes;
allow-transfer { 10.0.3.1; };
};
root@fi1gateway:/etc/bind# cat named.conf.options
options {
directory "/var/cache/bind";
dump-file "/var/cache/bind/cache_dump.db";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
1.1.1.1; 1.0.0.1;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See https://www.isc.org/bind-keys
//========================================================================
dnssec-enable yes;
//dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on port 53 { 127.0.0.1; 10.0.3.1; };
listen-on-v6 { none; };
// Accept requests for internal network only
allow-query { 127.0.0.1; 10.0.3.0/24; };
};
root@fi1gateway:/etc/bind# cat named.conf.local
//
// Do any local configuration here
//
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
include "/etc/bind/blacklists";
zone "erstes.netz" {
type slave;
file "/etc/bind/erstes.netz.db";
masters {10.0.0.1;};
};
zone "0.0.10.in-addr.arpa" {
type slave;
file "/etc/bind/0.0.10.in-addr.arpa";
masters {10.0.0.1;};
};
Relativ simpel, oder? Beide Nameserver neustarten. Nun schiebt gateway die ZonenDateien auf fi1gateway und unser Nameserver in fi1 ist zen-kompatibel. Wichtig ist nur: An den beiden ZonenDateien auf fi1 darf nicht händisch rumgemacht werden.
Das Ganze impliziert aber natürlich auch die korrekten Regeln für Shorewall, schauen wir uns dazu unsere rules-Dateien an:
root@gateway:/etc/shorewall# nano rules
#
# DNS settings for the VPN
#
DNS(ACCEPT) fw vpn
DNS(ACCEPT) vpn fw
Analog auf dem VPN-Server:
#
# DNS settings for the VPN
#
DNS(ACCEPT) zen fi1
DNS(ACCEPT) fi1 zen
und auf dem fi1gateway:
#
# DNS settings for the VPN
#
DNS(ACCEPT) fw vpn
DNS(ACCEPT) vpn fw
DNS(ACCEPT) loc fw
Wobei natürlich die Zonen auf dem VPN-Server entsprechend benannt sein müssen, während auf den Gateways die Zone einfach vpn heissen darf. Somit regelt Shorewall auf den Gateways immer „nur“ den Zugriff auf den VPN-Server, während Shorewall auf dem VPN-Server regelt welche Client-Zone wohin und was darf.
Zum Schluss ein paar Beispiele wie jetzt weitere Regeln gesetzt werden können.
next > Kontrolle