问题描述
SCENARIO
我正在使用IIS6运行多个网站.在其中一个站点上，我要添加一个用VS 2010创建的WCF Web服务(在VB.NET中).我们的网络服务器必须经过防火墙.该Web服务与ASPX页面一起运行.我相信这已经引入了NAT转换.
我有一个内部运行的Web服务，其访问方式如下:
http://192.168.23.10:90/PurchaseOrders/POService.svc
将IIS配置为应用90的标头-192.168.23.10
当前，我正在尝试使用最小的最小web.config文件，该文件几乎是默认文件，并且仅列出不带端点的服务名称.
我不在乎内部访问Web服务.我们所需要做的就是将服务公开给外部世界(例如，内部托管在192.168.23.10:90中，并通过防火墙以98.10.5.24的形式提供).
问题
现在，Web服务的外部Internet IP地址类似于98.10.5.24.人们不应该只输入裸IP地址就输入98.10.5.24:90.当我尝试从Internet访问Web服务时，发生以下错误:
没有协议绑定与给定地址http://98.10.5.24:90/PurchaseOrders/POService.svc''
协议绑定是在IIS或WAS配置的站点级别配置的.
这是标准错误消息，具有许多Internet博客上可用的修复".由于我已经删除了指向98.10.5.24的90的IIS标头，所以现在暂时应该会出现此错误.这样的更改几乎关闭了对Web服务的访问.
新观察(9/8/2012)-IP地址未翻译并因此导致错误似乎很奇怪.或者，但不太可能，错误消息将内部IP替换为外部IP.这可能是问题根源和解决方案的线索.
问题
1.防火墙是否需要打开端口90才能进行此工作...还是仅需要将IP地址公开为默认端口80?
2.即使从端口90馈送了98.10.5.24，端口80的IIS标头是否也需要包含98.10.5.24?3.端口90的IIS标头设置是否需要包括98.10.5.24?
4.我是否需要遵循针对相似"场景建议的任何编码更改?
5.是否可以对web.config文件进行更改以使其正常工作?
基本上，我只需要使外部Internet访问正常工作即可.前面的问题只是为了确保我概述了可能的问题.
谢谢.
SCENARIO
I am using IIS6 to run multiple web sites. On one of the sites I am adding a WCF web service created with VS 2010 (in VB.NET). Our webserver must go through a firewall. The web service is running alongside ASPX pages. I believe this had introduced a NAT conversion.
I have a web service running internally that is accessed like this:
http://192.168.23.10:90/PurchaseOrders/POService.svc
where the IIS is configured to apply a header for 90 -- which is 192.168.23.10
Currently, I am trying to use a bare minimum web.config file that pretty much is the default and simply lists the service name with no endpoints.
I don''t care about accessing the web service internally. All we need is that the service be exposed to the outside world (e.g., hosted internally 192.168.23.10:90 and made available through the firewall as 98.10.5.24).
PROBLEM
Now the external internet IP address for the web service is something like 98.10.5.24. People should not be typing in 98.10.5.24:90, just the bare IP address. When I try to access the web service from the internet the following error occurs:
No protocol binding matches the given address http://98.10.5.24:90/PurchaseOrders/POService.svc''
Protocol bindings are configured at the Site level in IIS or WAS configuration.
This is the standard error message that has many ''fixes'' available on internet blogs. This error was expected for now since I had removed the IIS header for 90 that pointed to 98.10.5.24. Such change had pretty much shut down access to the web service.
New Observation (9/8/2012) -- It seems odd that the IP address either wasn''t translated and hence caused the error. Alternatively, but less likely, the error message had internal IPs replaced with external IPs. Something here may be the clue to the source and cure of the problem.
QUESTIONS
1. Does the firewall need to open up port 90 to make this work ... or does the firewall merely need to expose the IP address as the default port 80?
2. Does the IIS header for port 80 need to include the 98.10.5.24 even though 98.10.5.24 is fed from port 90?
3. Does the IIS header settings for port 90 need to include 98.10.5.24?
4. Do I need to follow any coding changes recommended for "similar" scenarios?
5. Is there a change to the web.config file that will make this work?
Basically I just need to get the external internet access working. The foregoing questions are just to make sure I have the possible issues outlined.
Thanks.
推荐答案
<serviceHostingEnvironment multipleSiteBindingsEnabled ="true">
</serviceHostingEnvironment>
我们将Web服务移至默认端口80上运行，只是为了使配置更容易.正是端口80的IIS标头的添加触发了我们必须修复的错误序列.内部IP和外部IP需要一个标头-也许我们可以通过添加外部标头来避免所有麻烦-只是这样的更改似乎会在早期测试中引起问题.
创建主应用程序目录有一个副作用.我们必须删除两个http模块(而不是尝试修复任何问题):
We moved the web service to run on the default port 80 just to potentially make the configuration easier. And it was the addition of the IIS headers for the port 80 that triggered the sequence of errors we had to fix. A header was needed for the internal IP and for the external -- well maybe we could have avoided all the trouble by just adding the external header -- except that such a change seemed to cause problems in earlier testing.
There was a side-effect of creating the main application directory. There were two http-modules we had to delete (rather than try to fix anything):
<modules runAllManagedModulesForAllRequests="true">
<remove name="RadUploadModule" />
<add name="RadUploadModule" type="Telerik.Web.UI.RadUploadHttpModule" preCondition="integratedMode" />
<remove name="RadCompression" />
<add name="RadCompression" type="Telerik.Web.UI.RadCompression" preCondition="integratedMode" />
</modules>
据我所知，我们没有使用这些，所以当错误弹出时我才删除了它们.有趣的是，aspx网站的web.config在调用Web服务的过程中是如何自我插入的.但是这样的错误只是提醒我们，Web目录之间存在层次结构.
感谢您的关注和帮助.
We weren''t using these, as best as I could tell, so I just removed these when the error popped up. It is interesting to see how the aspx website''s web.config interjected itself in the process of calling the web service. But such error just reminds us that there is a hierarchy among the web directories.
Thanks for your interest and help.
这篇关于关于没有协议绑定被匹配的WCF Web服务返回错误的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！