Sentry Node Array Tutorial

For now we have not done anything different from what we would do when setting up a validator node, although we have stopped doing several things, such as creating the wallet or running the validator creation command “tx staking create-validator”, since we do not want to create validator nodes, only nodes that synchronize with the rest of the nodes in the network and we can use to synchronize our validator node in a secure way without exposing our IP to the rest of the network.

The sentry nodes (both), must have peers to be synchronized at all times, we will add the following peers to the config.toml file inside the config folder.

Persistent Peers:​

peers=$(curl -s https://ss.terp.nodestake.top/peers.txt) sed -i.bak -e "s/^persistent_peers *=.*/persistent_peers = \"$peers\"/" ~/.terp/config/config.toml

Note: the peers were obtained from Nodestake validator team.

It would also be advisable to add as persistent peer the sentry nodes between them. That is to say, that the sentry node B is persistent peer of the sentry node A, in the same way that the sentry node A is persistent peer of the sentry node B; this will make us have more redundancy.

Private Peers:​

In the config.toml file of the config folder of the sentry nodes (both), it is necessary to specify the id of the validator node in the private_peer_ids parameter. This is so that our sentry nodes never share with the rest of the peers of the network the existence of our validator node. If you don’t know how to get the id of your validator node, you can get it with the following command:

terpd tendermint show-node-id

Unconditional Peers​

In the same configuration file, we will also find the unconditional-peer-ids parameter to which we must add our validator node as we did with the private_peer_ids parameter. This step is necessary because the nodes have a limited number of peers to which they can connect.

To avoid the risk of leaving our validator node incommunicado, by setting its id in the unconditional-peer-ids parameter, we will make the sentry nodes always connected to the validator node even if the limit of peers to which they can be connected has been exceeded. Optionally we can also add in this same parameter (separated by commas) the homologous sentry node to guarantee that the sentry nodes will always be connected to each other.

unconditional-peer-ids = "validator node, peer sentry node".

Start Sentry Nodes​

At this point, we could start our sentry nodes and let them synchronize and be discovered by the rest of the network. For that we will use the following command:

sudo systemctl daemon-reload sudo systemctl enable terpd

Base configuration for validator​

Once the sentry nodes have been synchronized, we can configure the validator node with all certainty that our validator node is not going to stop being synchronized with the network. We will have to edit the config.toml file in the config folder, where we will find the following lines:

Persistent Peers​

In persistent_peers we will add only the ids of the sentry nodes, that is to say that if the node was already mounted before, we will have to delete the content of this field before adding our sentry nodes.

PEX​

In the same configuration file we will find the pex parameter, which we must set to “false”. This parameter does not discover other peers, it will only use the ones set in the persistent_peers parameter.

pex = false

Remove address book (optional)​

If the validator has already been exposed to the network, we can delete the address book so that it only “knows” the sentry nodes; if it is a validator that has never been started, this step is not necessary. Once inside the config folder and with the node stopped, perform the following command:

rm -rf $HOME/.terp/config/addrbook.json

Start Validator Node​

To verify that we are really connected only to two peers and these are the sentry nodes, we can write the following command in our validated node; the output is a JSON where it will show us the number and which peers we are connected to, where the number should be two and the peers should be our sentry nodes.

curl -s localhost:26657/net_info Here you can see the number of peers to which our validator node is connected, in this case it is two, which is correct.

Extra: Protecting the validator node through firewall​

Right now the p2p port of our validator node is open and anyone can establish a connection. If we have just set up the validator node, with the configurations made, nobody would have to find our validator node, however, to add a plus of security it is advisable to close the p2p port and only allow traffic to the IP’s of our sentry nodes.

There are several ways to do this, it is possible that your server provider allows you to do it through a gui. Ufw is a simple to use alternative.

Extra: Private networks​

One possibility we have when our validator node is in the same datacenter as one of the sentry nodes, would be to use private addressing.

In case we want to use private addressing, we will have to edit the addr-book-strict parameter of the config.toml file and set it to false in both the validator node and the sentry node that are communicating under private addressing. This parameter, when set to “true”, will only add routable addresses to the address book, the private addresses defined in RFC-1918 are not routable, therefore, they would not be added to the address book, so we will have to change it to false to be able to use IP addresses from the private ranges.

addr-book-strict: boolean. By default, nodes with a routable address will be considered for connection. If this setting is disabled (false), non-routable IP addresses, such as addresses from a private network, can be added to the address book. Source: https://docs.tendermint.com/master/nodes/validators.html

Conclusions​

Having sentry nodes will not only help our validator node not to fall victim to a denial of service attack, but will also make the Terp network more robust. The installation of the sentry nodes does not differ much from that of a validator node, and the additional configurations to be performed are very simple and intuitive.

Now that Terp Network is doing the 90u-3 testnet, it is a good time to try to set up sentry nodes and once the mainnet is launched, to be able to replicate it with the experience of having been able to test it in 90u-3. If you already have your node on 90u-3, what are you waiting for to set up your sentry nodes and protect yourself from unwanted attacks?

sources: https://stakely.io/en/blog/how-to-deploy-sentry-nodes-in-the-archway-network