This page discusses SHRINE's networking requirements, which are valid for SHRINE versions 2.0.0 and later, and they apply to any SHRINE-based network such as ACT and LADR. The discussion assumes an intermediate level of TCP/IP networking knowledge.
The following subsections summarize the networking requirements, which are organized by roles. Please follow only the subsection that applies to your site.
Starting with SHRINE 2.0.0, the topology of a SHRINE network is greatly simplified. All that each remote site needs to do is to allow its SHRINE host to have access to TCP port 6443 of the hub. Modern firewalls are typically "stateful" by design. A stateful firewall is aware of the beginning, middle, and end of each connection (particularly TCP connections), and it will maintain each connection for as long as the endpoint application requires it. SHRINE takes advantage of a single, stateful TCP connection that the remote site initiates to allow the site and the hub to exchange all SHRINE-specific data. The remote site is no longer required to configure an "inbound" (from its perspective) firewall rule to accommodate any "reciprocal" network traffic from the hub. Typically, many organizations allow unrestricted outbound Internet access for their hosts, and in such situations this policy is sufficient for the remote site.
This simplification of networking requirements has two advantages:
When troubleshooting connectivity issues, the site administrators must work with the hub to determine the status of network connectivity between the site and the hub. One popular tool is tcptraceroute, which is available in CentOS Linux but can be found in other distributions as well. The tool utilizes the basic principles of the traditional traceroute program but adapts it to work with TCP packets. It sends out TCP packets that have the "SYN" flag enabled for increasing values of time-to-live (TTL) until one such packet reaches the destination, or TTL reaches its default limit of 30, whichever comes first. Using tcptraceroute can determine the state of network connectivity between the remote site and the hub.
The following diagram illustrates a fictitious SHRINE network of one hub and one remote site. In this scenario, the SHRINE server has been configured to accept inbound connections to the default TCP port of 6443. Also, the hub and remote sites each have additional networking equipment that may affect routing and/or firewall policies, as shown in their respective blue boxes.
To use tcptraceroute to confirm network connectivity, the remote site administrator will run the utility from her own SHRINE host and point it at the hub. For each hop along the network path, tcptraceroute will send a TCP packet with SYN flag enabled and with the destination port of TCP 6443, until the final TCP packet is sent to the SHRINE server itself or the TTL exceeds the default value of 30. If the SHRINE server is available to the remote site's connection attempt within the hop and time limits of tcptraceroute, then the remote site will see an output like below:
traceroute to shrine-hub.example.edu (xxx.xxx.xxx.xxx), 30 hops max, 60 byte packets 1 * * * 2 * * * 3 * * * 4 * * * 5 * * * 6 * * * 7 * * * 8 * * * 9 * * * 10 * * * 11 * * * 12 shrine-hub.example.edu (xxx.xxx.xxx.xxx) <syn,ack> 95.025 ms * * |
In this output, because TCP port 6443 is not commonly used by applications as a listening port, it is no surprise that hops 1 through 11 do not respond to the TCP packet within the allotted time. But because the hub is configured to respond to any TCP handshake on port 6443, the last line of the output confirms that the hub replies with a TCP packet that has both SYN and ACK flags enabled. Note that the tcptraceroute utility does not actually complete the entire three-way TCP handshake, so no actual connection is created with the hub.
The remote site is responsible for ensuring that all equipment under its control are configured to facilitate end-to-end communication for SHRINE. Importantly, the remote site is strongly discouraged from interfering with this communication through the use of in-line application proxies, because a misconfigured proxy can exert deleterious effects on application payload in TCP packets.