Many systems will have multiple networks that are isolated by firewalls. These firewalls will frequently hide the network addresses of the hosts behind them unless the Administrator has specifically configured the firewall to allow external access. In some networks the Administrator will place hosts with externally available Servers outside the firewall as shown in Figure 33.
In this configuration Servers running on the publicly visible network will have the same network address from the perspective of all Clients which means the URLs returned by DiscoveryServers are not affected by the location of the Client.
In this configuration the address of the Server that the Internet Client sees will be different from the address that the internal Client sees. This means that the Server’s DiscoveryEndpoint would return incorrect URLs to the Internet Client (assuming it was configured to provide the internal URLs).
Administrators can correct this problem by configuring the Server to use multiple HostNames. A Server that has multiple HostNames shall look at the EndpointUrl passed to the GetEndpoints or CreateSession services and return EndpointDescriptions with URLs that use the same HostName. A Server with multiple HostNames shall also return an Application Instance Certificate that specifies the HostName used in the URL it returns. An Administrator may create a single Certificate with multiple HostNames or assign different Certificates for each HostName that the Server supports.
Note that Servers may not be aware of all HostNames which can be used to access the Server (i.e. a NAT firewall) so Clients need to handle the case where the URL used to access the Server is different from the HostNames in the Certificate. This is discussed in more detail in OPC 10000-4.
Administrators may also wish to set up a DiscoveryServer that is configured with the ApplicationDescriptions for Servers that are accessible to external Clients. This DiscoveryServer would have to substitute its own Endpoint for the DiscoveryUrls in all ApplicationDescriptions that it returns when a Client calls FindServers. This would tell the Client to call the DiscoveryServer back when it wishes to connect to the Server. The DiscoveryServer would then request the EndpointDescriptions from the actual Server as shown in Figure 35. At this point the Client would have all the information it needs to establish a secure channel with the Server behind the firewall.
In this example, the DiscoveryServer outside of the firewall allows the Administrator to close off the Server’s DiscoveryEndpoints to every Client other than the DiscoveryServer. The Administrator could eliminate that hole as well if it stored the EndpointDescriptions on the DiscoveryServer. This allows an Administrator to configure a system in which no public access is allowed to any application behind the firewall. The only access behind the firewall is via a secure connection.
The UA AddressSpace supports references between Nodes that exist in different Server AddressSpace spaces. These references are specified with a ExpandedNodeId that includes the URI of the Server which owns the Node. A Client that wishes to follow a reference to an external Node should map the ApplicationUri onto an EndpointUrl that it can use. A Client can do this by using the GlobalDiscoveryServer that knows about the Server. The process of connecting to a Server containing a remote Node is illustrated in Figure 36.