[dhcpd] Wel of geen "routers" option dmv. 'pools'

[eymey]

De situatie is zo:

Ik heb een VPN opgezet, zodat "road warriors" verbinding kunnen maken met het kantoornetwerk. Dit doe ik m.b.v. OpenVPN (openvpn.sourceforge.net) met Ethernet Bridging aan de kant van de linux-server, zodat broadcasts tgv. Samba/Microsoft e.d. ook door komen.

Nou wil ik, netals de rest van de pc's op kantoor, ook de binnenkomende VPN'ers, die op dat moment op het netwerk een 'virtueel' mac-adres krijgen, via DHCP een IP adres geven. Als DHCP server gebruik ik de ISC DHCP Server V3.0pl2

Dit gaat in principe perfect: Als een windows-client vanaf een andere plek een verbinding maakt krijgt deze netjes een IP adres op het LAN. Er is alleen één probleem: Netals de andere pc's krijgt deze client ook een "gateway/default router" adres door.

Dit is natuurlijk niet nodig, en kan wellicht ook ongewenst zijn. Daarom wil ik dus op basis van MAC adres ervoor zorgen dat de VPN'ers via DHCP geen gateway-adres doorgestuurd krijgen.

Alle VPN mac-adressen beginnen met "00:FF". Hier moet dus op te filteren zijn. Een stukje uit mijn DHCPD config:

code:

class "openvpn" {
     match if substring (hardware, 1, 2) = 00:FF;
 }
## end class declaration

# subnet instellingen.
authoritative;

subnet 10.2.1.0 netmask 255.255.255.0 {
option subnet-mask 255.255.255.0;
option broadcast-address 10.2.1.255;
option domain-name "......";
option domain-name-servers 10.2.1.1;

pool {
     deny members of "openvpn";
     range 10.2.1.65 10.2.1.180;
     option routers 10.2.1.1;
     default-lease-time 86400;
     max-lease-time 151200;
     }
pool {
     allow members of "openvpn";
     range 10.2.1.210 10.2.1.240;
     default-lease-time 3600;
     max-lease-time 14400;
     }
}

Op zich werkt dit, qua uitgereikt IP adres goed: Alle members van de class "openvpn" krijgen netjes een IP adres uit de .210-.240 pool uitgereikt. De overige hardware krijgt gewoon een IP adres uit de .65-.180 pool.

Het probleem is alleen de gateway (option routers 10.2.1.1): De VPN clients krijgen nu, zoals bedoeld, geen gateway meer. Het probleem is alleen, dat de gewone pc's nu ook ineens geen gateway meer krijgen.

Kan de optie "option routers x.x.x.x" alleen maar binnen een algemene subnet-scope vallen en niet binnen een bepaalde 'pool' ofzo? Of zie ik iets anders over het hoofd? Of is er een andere manie rom te bewerkstelligen dat VPN'ers geen default gateway krijgen.

[eymey]

Ik doe nog maar een klein, maar beleefd schopje omhoog.

Ik hoop dat hier iemand rond hangt die hier ook wel eens mee te maken heeft gehad.

[AdLentis]

Ik ben even rond wezen kijken op het net, en er zijn wel DHCP daemons die deze configuratie zouden moeten ondersteunen, maar of de ISC server dat ook doet, weet ik niet.

De makkelijkeste work-around die je zou kunnen proberen is het (mis)bruiken van de netmasks:

edit: de subnets moeten dan wel in een shared network staan natuurlijk

code:

class "openvpn" {
     match if substring (hardware, 1, 2) = 00:FF;
 }
## end class declaration

shared network .... {
     # subnet instellingen.
     authoritative;

     # De eerste bit altijd hetzelfde...

     # Lokaal subnet: 115 adressen
     subnet 10.2.1.0 netmask 255.255.255.128 {
     option subnet-mask 255.255.255.0;
     option broadcast-address 10.2.1.255;
     option domain-name "......";
     option domain-name-servers 10.2.1.1;
     option routers 10.2.1.1;
     pool {
          deny members of "openvpn";
          range 10.2.1.12 10.2.1.127;
          default-lease-time 86400;
          max-lease-time 151200;
          }
     }

     # VPN subnet: 30 adressen
     subnet 10.2.1.0 netmask 255.255.255.128 {
     option subnet-mask 255.255.255.0;
     option broadcast-address 10.2.1.255;
     option domain-name "......";
     option domain-name-servers 10.2.1.1;
     pool {
          allow members of "openvpn";
          range 10.2.1.210 10.2.1.240;
          default-lease-time 3600;
          max-lease-time 14400;
          }
     }

}

Mocht je wat meer adressen willen reserveren voor dat eerste subnet, dan kan je het beste het 2e subnet verder opsplitsen, en daarvan dan een deel gebruiken.

[ Voor 21% gewijzigd door AdLentis op 02-06-2004 15:58 ]

[Verwijderd]

Even 'DHCP' naar 'dhcpd' veranderd om duidelijk te maken dat het niet om de DHCP-service in Windows Server System gaat

[eymey]

Ik heb de oplossing al gevonden. De originele code die ik postte bleek toch (bijna) goed te zijn. Ik heb nu echter wat meer opties binnen een "pool" definitie geplaatst en wat minder daarbuiten:

code:

# dhcpd.conf

# option definitions common to all supported networks...
ddns-update-style none;

## If hardware address begins with 00:FF, the client is an
## openvpn tap adapter, and we do not want to assign a
## default gateway or dns server.  Assign then to a special
## subclass and configure a pool which does not hand out
## these parameters.

class "openvpn" {
     match if substring (hardware, 1, 2) = 00:FF;
 }
## end class declaration

# subnet instellingen.
authoritative;

subnet 10.2.1.0 netmask 255.255.255.0 {
option domain-name "mf";
option domain-name-servers 10.2.1.1;

pool {
     deny members of "openvpn";
     range 10.2.1.65 10.2.1.180;
     option subnet-mask 255.255.255.0;
     option broadcast-address 10.2.1.255;
     option routers 10.2.1.1;
     default-lease-time 86400;
     max-lease-time 151200;
     }
pool {
     allow members of "openvpn";
     range 10.2.1.210 10.2.1.240;
     default-lease-time 3600;
     max-lease-time 14400;
     }
}

Blijkbaar moet een routers option in een bepaald blok dus toch gepaard gaan met een broadcast-address of subnet-mask ofzo. In ieder geval werkt het nu mooi.

De clients in het LAN krijgen nu gewoon netjes een default gateway en de VPN'ers niet.

Dit is dus weer een 'leuk' topic voor de anderen op tweakers.net, mochten ze ooit ook iets vergelijkbaars gaan doen, dacht ik zo

[eymey]

Helaas, ik heb te vroeg gejuigd

Alles leek goed te gaan met deze config: Ook bij herhaaldelijk "repair" gebruiken onder Windows XP en een release en renew achter elkaar, bleven de LAN clients netjes hun default gateway ontvangen.

Maar toen de leases van de diverse clients verlopen waren, en de clients opnieuw een DHCP gingen aanvragen, bleek hij toch ineens de default gateways niet meer mee te sturen