1
00:00:01,080 --> 00:00:02,680
IP Address Management, or IPAM.

2
00:00:02,680 --> 00:00:08,190
Let's take a look at some common IP address issues in hybrid environments.

3
00:00:08,190 --> 00:00:09,750
Now I've got six on this side.

4
00:00:09,750 --> 00:00:13,460
Of course, we can think of many more. One that springs to my mind as

5
00:00:13,460 --> 00:00:17,760
Internet Protocol v6. But fortunately, the exam focuses strictly on

6
00:00:17,760 --> 00:00:22,010
IPv4, and actually, the DHCP failover feature that we'll look at

7
00:00:22,010 --> 00:00:25,890
later in this lesson supports only IPv4 anyway. But when I'm

8
00:00:25,890 --> 00:00:27,640
thinking of a hybrid cloud,

9
00:00:27,640 --> 00:00:30,250
I'm thinking first of all is making sure that we never

10
00:00:30,250 --> 00:00:33,800
have the problem of IP address range overlap. With those

11
00:00:33,800 --> 00:00:36,790
RFC 1918 private IP addresses,

12
00:00:36,790 --> 00:00:41,210
the private IPv4 addresses that is, you have one or more of these ranges

13
00:00:41,210 --> 00:00:44,520
on‑prem, and then as you're extending your network into Azure,

14
00:00:44,520 --> 00:00:46,480
you have to think about that in terms of

15
00:00:46,480 --> 00:00:48,990
site‑to‑site VPN or ExpressRoute circuit,

16
00:00:48,990 --> 00:00:52,580
making sure that you're not overlapping to cause problems.

17
00:00:52,580 --> 00:00:54,890
Although in the Azure VNet world,

18
00:00:54,890 --> 00:00:58,090
your virtual networks could have overlapping ranges.

19
00:00:58,090 --> 00:00:59,960
That's going to present a problem, again,

20
00:00:59,960 --> 00:01:04,750
if you do peerings or VPN or ExpressRoute circuits. We also in

21
00:01:04,750 --> 00:01:08,610
Azure need to think about Azure public IP addresses. Common

22
00:01:08,610 --> 00:01:12,080
newcomer mistake I see people make is put public internet

23
00:01:12,080 --> 00:01:15,210
accessible IPs directly on their Azure VMs.

24
00:01:15,210 --> 00:01:16,630
Do you really want to do that?

25
00:01:16,630 --> 00:01:17,580
In my experience,

26
00:01:17,580 --> 00:01:22,330
you'll see RDP brute‑force attacks within minutes of exposing an Azure VM

27
00:01:22,330 --> 00:01:26,980
directly to the internet. With Dynamic Host Configuration Protocol, there's the

28
00:01:26,980 --> 00:01:31,190
notion of a rogue server. Maybe one of your development colleagues at work

29
00:01:31,190 --> 00:01:35,840
brings up a DHCP server for testing, and that person winds up creating an

30
00:01:35,840 --> 00:01:38,800
unwanted denial of service for other users.

31
00:01:38,800 --> 00:01:41,410
DHCP is a broadcast‑based protocol,

32
00:01:41,410 --> 00:01:45,360
so it's way too easy for a DHCP client to pick up an

33
00:01:45,360 --> 00:01:47,640
IP address from a DHCP server.

34
00:01:47,640 --> 00:01:50,590
How do you prevent that? With name resolution, we have rogue

35
00:01:50,590 --> 00:01:54,510
DNS servers and rogue DNS updates. Elsewhere in this course we

36
00:01:54,510 --> 00:01:56,800
looked at DNSSEC, for example,

37
00:01:56,800 --> 00:02:00,440
as a way to mitigate that rogue DNS update problem.

38
00:02:00,440 --> 00:02:04,690
But what do you have to prevent rogue DNS servers showing up

39
00:02:04,690 --> 00:02:06,840
in your environment? When we look at Azure,

40
00:02:06,840 --> 00:02:12,230
we have to recognize that currently, as of this recording in early 2022, the

41
00:02:12,230 --> 00:02:16,970
Azure public cloud has no inbox IP address management solution.

42
00:02:16,970 --> 00:02:20,870
It's a fully hosted architecture based on software‑defined

43
00:02:20,870 --> 00:02:22,700
networking. Elsewhere in this course,

44
00:02:22,700 --> 00:02:25,990
we learned about the Azure wire server that provides

45
00:02:25,990 --> 00:02:29,820
Azure‑based DHCP for your virtual networks.

46
00:02:29,820 --> 00:02:33,420
We don't have a way right now to have a single pane of

47
00:02:33,420 --> 00:02:36,240
glass management wise from Microsoft.

48
00:02:36,240 --> 00:02:38,370
It's unfortunate, but it's the truth. Now,

49
00:02:38,370 --> 00:02:41,920
this opens the way for third‑party independent software

50
00:02:41,920 --> 00:02:44,440
vendors, or ISVs. One that I know of,

51
00:02:44,440 --> 00:02:47,640
although I don't have any experience with using it yet is called

52
00:02:47,640 --> 00:02:51,810
EfficientIP. So there are third‑party vendors who do provide IP

53
00:02:51,810 --> 00:02:57,000
address management for hybrid cloud. We're just not there yet in the Microsoft world.