Send dhcp-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.isc.org/mailman/listinfo/dhcp-users
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of dhcp-users digest..."
Today's Topics:
1. Re: Assigning fixed IP to generated VDI desktops (Miloslav H?la)
2. Re: Assigning fixed IP to generated VDI desktops (Simon Hobson)
3. Re: Sorry - obviously that last email was a mistake (Cathy Almond)
4. Re: Sorry - obviously that last email was a mistake (/dev/rob0)
----------------------------------------------------------------------
Message: 1
Date: Tue, 1 Nov 2016 15:07:05 +0100
From: Miloslav H?la <[email protected]>
To: [email protected]
Subject: Re: Assigning fixed IP to generated VDI desktops
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8; format=flowed
Dne 01.11.2016 v 11:47 Simon Hobson napsal(a):
> Miloslav H?la <[email protected]> wrote:
>
>> The basic steps are following:
>>
>> 1) prepare a golden image (the source Windows machine)
>> 2) generate the pool of windows desktops based on the golden
>>
>> Let's say, we are creating a pool of 50 office desktops. We are telling to
>> VMware: "Create office-01 to office-50 from golden". The process for every
>> new station is:
>>
>> a) Take golden with known MAC1 and hostname 'golden'.
>> b) Clone golden. The result is a windows machine with new random MAC2, but
>> hostname is still 'golden'.
>> c) Boot up new machine and run customization scripts. The result is the
>> hostname is changed to 'office-01'.
>> d) Reboot machine (and run some other scripts)
>> e) Power off the machine. It's done.
>>
>> We are assigning IP addresses by making classes based on host-name option
>> matching.
>>
>> The problem is, that in step b) we have machine with hostname 'golden' and
>> MAC2. So, DHCP server creates a lease for it from dynamic range. Then
>> machine reboots and have hostname 'office-01' and still MAC2 in steps c) and
>> d). Now we need to assign fixed IP by hostname, but there is already lease
>> for it and DHCP server offers this one.
>
> How about having a small pool, and "allow members of golden" where class
> "golden" is match on hostname="golden" ? Then on first boot, each new machine
> would get an address from this pool. Once it's changed it's hostname, it will
> no longer match that class and so will be denied access to that pool - so it
> will honour other assignments, if you get it all right, this will be your
> static IP.
We have separated IP pools already. One with public IP adresses for
office-XX machines and one with private IP addresses for temporary
in-the-middle-of-cloning machines. The private pool is defined with
'deny members of "office-01"; deny members od "office-02"; ...'. It is
hard to maintain. Thanks for the tip to do matching by contraries. Seems
like good idea.
>> My question is, is there some kind of prefences we could do? I read in
>> manual that priorities are host, class, pool, subnet, shared-network.
>
> Not so much priority, as inheritance. If anything is set in one level, then
> it will be inherited down the levels until it's either used or over-ridden by
> being set in a lower level. Thus, for example, you can set name-servers in
> the global scope and that will apply everywhere - but you could set it again
> in (say) a subnet declaration and it will apply in that subnet and any pools
> within it. And you could over-ride it again in a single pool.
>
>
>> And another questions, possibly not so related. We are running separated
>> DHCP server for VDI. And we have a two next DHCP servers in fail-over mode
>> for the rest of the network. The whole network has about 130 subnets and 100
>> VLANs. We would like to merge VDI DHCP server with the two others. The
>> question is, the host-name matching must work only for VDI VLAN. If I
>> understand manual correctly, class declarations are global. Could it be done
>> by subclasses?
>
> You will need to ensure that your assignment logic supports it. IFF you can
> be sure that no other host will have a host name "office-nn" then it is
> sufficient to define a class matching on that. However, since it is easy to
> set a hostname then someone could upset that.
> Presumably the MAC addresses all fall within one OUI (or a small number of
> OUIs), so you could extend the matching to that and thus exclude anything not
> running as a VM with that hypervisor type.
That's the plan. But it is still weak place for security, mainly for
WiFi access. On the other hand, WiFi is in another VLAN so attacker will
be without connectivity with such stolen IP.
>> And the last question. How DHCP server handles requests from DHCP relay? In
>> log we can see:
>>
>> - via eth0
>> - via eth1
>> - via 10.70.0.1
>>
>> I guess, that server fetches current eth0 or eth1 IP addresses and match the
>> subnets according to. Is it the same for the relay? Subnet is matched by the
>> relay IP address?
>
> Correct.
> For packets arriving "directly" at the server, it will log "via ethn" and use
> the subnet(s) defined on that interface to determine an appropriate subnet to
> consider for address allocation to the client. Where the request is relayed,
> the relay agent will fill in the GI-Addr (gateway Interface Address) field in
> the packet and the server will use that. The GI-Addr field *must* be an IP
> address within the subnet (or shared-network) to which the clients are
> connected.
>
> For a little light reading :D I strongly recommend The DHCP Handbook by Ralph
> Droms and Ted Lemon. There's a second edition, but this mostly adds stuff
> about failover - other than that, the first edition is still very usable.
> It's both very detailed and very readable - and starts with some history to
> explain the "WTF did we do it that way" elements of DHCP ! FWIW, both authors
> are respected in the DHCP field - Ted in particular had a big hand in writing
> the ISC server, at least the V3 version IIRC, and really knows what he's
> talking about.
Many thanks for your help and tips!
------------------------------
Message: 2
Date: Tue, 1 Nov 2016 14:20:28 +0000
From: Simon Hobson <[email protected]>
To: Users of ISC DHCP <[email protected]>
Subject: Re: Assigning fixed IP to generated VDI desktops
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Miloslav H?la <[email protected]> wrote:
>> You will need to ensure that your assignment logic supports it. IFF you can
>> be sure that no other host will have a host name "office-nn" then it is
>> sufficient to define a class matching on that. However, since it is easy to
>> set a hostname then someone could upset that.
>> Presumably the MAC addresses all fall within one OUI (or a small number of
>> OUIs), so you could extend the matching to that and thus exclude anything
>> not running as a VM with that hypervisor type.
>
> That's the plan. But it is still weak place for security, mainly for WiFi
> access. On the other hand, WiFi is in another VLAN so attacker will be
> without connectivity with such stolen IP.
Don't forget that, unless you get the config very badly wrong, a device in a
different network just won't match the subnet at all. So if your WiFo users are
on a different VLAN (ie different network) then they won't be considered for
your VDI pools at all even if they match the class statements. Thus they won't
be able to "steal" an IP.
------------------------------
Message: 3
Date: Tue, 1 Nov 2016 17:40:02 +0000
From: Cathy Almond <[email protected]>
To: [email protected]
Subject: Re: Sorry - obviously that last email was a mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
On 31/10/2016 23:14, Alan Buxey wrote:
> So not a subversive reminder to all of us that Kea is our there for us
> to use instead of the old server? ;)
>
> alan
No - we stopped using subversion quite some time ago ;)
------------------------------
Message: 4
Date: Tue, 1 Nov 2016 13:21:11 -0500
From: /dev/rob0 <[email protected]>
To: [email protected]
Subject: Re: Sorry - obviously that last email was a mistake
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Tue, Nov 01, 2016 at 05:40:02PM +0000, Cathy Almond wrote:
> On 31/10/2016 23:14, Alan Buxey wrote:
> > So not a subversive reminder to all of us that Kea is our
> > there for us to use instead of the old server? ;)
>
> No - we stopped using subversion quite some time ago ;)
Oh my. Only one thing I can say about a pun like that:
git out!
--
http://rob0.nodns4.us/
Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:
------------------------------
Subject: Digest Footer
_______________________________________________
dhcp-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/dhcp-users
------------------------------
End of dhcp-users Digest, Vol 97, Issue 2
*****************************************