نمایش نتایج: از شماره 1 تا 3 از مجموع 3

موضوع: A Web Site Using ISA Server

  
  1. #1
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272

    A Web Site Using ISA Server

    کد:
    http://www.isaserver.org/tutorials/A_Web_Site_Using_ISA_Server_Part_1_Preparing_To_Publish_Your_Site.html
    Part 1: Preparing To Publish Your Site

    SA Server allows you to make internal resources, such a web servers, email servers and FTP servers, available to Internet users. This process of making internal services available to users on an external network is called “Publishing”. When you Publish a service on your internal, private network, you allows selective access to external users.
    The actual procedure for publishing a service is very easy, as it is wizard driven. However, before you publish, you have to make sure a couple of infrastructure issues and ISA Server components are set up before you successfully publish your site. In this article we’ll look at the preparations you need to make before publishing a web site.
    Prior to publishing your site, you need to deal with the following issues:

    • DNS Entries
    • Destination Sets
    • ISA client configuration
    • ISA Server Inbound Web Request Listener

    Let’s look at each of these issues and how to handle them before beginning the actual publishing of our web site.


    DNS Entries

    Users on the Internet will access your published web site via a Fully Qualified Domain Name (FQDN), such as www.isaserver.org. That FQDN must be translated to an IP address before the user can connect to your site. This is the job of a DNS Server. Before you publish your site, you must have a DNS entry for your site on a publicly available DNS server.
    Most people will have DNS entries handled by their ISP. You do have the option of hosting your own public DNS Servers. If you are managing your own public DNS servers (and you must have two, although some people cheat and report two IP addresses on the same server), you need to include a Host (A) entry for the internal web server you wish to publihs. For example, if you are managing your own DNS, and have a zone for "domain.com", you must create a Host (A) record for "www", if you wish people to access your internal web server www.domain.com.
    Your site may also be accessible via multiple names, such as ftp.domain.com, www.domain.com, and mail.domain.com. You can enter multiple Host (A) entries; one for each host name, or you can make a single Host (A) entry and use CNAME (alias) records for the other names. The CNAME approach is a bit easier to manage if you change your IP address from time to time.
    Alternatively, you could forget about DNS entries, and make everyone connect to your web site via an IP address. While this is doable, most people can hardly remember their own phone number, much less a 12 digit IP address.
    Destination Sets

    Once you've got the DNS issues handled, you're ready to create a destination set for your site. A destination set is used by ISA Server to identify which site is requested by the external user. Remember, when working with destination sets and publishing, you are looking at it from the vantage point of the external user, not the internal user. The destination for the external user is going to the FQDN of your site.
    Let's say we want to create a destination set for our site. The internal server we want to publish will answer to the names mail.domain.com and www.domain.com. We can create a single destination set that contains all three of these destinations. Then we can use this destination set in our publishing rule.

    • Open the ISA Management console, and expand the Servers and Arrays node. The expand the Policy Elements node.
    • Right click on the Destination Sets node, click the New command and then click Set.
    • You'll be presented with the New Destination Set dialog box as it appears below.

    • Enter the name of the destination set in the Name text box. Enter a description for the destination set in the Description (optional) text box. You should put each of your destinations in the Description text box because it will make it easier for you to figure out what the destination set is pointing to when you configure your publishing rules. The reason for this is that the description information will appear in the wizards, making it easy for you to figure out what sites the destination set references.
    • To add a new destination to the set, click the Add button. You will see the Add/Edit destinationdialog box as seen below.

    • In the Add/Edit Destination dialog box, type in the FQDN for your site in the Destination text box. Note that you can use an asterisk as a wild card to represent all the host names in a domain. After entering the FQDN, click OK.

    After creating the destination set, it will appear in the right pane of the ISA Management console. When the ISA Server receives a request for one of these destinations, it will actually examine the headers in the request and see if it has the destination listed in the header included in a destination set for a published server.
    ISA Client Configuration

    The server you want to publish should be configured as a SecureNAT client. This is a departure from how it was done in Proxy Server 2.0, where the only way you could publish a server was by making the server a Winsock Proxy client and then hammering away at a wspcfg.ini file. ISA Server allows you to escape that pain by configuring published servers as SecureNAT clients.
    SecureNAT client configuration is easy. The only thing you need to do is set the default gateway on the server to an address that routes Internet bound requests to the internal interface of the ISA Server. If the published server is on the same logical network ID as the internal interface of the ISA Server, you can set the default gateway to be the IP address of the internal interface of the ISA Server. If the server to be published is on a logical network ID removed from the internal network interface of the ISA server, then you must configure the default gateway on the server to be a router interface that will route packets destined for the Internet to the internal interface of the ISA Server.
    If you are working with a routed network, you must make sure that the routing table on the ISA Server is properly configured before even setting up ISA Server. Remember that packets need to know the path from the ISA Server to all subnets on the internal network, and all the subnets need to know the path to the internal interface of the ISA Server. In order for the ISA Server to know the paths to the internal network IDs, you must configure the routing table on the ISA Server with the appropriate gateway address(es) for each of the internal network IDs. You must configure the routing table, because you cannot configure a default gateway on the internal interface. Windows 2000 supports a single network adapter with a default gateway, and that adapter must be the external interface of the ISA Server.
    Some services may not work correctly using SecureNAT. You'll see this if you plan on publishing certain Internet enabled multiplayer games. In this case, you'll need to configure the server as a Firewall Client and then configure a wspcfg.ini file on that server. If that sounds too painful, you can place the game server on a DMZ segment and create packet filters to allow the required ports (typically 'all open' when dealing with a non-secure game server).
    ISA Server Inbound Request Listener
    The ISA Server listens to incoming web requests on what is called the inbound request Listener. By default, the inbound web request Listener uses port 80 on the external interface of the ISA Server. You can change this if you like, but then everyone that needs to connect to your web site will have to include the port number is their request. If you want to make your site easy to access, don't change the default port number setting. Note that the requests accepted by the Inbound Request Listener are intercepted by the Web Proxy Service.
    You will have to add the inbound Listener for the IP address(es) that you want the ISA Server to listen on.

    • Open the ISA Server management console, expand the Servers and Arrays node, and then right click on your server. If you are running an array, right click on the array name. Then click the Properties command. In the dialog box that appears, click the Incoming Web Requests tab. You will see something like what appears below.

    • On the Incoming Web Requests page you make the configuration changes required for your inbound web request Listener. Note that you have two options, one is the Use the same listener configuration for all IP addresses and the second is Configure listeners individually per IP address. If you have multiple IP addresses bound to the external interface you should configure the Listeners separately. I like to configure the Listeners separately even if I have a single IP address, because I have a better idea of what's going on that way.
    • Select the Configure listeners individually per IP addresses and then click the Add button. That brings up Add/Edit Listeners dialog box. A completed configuration appears in the figure below

    • In the Server drop-down list box, select the name of the server. In the IP Address drop-down list box, select the IP address on the external interface that you want configured as a Listener. If you have multiple IP addresses bound to the external interface, you'll have several to choose from. Those that have already been configured as Listeners won't be available. You can configure an optional Display name to describe the Listener. The entries in the Authentication from allow you to configure authentication options if you wish users to authenticate against the ISA Server. Note that these options to not configure the authentication options available to authenticate against the web site. These options are for the ISA Server only. Note that configuring the options here does not automatically require authentication against the ISA Server; these options just make the various authentication types available if you decide to enable authentication.
    • Click OK, and you'll see something like what appears below.

    • The new Listener appears in the box containing all the configured Listeners. In the TCP Port box you can change the port number used by the Listeners. Note that this setting applies to all Listeners, not just the one you have selected in the box above. You cannot use a different Listener port number for each specific Listener; this setting is a global one. If you want to require that users are authenticated before accessing any internal web site, put a checkmark in the checkbox for Ask unauthenticated users for identification. Note that this is also a global option and cannot be configured on a per Listener basis.
    • Click Apply and you will see the ISA Server Warning text box as pictured below.

    • If you want the ISA Server to restart the service, choose the Save the changes and restart the service(s) option. If you want to restart the service yourself, choose the Save the changes, but don't restart the services(s) option. I like to select the latter option because when you let the ISA Server do it for you, it might take awhile before the server actually gets around to doing it. When you do it yourself, you know exactly when the service is restarted.

    Conclusion

    You can publish services located on your internal network using the publishing wizards included with ISA Server. This includes a special publishing wizard that is dedicated to publishing web sites on the internal network. The wizard makes it easy to publish these internal web sites. However, there is some footwork you need to take care of before actually publishing the site. In this article we covered some of the key preparatory elements that need to be completed before publishing your web site.
    In the second part of this two part series on web publishing, we'll go over the actual steps you perform when publishing a web site, and examine some of the standard and non-standard procedures you can carry out to publish your site. See you then!









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

  2. #2
    نام حقيقي: 1234

    مدیر بازنشسته
    تاریخ عضویت
    Jul 2009
    محل سکونت
    5678
    نوشته
    5,634
    سپاسگزاری شده
    2513
    سپاسگزاری کرده
    272
    کد:
    http://www.isaserver.org/tutorials/Publishing_A_Web_Site_Using_ISA_Server_Part_2.html
    Part-2

    n the first part of this two part series, we took a look at some of the things you need to do before publishing your server. If you missed the first part, go and read it now by clicking here. In that article, we covered the importance of taking care of the = following issues:

    • DNS Configuration
    • Destination Sets
    • ISA Server client configuration
    • ISA Server Inbound Request Listener
    After these elements are configured, you are ready to publish your = Web Server.



    Publishing a Web Server Located on the ISA Server
    Publishing a web site located on the ISA Server entails some special problems you must address before you begin publishing. By default, IIS wants to use Port 80 to listen for inbound web requests. However, since the ISA Server's Web Proxy service uses Port 80 to Listen for inbound web requests, you cannot have both the ISA Server and the IIS WWW Service both listening on the same port.
    To solve this problem, you should configure IIS to listen on the internal interface of the ISA Server. This prevents a conflict with the Web Proxy service's Inbound Web Requests Listener. However, if you are publishing Autoconfiguration information on the internal interface of the ISA Server, it will use Port 80 by default. You could change the Port number that ISA Server uses to listen for Autoconfiguration requests and try to make it work that way. However, from our experience with ISA Server, it does not seem to want to work on the internal interface's Port 80. This may be a problem related to the configurations we have worked with, but we have never been able to publish a web site on Port 80 of the internal interface, in spite of the documentation saying this is possible.
    So, the first thing you should do is change the IP address and Listening Port number that IIS uses to listen for inbound web requests.
    Readying IIS For Publishing

    1. Open the Internet Services Manager from the Administrative Tools Menu.
    2. You'll see what appears in the figure below.

    3. In the IP Address drop-down list box, click the down-arrow and select the IP address of your internal interface. In the TCP Port text box type in a Port number that is not already in use. You can determine which Ports are already in use by opening a command prompt and typing netstat -na. This will list all currently open ports. Note that Ports listening on 0.0.0.0 are listening on all interface. You'll be fairly safe if you use a high number port, because relatively few of those are used by Windows network services. But make sure first!
    4. After making the changes to the IP Address and Port number, stop and then restart the WWW Service. You can do this via the control buttons in the Internet Information Services console.
    Now that IIS is ready, we can get to the job of Publishing our web site.
    Creating a Web Publishing Rule
    To create a Web Publishing Rule, we can take advantage of the Web Publishing Wizard. Perform the Following steps to publish your web site.

    1. Open the ISA Management console, expand the Servers and Arrays node, and then expand your server or array name.
    2. Expand the Publishing node, and then right click on the Web Publishing Rules node. Click on the New and then on the Rule command. This will start the Web Publishing Wizard.
    3. On the first page of the wizard, you'll type in the name of the rule, as we've done in the figure below.

    4. Click Next. On the Destination Sets page, Select the Specified destination set option, and then select the name of the destination set that you want to use for this publishing rule. You will see something like what appears in the figure below.

    5. Note that I have included in the description of the destination set the URL that will be used to access the published web site. Its always a good idea to include the URLs that are being used in the destination set in the description box. That way, you'll know exactly what URLs are being used by the destination set when you configure your publishing rules. Click Next.
    6. This takes you to the Client Type page. If you want everybody in the world to be able to access the web site, select the Any request option. If you want to limit who can access the site, select Specific computer (client address sets) or Specific users and groups option. You might want to limit site access if you are making it available only to partners. The Client Type page should look like what appears below.

    7. After configuring the client type, click Next. This takes you to the Rule Action page. On this page, you configure how you want ISA Server's publishing rule to handle inbound requests for the URLs included in the destination set. Select the Redirect the request to this internal Web server (name or IP address). Note that if you use a name, rather than an IP address, the internal interface of the ISA Server must be configured with a DNS Server address that can resolve the name. You might be able to get away with the NetBIOS name resolution sequence, but don't tempt fate. Make sure your DNS infrastructure is in place before working with ISA Server.

      Change the Port number in the text box for Connect to this port when bridging request as HTTP to the port number that you configured in IIS for the web site. You can change the other options if you need to, if you made changes to the other ports in IIS. The dialog box should look like the figure below.

    8. On the last page of the wizard you can confirm your settings. If all looks good, click Finish.
    Now, when we type in the URL www.isa.tzo.com we see the following:

    Note that I've changed the default page on the ISA Server that I published. This helps me know what web site and server I am accessing. Changing the default page to give server identification information is a good idea if you're working with a number of publishing rules and servers and you need to get a grip on "which is which". After everything is configured and working correctly, you can change the default page on your IIS web sites to reflect the actual content you want to present to the public or your partners.
    Note that you can see the connection request in the ISA Management console, as seen below.

    In this example, the domain name for the published server is isa.tzo.com. TZO allows you to dynamically register your domain name if you happen to be stuck with a connection that uses a dynamically assigned IP address. Each time your IP address changes, the TZO client software registers your new IP address with the TZO dynamic DNS server. This is quite helpful for those of you with DHCP assigned IP addresses on your external interface. Another cool thing about TZO is that they assign a wildcard entry for your host name. That means you can use www, mail, ftp, or nntp or any other host name you want, and it will resolve to the external IP address of your ISA Server. Note that if you wish to use the TZO service, you will have to create a packet filter to support the service on the ISA Server.
    For more information about TZO and their dynamic DNS service, check out:
    www.tzo.com
    Publishing an Internal Server
    In the previous example we went over the procedure for publishing a web server located on the ISA Server itself. This time, we'll publish an internal web server; that is, a web server located on our private network. Publishing an internal server is not quite a difficult, because you can use the default Port number of the internal server, if you wish. You can publish multiple sites on the internal web server by placing them on different ports, and then using a different destination set and web publishing rule for each one. Another option supported by ISA Server is to publish multiple sites using different host headers.
    Perform the following steps to publish an internal web server:

    1. As in the last example, open the ISA Management console, and right click on the Web Publishing Rules node. Click New then click Rule.
    2. On the first page of the Web Publishing Wizard, type in a name for your rule, then click Next.
    3. On the Destination Sets page, select Specified destination set and then choose the destination set you want to use. In this example, we have configured a destination set that we will use to connect to our internal web server EXETER. Your dialog box should look something like that seen below.

    4. On the Client Type page, select the appropriate client type and click Next.
    5. On the Rule Action page, select the Redirect the request to this internal Web server (name or IP address). Then, type in the IP address of the internal web server. If you are using Host Headers to create multiple sites on your IIS Server, be sure to select the Send the original host header to the publishing server instead of the actual one (specified above). What this means is that the host header will include the name in the original request, rather than the request containing the name or IP address of the internal server. In this way, multiple web sites that are configured by using host headers on the internal server will work correctly. Your dialog box should look something like that below.

    6. Click Next. Confirm your choices and then click Finish.
    Confirm that your Web Publishing Rule is configured correctly by typing the URL in the destination set for your server in your browser. You'll see success as we see below!

    Parting Thoughts:
    Publishing a web site using ISA Server is a simple process can be done using the Web Publishing Wizard. While the actual publishing of the site is easy, there are a lot of places that you can mess up if you haven't done the footwork in advance to prepare the site for publishing.
    One thing that catches a lot of people is DNS configuration. Remember the Firewall Clients will use the DNS entry on the external interface on the ISA Server, but SecureNAT Clients use the DNS configuration on the SecureNAT client itself. The vast majority of the servers you publish should be configured as SecureNAT clients, so be sure to configure them with a DNS server that can resolve Internet names.
    Another thing that often catches people is how destination sets are used in publishing rules. The reason is that we spend most of our time creating destination sets to control outbound access. However, when we configure destination sets to support web publishing, we have to look at it from the other way around. We have to look at the destination from the viewpoint of the person on the Internet making the inbound request. You must use the FQDN that external users will use to access your published web site.
    In a future article, I'll cover some issues related to processing path statements, and we'll go through examples of how you publish sites that include path statements. Until then, happy publishing!







  3. #3
    نام حقيقي: ali reza

    عضو عادی
    تاریخ عضویت
    Jun 2008
    محل سکونت
    shiraz
    نوشته
    335
    سپاسگزاری شده
    17
    سپاسگزاری کرده
    15
    سلام پاتریس جان ، ممنون
    این سایت رو قبلاً چک کرده بودم . خودم فکر کنم توی publish مشکلی نباشه. چون وقتی که از توی آیزا log می گیرم close connection رو بهم میده. نمی دونم مشکل از کجاست



کلمات کلیدی در جستجوها:

publish web

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •