کد:
http://blogs.msdn.com/askie/archive/2008/12/18/understanding-directly-accessing-computer-specified-in-the-address-tab-on-isa-server.aspx
In the recent months, I have been getting involved in a number of customer cases related to the feature “Directly access computes specified in the Addresses tab” when configuring the Web Browser settings for the Internal Network object. There has been confusion over the purpose of this functionality and this post should clear the biggest misconceptions about this feature.
Misconception #1
The most common misconception is that if a domain or fully qualified domain name (FQDN) of a server is added to the list, then a client will never send traffic via the ISA server to it.
Answer: Not necessarily true, traffic could be sent to the ISA server depending on the network configuration.
Misconception #2
This is a method to create a list of servers and domains that I don’t want any of my users to go to.
Answer: This is not what this was intended for but stay tuned because I may show you how it can be done in another blog but it will be complicated and you will probably just want to create a deny rule for those sites or buy a 3rd party filtering product from one of our partners before it is all said and done.
The real purpose of this function is to allow the internal client’s web browsers access internal or intranet sites directly without having to be funneled through the web proxy or via the firewall client. In the diagram below, we see that the user’s system is CLIENT.FABRICAM.COM and the ISA 2006 server FQDN is PROXY.FABRICAM.COM. The network also has a private link to a partner’s network over at CONTOSO.COM.

Figure 1 -
The object here is to configure it so the client does not send traffic to the ISA 2006 server. Now, configuring the client can be done a number of ways. The client can be configured manually as below. This can be a very tedious and mundane way of doing this and should really only be used for testing or extremely small deployments. The client can also be configured via a group policy and via a PAC (Proxy Auto Configuration) file from the IEAK (Internet Explorer Administration Kit) located on a server running IIS.



Figure 2 -
Since this is about ISA server, the ISA administrator should use the centralized management functionality built into ISA. In our scenario, the administrator requirement is that all clients access the Fabricam Intranet sites directly bypassing the ISA server. Our hero, the ISA Administrator, opens the ISA 2006 console, navigates to the Networks tab, then to the Internal network object and goes into the properties as shown below. Our hero clicks the Add button and enters “*.fabricam.com”.

Figure 3 -
After applying the setting, we see that no traffic is going to the ISA 2006 as web proxy traffic. During the test, we see that the client is trying to get to the website intranet.fabricam.com. The assumption is that the URL is compared to the sites listed in “Directly access computes specified in the Addresses tab” and then it is final but the process is more complex than that. Initially, the URL is compared to the list and if there is no match, the client operating system then does a DNS query for intranet.fabricam.com. In our situation, a local internal address is returned and the client sends the traffic directly to the web server.
The ISA administrator has a new task to conquer. The requirement is to have the clients access the partner’s private extranet directly and bypass the ISA server. For this, we will have to take a look at the network diagram with the network addresses below:


Figure 4
The assumption is made that there are the appropriate network. The ISA Administrator configures the setting as shown below where he enters partner.contoso.com:

Figure 5
The client performs a test and is not able to access the partner.contoso.com website directly. What went wrong? Why is the ISA 2006 server denying the access to this site? Yes, the ISA Administrator did apply the changes. The ISA Administrator does a NSLOOKUP for partner.contoso.com and gets the IP Address that is not 172.16.10.100. Next test, ping 172.16.10.100 and this works. After a few calls, there is a DNS Stub Zone for contoso.com and with a Host record for partner.contoso.com with the corresponding IP address of 172.16.10.100.
Our hero checks the settings and discovers this:

Figure 6
The ISA administrator then adds the following network range for 172.16.100.0-172.16.100.255.

Figure 7 -
Let’s recap why his initial test failed. Although the URL partner.contoso.com matched what was in the list for direct access, the traffic still ended up going to the ISA server as web proxy traffic. Breaking this down, there is the initial pattern match, so initially, the session is not sent to the ISA server for it to resolve but to the client operating system’s TCP/IP stack where it goes through the process for DNS recursive resolution for partner.contoso.com. At this point, dns.fabricam.com does not have a record for this server and then does an iterative DNS request starting at the root DNS servers, eventually returning a public IP Address for the site. The client’s IP stack then goes through the ANDing process and then determines that that is not on the local subnet. The client will attempt a connection with http://<Public IP Address>/ instead of http:// partner.contoso.com/. Since http://<Public IP Address>/ is not a URL match to the direct access, the request is then forwarded to the ISA 2006 Web Proxy. To summarize, since the client could resolve the address locally, it essentially had to send it to the ISA server.
Why did the ISA administrator have to configure the Contoso subnet in the addresses tab? Logically, the Contoso subnet should be considered an internal routable subnet for the Fabricam users. Any client that is utilizing the WPAD and/or WSPAD functionality will have the settings to bypass the usage of the web proxy in the instance of traffic being sent to http://<Contoso IP Address range>/.
Note: This would also apply to HTTPS SSL traffic.
Whoa! Our hero realizes that there are clients that are running the Microsoft ISA Firewall Client. There are times when the clients need to access the Fabricam and Contoso subnets that use protocols other than HTTP, HTTPS and FTP (passive mode). The ISA Administrator then goes and configures the Domains tab to include the *.fabricam.com domain and partner.contoso.com FQDN as show below:

Figure 8 -
The ISA administrator now has all the pieces of the puzzle to allow the users to access internal resources without putting any extra burden on the ISA server. At this point, the internal network has been configured along with direct access to the partner network.
This blog was brought to you by Brennan Crowe. He is a Senior Support Engineer on the Microsoft Security team, specializing in ISA Server.
Regards,
The IE Support Team




موضوعات مشابه: