So, you have a validator node VAL0 and the sentry nodes SEN1, SEN2, and SEN3 according to your single layer sentry node setup above.
I would encourage to manage networking through a firewall, i.e., UFW, but you can also add other layers at will, i.e., physical network topology.
As validator client and beacon nodes we use Lighthouse which configures it's p2p port on :9000 by default.
Sentry Nodes SEN1, SEN2, SEN3
The sentry node networking setup is quite generic, we disallow incoming connections except for a limited SSH access and the Lighthouse discovery port.
ufw default deny incoming # deny incoming connections (server hardening)
ufw default allow outgoing # allow outgoing connections (p2p requires that)
ufw limit 22 # limit SSH requests, change this to your SSH port
ufw allow 9000 # open the Lighthouse discovery port
Add other rules at will, e.g., if you setup monitoring dashboards. Enable the networking rule set with ufw enable. See the rules with ufw status.
Now just configure the Lighthouse beacon chain node according to the official documentation. https://lighthouse-book.sigmaprime.io/
If you change the discovery port, make sure to update the UFW rules.
The sentry node will be available both on the open internet and the local area network for connections to the other sentry nodes and also the validator node.
Validator Node VAL0
The validator node will be shielded from the internet. For simplicity, we will just use UFW rules here, this even works on cloud providers given your machines are all in the same local network / region. For extended security, you can also add physical network logic, e.g., only wiring the validator directly to the sentries without direct internet access (make sure you come up with some SSH logic here).
ufw default deny incoming # deny incoming connections (server hardening)
ufw default deny outgoing # deny outgoing connections (to avoid the internet)
ufw limit 22 # limit SSH requests, change this to your SSH port
We deny any incoming traffic and throttle SSH access. We also deny all outgoing traffic to avoid peering with other clients on the internet.
To only allow local network connections to your Lighthouse validator, open port 9000 for the following subnets:
ufw allow from 10.0.0.0/8 to any port 9000
ufw allow from 192.168.0.0/16 to any port 9000
This allows the local subnets 10.0.0.0/8 and 192.168.0.0/16 to access your lighthouse client.
Now, to also allow outgoing connections, for the same subnets, do:
ufw allow out from any to 10.0.0.0/8
ufw allow out from any to 192.168.0.0/16
Enable the networking rule set with ufw enable. See the rules with ufw status.
Now just configure the Lighthouse beacon chain node and validator client according to the official documentation. If you change the discovery port, make sure to update the UFW rules.
Discovery
Now, the last step is to wire the clients together. The sentry nodes SEN1, SEN2, and SEN3 will be able to access public bootnodes of the beacon chain they want to connect to, there is not much action required.
The validator node VAL0 will need some custom networking configuration. The following configuration options come in handy:
--boot-nodes <ENR-LIST>
One or more comma-delimited base64-encoded ENR's to bootstrap the p2p network.
--libp2p-addresses <MULTIADDR>
One or more comma-delimited multiaddrs to manually connect to a libp2p peer without an ENR.
So, either take the LibP2P Multi-Address format or the Ethereum Node Record (ENR) from the three SEN1, SEN2, and SEN3 and pass it either as bootnode or static peer to your validator node, e.g.:
lighthouse bn --boot-nodes "enr:-LK4QHP9pudQUPud4VfLoRHBytpK1dE_mQYa-BCVJGsR4jHDO1uzmfkrXGTmovAn9RukI52icX3s0fHfhT-Fsinr1B8Dh2F0dG5ldHOIAAAAAAAAAACEZXRoMpD2d10HAAABE___________gmlkgnY0gmlwhFzIHRCJc2VjcDI1NmsxoQKfVWe8YoASdFmIlVxo4Lh6je6jGW-tXOJWTh-6ZuW4ooN0Y3CCIyiDdWRwgiMo, ..."
Or:
lighthouse bn --libp2p-addresses "/ip4/10.0.3.84/tcp/9000/p2p/16Uiu2HAsDfeLV6FLXhh1D5MeTSxADCPfBCHRh4VrhcHzeSpxGQRF, ..."
That way your validator node will try to peer with your provided sentry nodes only.
