5 minute read
The tutorial up to this point only demonstrated the ability to send traffic between the IP addresses assigned to the trustgrid0 interfaces on each agent. However, it’s quite likely that security and operational constraints will prevent the Trustgrid agent from being installed directly on the target server. Instead, the agent will need to route traffic destined for the target server’s local network.
In this section, we will configure an agent to route traffic destined for another network through the Trustgrid virtual network. To avoid assumptions about the networks your agents are deployed in, we will use a loopback interface to simulate an adjacent network. But the steps shown here would apply equally if routing between real physical interfaces.
On agent1 we will create a loopback interface and assign it an IP address from another subnet. This will simulate an adjacent network that the agent needs to route traffic to.
172.31.255.1/32
can be replaced by another IP if it conflicts with an IP or route on either of the agents.lo2
and assign an IP address 172.16.255.1
.sudo ip link add name lo2 type dummy
sudo ip addr add 172.31.255.1/32 dev lo2
sudo ip link set lo2 up
nc -k -l -p 5000 -s 172.31.255.1
The first step is to configure agent1 to forward traffic to networks other than its own trustgrid0 interface IP. By default, the Linux operating system will only accept packets on an interface if the destination IP is assigned to that interface. Enabling IP forwarding allows the OS to manage packets destined for other IPs and networks.
Now that agent1 has an “adjacent network” of interest, the virtual network needs to be told that packets destined for this network should be routed to agent1. We will do this with a virtual network route.
172.31.255.1/32
1
Next, we need to tell agent2 to use the trustgrid0 interface to route traffic destined for the adjacent network. This is done by adding a local route in the operating systems that will forward traffic for the target IP, 172.31.255.1, via the trustgrid0 interface and through the virtual network tunnel.
sudo ip route add 172.31.255.1/32 dev trustgrid0
ip route
We can now test ICMP connectivity using ping
.
ping -c 3 172.31.255.1
This confirms that traffic destined for the adjacent network IP is:
Similarly, we can verify TCP traffic is being routed and forwarded as expected. Similar to the access policy tutorial, we will test connectivity to the netcat listener but in this case, we will bind the listener to the loopback interface IP.
In the access policy tutorial we specified a rule that only allowed TCP access to port 5000 when the destination IP was agent1’s trustgrid0 IP, 100.64.0.1
. Since we are now routing traffic to agent1’s loopback IP 172.31.255.1
instead, we need to update the policy to allow access to that IP/port instead.
172.31.255.1/32
and click Save.
Now we can start our listener and test connectivity.
nc -k -l -p 5000 -s 172.31.255.1
nc -vz -w 1 172.31.255.1 5000
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.