📜 ⬆️ ⬇️

DirectAccess in Windows 7. Part1

In my previous post I mentioned two, from my point of view, the most interesting innovations of Windows 7 - BranchCache and DirectAccess. BranchCache technology was reviewed last time. It is the turn of DirectAccess. However, along the way, it became clear that the material goes beyond one post. So for starters, I will focus on the features of DirectAccess and some of the issues of using IPv6.

What is DirectAccess?

DirectAccess is a technology for remote access to corporate network resources. From a consumer point of view, the essence of the technology can be expressed as follows: "As soon as my computer connected to the Internet, I immediately got access to both the Internet resources and the entire corporate network." In technical terms, when connected to the Internet, a user computer configured as a DirectAccess client (DA client) automatically establishes a tunnel to the DirectAccess server (DA server) and through it gains access to the entire corporate network. Does it differ in any way from traditional VPN solutions? Let's look at the features of DirectAccess and the technological basis of this solution, after which, I think, everyone will be able to answer this question for himself.
')
DirectAccess Features

The first very important feature is that no additional actions are required from the user. The tunnel between the client and the DirectAccess server is established automatically, and, as will be shown later, two tunnels are actually created: one to authenticate the computer, the second to authenticate the user. And this process is completely transparent to the user. No need to run any VPN connections, no need to enter credentials - username and password, pin code for smart card, etc. Moreover, if the connection to the Internet is lost for some time, and the tunnel is naturally broken. , and then restored (for example, an unstable WiFi signal), then again, automatically and without a user’s participation, the tunnel to the corporate network is also restored.

The second feature follows from the first, although perhaps this is not very obvious. As long as there is connection to the Internet, and there is a tunnel, a client computer is available for management by the company's IT services. In other words, thanks to DirectAccess, not only the user can constantly work with corporate resources, would be communication with the outside world, but other employees, primarily IT specialists, have access to the user's computer. The user is always “under the hood” at the IT services, which, probably, does not suit him very much, but the IT staff are very satisfied. :) From a practical point of view, this fact makes it possible to monitor the client machine — the scan of the anti-virus database, the latest updates, the included firewall, etc. — even if it is located outside the corporate network. On the other hand, manually breaking a DA-tunnel is not as easy as in the case of a VPN connection, which, as a rule, is visually displayed in network connections. That is certainly possible, but you need to know how.

Finally, by default, DirectAccess provides different routes to local, external, and corporate resources (see Figure 1). In many implementations, when a VPN connection is established, the default gateway address changes, and all traffic is chased to the VPN server, and from there to the Internet or corporate network. On the one hand, this slows down the speed of work with Internet resources, on the other hand, it can create certain problems with routing in a local network. DirectAccess is quite flexible in configuration, so you can both configure the split tunnel mode (the default) and wrap all traffic to the DA server.
image
Fig. one

Technological foundation

Let's now look at the technological solutions underlying DirectAccess. In fact, there are three:
1. IPv6 protocol for connecting a DA client with a DA server and Intranet computers.
2. IPSec over IPv6 for secure data transmission over the Internet / Intranet network.
3. Name Resolution Policy Table (NRPT) for correct resolution of internal (corporate) and external names.
The latter, by the way, allows the user, while on the Internet, to access internal resources by short names, for example: \\ corp-srv1 \ docs. We will discuss successively all three listed components.

IPv6

DirectAccess requires a configured IP version 6 protocol, at least on DA clients and DA servers. Do not rush to immediately finish reading, this does not mean that DirectAccess is not applicable under the current conditions of the almost undivided reign of IPv4 in our open spaces, and not only of our Internet.

Why at all was bet on IPv6? This protocol has many advantages, the most important of which is the lack of good old IPv4 flaws. :) Seriously, in relation to our topic, I would point out the following features of IPv6.

The first is a huge address space. What does it really give? Now all or almost all companies use one or more public IPv4 addresses in the perimeter network, while the computers on the internal network are set to any of the private address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0 /sixteen). It is likely that when connecting to the Internet via NAT, the remote computer will receive an address from the same range, which will make using split tunnel mode very difficult. A similar problem may arise when VPNs bind two remote offices using the same private IP subnet. The IPv6 address space allows you to assign a unique IPv6 address to any company host, and a unique one, not only within the corporate network, but throughout the Internet. As a consequence, there is no need for address translation, and you can stop using NAT altogether - it will only be about packet routing.

How safe is it to work without NAT? I understand that the question is more than debatable. But still. Let's remember that, first of all, NAT is intended to solve the problem of a shortage of public IPv4 addresses. This problem is not in IPv6. The second consequence of using NAT is hiding internal IP addressing. Hosts on the Internet “see” only IP addresses on the external interface of a NAT device. In case of rejection of NAT, the company will “spotlight” the real IPv6 addresses of the corporate network. Is this a security threat? In general, yes. The less an attacker knows about my network, the less potential troubles he may have. However, on the other hand, we are talking about remote client access to corporate resources. Firewalls have not been canceled, they still allow only certain traffic and are probably equipped with intrusion detection systems, prevention of port scanning, etc. In addition, hardly anyone will set up a tunnel for remote access without encryption. And here we need to remember about IPSec over IPv6. The DA server only accepts IPSec traffic. Default. You can always migrate. And when an IPSec connection is established, the server and the client mutually authenticate, first at the computer account level using digital certificates, then at the user account level using the corporate policy (password, smart card, fingerprints, etc.). Accordingly, knowledge of the specific IP address of the internal server will hardly greatly facilitate the task of penetration into the internal network.

Conversely, the rejection of NAT leads to another useful feature of the use of IPv6 - the possibility of secure point-to-point connections. Indeed, the standard solution in the case of NAT is a scheme (see Figure 2), in which an encrypted tunnel is established from, in this case, a DA client to a DA server. On the internal network, traffic is already transmitted in open form (red arrows), or it is again encrypted, but not by the client, but by the DA server.
image
Pic2

In the case of global IPv6 routing, an encrypted channel can be established between the DA client and the destination server, and the DirectAccess server only passes (routes) such traffic through itself (see Figure 3). This allows you to configure access rights to servers and at the computer level, and at the user level, in addition, "tightening the screws" security. The difficulty in implementing such a scheme when using address translation is that each IPSec packet has a digital signature that is broken when the NAT device tries to modify the packet. Although there is a solution to this problem, not every NAT device supports it.
image
Fig. 3

Well, another important point associated with NAT. Applications. You can easily encounter programs that do not work or work crookedly through NAT. Including, by virtue of incorrect resolution of internal and external names. The lack of NAT allows developers to forget about address translation issues and focus on the business logic of the application, and administrators to get rid of additional settings and applications and firewalls.
Thus, the “openness” of the IP addressing of your network and the advantages of the “world without NAT” that I tried to identify are on the scale. The choice, as always, is yours.

In the next post, I'll finish reviewing the technology foundation of DirectAccess. It will be about the use of IPv6 in an IPv4 environment, IPSec over IPv6 application options, features of the implementation of NRPT.

Source: https://habr.com/ru/post/105979/


All Articles