کد:
http://www.isaserver.org/tutorials/Publishing_Multiple_Web_Sites_using_Web_Publishing_Rules.html
f you haven’t been able to tell by now, the feature I like the most about ISA Server is Web Publishing. Web Publishing Rules allow you to do allow you to do all sorts of things you can’t do with Server Publishing Rules. Here are just a few of the cool tricks you can do with Web Publishing Rules: Publish multiple Web sites with a single IP address on the external interface of the ISA Server
Perform port redirection to allow internal Web servers to listen on alternate port numbers
Perform protocol redirection that allows incoming HTTP or HTTPS requests to be forwarded as FTP requests
Carry out SSL bridging – this allows you to terminate an SSL connection on the external interface of the ISA Server and then bridge that connection as either HTTP or SSL to the internal network server
Use basic, integrated, digest or client certificate authentication to gain access to an Incoming Web Requests listener
Impersonate internal Web servers by binding the Web server certificate to the Incoming Web Requests listener used to accept requests for the internal Web server
The Web Proxy service provides the intelligence behind Web Publishing Rules. Unlike Server Publishing Rules, Web Publishing Rules take advantage of the Web Proxy service’s ability to examine HTTP header information and make decisions about how to route requests based on header information.
For example, the Web Proxy service is able to take the destination URL contained in an incoming request and compare that to URLs included in Destination Sets that are part of Web Publishing Rules. The first Web Publishing Rule that contains a matching URL in its Destination Set is applied to the incoming request.
You can publish multiple internal Web servers using a single IP address on the external interface of the ISA Server. You must use Web Publishing Rules to accomplish this task. Web Publishing Rules depend on the Web Proxy service, which means you have to install the ISA Server in either Integrated or Web Caching mode. You can’t create Web Publishing Rules if you install the ISA Server in firewall mode.
The figure below shows a typical Web Publishing scenario. The ISA Server is installed in Integrated mode and there are two IP addresses bound to the external interface. In this example, the external IP addresses are
1.1.1.1 and
1.1.1.2. There are three physical servers on the internal network that house a total of 4 Web sites.
Server1 has a single Web site, as does
Server2. There are two Web sites on
Server3. One of the Web sites listens on TCP port
80 and the other Web site listens on TCP port
8866.
Things you need to take care of when publishing multiple Web sites include:
Creating Public DNS Server Records
Configuring the Incoming Web Requests listeners
Creating the Web Publishing Rules
Let’s look at each of these issues in more detail.
---------------------------------
Creating the Public DNS Records
---------------------------------
This is probably the most troublesome issues for neophyte ISA Server administrators. It’s imperative that you have public DNS entries for the sites that you want to publish using Web Publishing Rules. The Web Proxy service needs to evaluate FQDNs in the URLs it processes (as well as the path) to make intelligent decisions regarding which Web Publishing Rule should be assigned responsibility for an incoming request.
You cannot use IP addresses in your Destination Sets if you want to publish multiple Web sites with a single IP address on the external interface of the ISA Server.
In our current example, we need to create the following Host (A) records on a public DNS Server (the DNS server can be hosted by a third party, or you can host your own DNS server, its doesn’t matter who hosts the server; what’s important is that the server is publicly accessible):
www.domain.com 1.1.1.1
web1.domain.com 1.1.1.1
web2.domain.com 1.1.1.2
web3.domain.com 1.1.1.2
Notice that
www.domain.com and
web1.domain.com both resolve to the same IP address and
web2.domain.com and
web3.domain.com resolve to the same IP address. This doesn’t create problems for Web Publishing Rules because the Web Proxy service can decide how to handle incoming requests based on the URL contained in the request.
---------------------------------
Creating the Incoming Web Requests Listeners
---------------------------------
The Web Proxy service depends on an Incoming Web Requests listener to accept incoming HTTP connections. You can access the Incoming Web Requests listener configuration interface by right clicking on your server name in the
ISA Management console and clicking the
Properties command. Click on the
Incoming Web Requests tab and you’ll see what appears below.
If you have a single IP address bound to the external interface of the ISA Server, you can select the
Use the same listener configuration for all IP addresses option, since the single IP address represents all of your IP addresses. You should select the
Configure listeners individually per IP address option if you have more than one IP address bound to the external interface of the ISA Server. While you don’t have to do it this way, configuring each IP address as an individual listener provides you a lot more flexibility.
Click the
Add button to access the
Add/Edit Listeners dialog box. Select your
Server name, select the
IP Address and type in a
Display name. You have the option to
Use a server certificate to authenticate to Web clients. This option allows you to bind a Web Server certificate to this Incoming Web Requests listener, which sets things up so the listener can impersonate the Web server on the internal network. Select the authentication methods you want to support. If you select the
Basic or
Digest authentication methods, I highly recommend that you select a default domain, as this will improve performance.
Click
OK in the
Add/Edit Listeners dialog box. This added the first listener. I’ll repeat the process so that we have separate listeners for
1.1.1.1 and
1.1.1.2. The figure below shows what the
Incoming Web Requests listener tab looks like after the two listeners are configured.
It’s important to note that the Incoming Web Requests listener represents a socket which accepts incoming HTTP requests. There is
no direct connection between a particular Web Publishing Rule and a specific Incoming Web Requests listener. That is to say, you don’t configure a Web Publishing Rule to use a specific Incoming Web Requests listener. The listener that services a particular request is determined by name resolution for the FQDN the external user uses to access the Web site.
For example,
www.domain.com resolves to
1.1.1.1. Whenever someone tries to access
www.domain.com, they will connect with the Incoming Web Requests listener that uses IP address
1.1.1.1. The listener accepts the request and forwards it to the Web Proxy service. The Web Proxy service compares the URL (which in this case is
www.domain.com) in the request with the URLs contained in the Destination Sets in the Web Publishing Rules. If there’s a match, the matching rule determines how the request is handled.
---------------------------------
Creating the Web Publishing Rules
---------------------------------
Let’s look at our network diagram again:
What we want to do is create four Web Publishing Rules. Two of the rules will use the Incoming Web Requests listener using
1.1.1.1, and two of the rules will use the Incoming Web requests listener using
1.1.1.2. Let’s take a close look at the rules.
Web Publishing Rule1
This rule uses a Destination Set that contains the URL
www.domain.com. The FQDN
www.domain.com resolves to
1.1.1.1. When the Incoming Web Request listener picks up the request for
www.domain.com, it will forward it to the Web Proxy service. The Web Proxy service will find that
Web Publishing Rule 1 uses a Destination Set containing the URL
www.domain.com. This rule is configured to redirect the request the internal network Web server named
Server1 on its
TCP port 80.
Web Publishing Rule 2
This rule uses a Destination Set that contains the URL
web1.domain.com. The FQDN
web1.domain.com resolves to
1.1.1.1, which is the same IP address used by
www.domain.com and
Web Publishing Rule 1. However, when the Incoming Web Requests listener on IP address
1.1.1.1 picks up this request, it forwards the request to the Web Proxy service and the Web Proxy service see the URL as
web1.domain.com. The
Web Publishing Rule 2 is configured to redirect the request to the internal network server
Server2 on its
TCP port 80. Notice the magic performed by the Web Proxy service! Requests for
www.domain.com and
web1.domain.com arrive at the same IP address on the external interface of the ISA Server and the Web Proxy service can decide what to do with the requests because
they have different URLs. This is why you
never want to use an IP address in the Destination Sets you use to publish Web sites.
Web Publishing Rule 3
This rule uses a Destination Set that contains the URL
web2.domain.com. The FQDN
web2.domain.com resolves to
1.1.1.2. When the Incoming Web Request listener picks up the request for
web2.domain.com, it will forward it to the Web Proxy service. The Web Proxy service will find that
Web Publishing Rule 3 uses a Destination Set containing the URL
web2.domain.com. This rule is configured to redirect the request the internal network Web server named
Server3 on its
TCP port 80.
Web Publishing Rule 4
This rule uses a Destination Set that contains the URL
web3.domain.com. The FQDN
web3.domain.com resolves to
1.1.1.2, which is the same IP address used by
web2.domain.com and
Web Publishing Rule 3. However, when the Incoming Web Requests listener on IP address
1.1.1.2 picks up this request, it forwards the request to the Web Proxy service and the Web Proxy service see the URL as
web3.domain.com. The
Web Publishing Rule 4 is configured to redirect the request to the internal network server
Server3 on its
TCP port 8866. Again, note the magic performed by the Web Proxy service! Requests for
web3.domain.com and
web2.domain.com arrive at the same IP address on the external interface of the ISA Server and the Web Proxy service decides what to do with the requests because
they have different URLs. In this case,
Web Publishing Rule 4 forwards the request to the same server on the internal network that
Web Publishing Rule 3 does, but it forwards it to a different port number. This is one example of the type of port redirection you can do with Web Publishing Rules.
---------------------------------
Summary
---------------------------------
Web Publishing Rules allow you to publish multiple Web sites using a single IP address on the external interface of the ISA Server. Publishing multiple Web sites using a single IP address on the external interface is easy, as long as you as you use FQDNs in your Destination Sets. Your attempts to publish multiple servers on the internal network with a single IP address will usually fail if you use IP addresses in the Destination Sets used by your Web Publishing Rules. Make sure your published servers have entries in the public DNS and that they resolve to IP addresses used by your Incoming Web Requests listeners.