Routing

Example 1 - Routing to a Lost Relay

• This example demonstrates how to handle gaining access to a Relay that has been lost due to an intermediary relay being lost. Consider the situation below, where we have access to SQL01 and SQL02 through the intermediary Relay initial_foothold:

• At some point the initial_foothold relay either dies, or through some user error access to the SQL servers is lost. We know the initial_foothold is dead because it no longer responds to the Ping command.

• If we regain a foothold in the network we can also regain access to the SQL servers through routing. In the figure below we see the second_foothold highlighted in green. In order to setup the channels to get back to SQL01 we need to copy the information from the Interface (highlighted in red).

• We double click the highlighted interface and copy the arguments shown into a notepad.

• Using the information provided from the previous step, we create a new listening interface on second_foothold that is identical to the listening channel between initial_foothold and SQL01.

• Once this channel is listening, we need to grab the RelayID of SQL01 and the DeviceID of the Interface we wish to connect to. This information can be obtained by clicking on the Relay and selecting the highlighted values:

• Now, on second_foothold we run the CreateRoute command. The command shown below instructs the Relay to update its routing table such that it understands that SQL01's Interface with ID 8000 can be reached by sending packets out of the Interface with ID 1 (the channel we setup earlier).

• Important to note in this command is the use of the RelayID colon seperated DeviceId identifier. Think of this as a hostname and port. Also of note is the Neighbour boolean set to true, this is because we are routing to a Relay that will be 1 hop away.

• At this point your network should look similar to that shown below, note there is now a loop where two routes could be used to reach SQL01, although we can't use the route through initial_foothold as it is dead.

• The next stage is to update the Gateway's routing table. This is an important step and should be executed with care. We must tell the Gateway about this new route to SQL01. At this point in time the Gateway only knows that packets destined for SQL01 must go through initial_foothold. We must delete this route and add our new route. For this stage we need the RelayID of SQL01 and second_foothold.

• The figure below shows the Gateway's routing table, highlighted in red is the current route to SQL01 out of DeviceID 1 (which is connected to initial_foothold). We need to delete this route by clicking on the 3 button's highlighted in yellow. In green is the route to second_foothold, this goes through DeviceID 2, we need this information for the next step.

• The CreateRoute command for the Gateway is therefore:

• If we now delete the initial_foothold relay by sending it the Close command (it won't reach initial_foothold but will remove it from our graph), we should be left with the following network, and access back to SQL01:

Example 2 - Getting Access to SQL02

• This example follows directly from the previous. We have gained access to SQL01, but have closed initial_foothold and mistakenly forgotten to keep note of the Interface arguments as we did in the last example. We can regain access to SQL02 by reversing some of the arguments.

• First, we click on the Gateway Return Channel Interface highlighted below in green and copy the arguments that were used to create it as before.

• The arguments are as follows:

{
  "arguments": [
    [
      {
        "name": "Output ID",
        "type": "string",
        "value": "M5EXErzK"
      },
      {
        "name": "Input ID",
        "type": "string",
        "value": "g2HFrb9a"
      }
    ],
    {
      "name": "Filesystem path",
      "type": "string",
      "value": "c:\\users\\tim\\desktop"
    },
    {
      "name": "Clear",
      "type": "boolean",
      "value": false
    }
  ],
  "jitter": [
    0.03,
    0.03
  ]
}

• In order to create a listening Interface on second_foothold we can create a new UncShareFile channel, however we must reverse the InputID and OutputID shown above. To be completely concise, the InputID shown above is g2HFrb9a and therefore when we create this new channel the OutputID will be g2HFrb9a. This is demonstrated in the next figure.

• NOTE: If the Relay was setup from a Negotiation channel then do not reverse the arguments. In this instance when creating the channel, we would set the InputID to g2HFrb9a and the OutputID to M5EXErzK.

• Now, all we have to do is create the relevant routes as we did previously. The RelayID for SQL02 is 748cb67487182ef6. The CreateRoute command to be executed on second_foothold is as follows:

• We delete the old route in the gateway as previously described, and the CreateRoute command on the Gateway is as follows:

Example 3 - Connecting to Redundant Listeners

• The following video demonstrates gaining access to a Relay that had a redundant access listener setup - https://youtu.be/UZ7M9dbcjOY