3

I have three computers set up like this:

enter image description here

But I am having issues understanding how to setup the /etc/network/interfaces for each device so that they can all access the internet.

I have tried this:

Load Balancer:
    Eth1 (Local)
        address 192.168.1.10
        netmask 255.255.255.0
        network 192.168.0.0
        gateway 192.168.1.254 #hub
    Eth0
        address 192.168.0.10
        netmask 255.255.255.0
        network 192.168.1.0
        broadcast 192.168.1.255 #hub

RPi1:
    address 192.168.0.20
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.0.10 #Load Balancer Eth0
    gateway 192.168.1.10 #Load Balancer Eth1
RPi2:
    address 192.168.0.30
    netmask 255.255.255.0
    network 192.168.1.0
    broadcast 192.168.0.10 #Load Balancer Eth0
    gateway 192.168.1.10 #Load Balancer Eth1

I am testing whether they are connected to the internet by trying to ssh into them but I can only successfully ssh into the Load Balancer. Can you spot anything that may be causing the issue?

I have also tried sshing like this:

ssh -t 192.168.1.10 ssh 192.168.0.20

But it is not working

Edit for Doug Smythies

I have tried everything you suggested and there were no errors but it didn't work! I am going to try now with

EXTIF="eth1"
INTIF="eth0"

The other way round because I think it is?

So the RPi1s /etc/network/interfaces file looks something like this:

auto lo etho
iface eth0 inet static

address 192.168.0.20
netmask 255.255.255.0
network 192.168.0.0
broadcast 192.168.0.255
gateway 192.168.0.10
dns-nameservers 8.8.8.8
dns-search google.com

but unfortunately I cannot edit this now as I am not near the Pi! And I won't be for several weeks.

I tried pinging 8.8.8.8 before I left and it said something like:

192.168.1.10 network unreachable

Over and over again.

Also do I need to open any ports on the router? I have configured to forward ports 8051 and 8052 to 192.168.1.10.

Oh and I also edited the sshd file on RPi1 to listen to port 8051

edit 2

I have tried again:

ssh -p 8051 pi@1.2.3.4

And I get the error:

ssh_exchange_identification: Connection closed by remote host

I feel like we are getting closer!

edit 3

But when I try locally (using teamviewer to a local computer) to ssh like:

192.168.0.20:8051

It does not work. Which I am guessing is a very bad sign!

sudo netstat -plnt

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:111             0.0.0.0:*               LISTEN      644/rpcbind     
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1286/nginx      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1211/sshd       
tcp        0      0 127.0.0.1:631           0.0.0.0:*               LISTEN      1428/cupsd      
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN      814/smbd        
tcp        0      0 0.0.0.0:38503           0.0.0.0:*               LISTEN      697/rpc.statd   
tcp        0      0 0.0.0.0:139             0.0.0.0:*               LISTEN      814/smbd        
tcp6       0      0 :::111                  :::*                    LISTEN      644/rpcbind     
tcp6       0      0 :::80                   :::*                    LISTEN      1286/nginx      
tcp6       0      0 :::22                   :::*                    LISTEN      1211/sshd       
tcp6       0      0 ::1:631                 :::*                    LISTEN      1428/cupsd      
tcp6       0      0 :::445                  :::*                    LISTEN      814/smbd        
tcp6       0      0 :::54661                :::*                    LISTEN      697/rpc.statd   
tcp6       0      0 :::139                  :::*                    LISTEN      814/smbd
Community
  • 1
maxisme
  • 131

2 Answers2

3

From our extensive chat session: Your setup is / was suffering from: Troubles with your router not forwarding as expected; Hackers attempting to break-in via the existing, and working, port 22 forward to your load balancer computer; ufw being enabled, getting in the way of the suggested iptables script.

Access method 1: Chaining SSH sessions:

Create an ssh session in the usual way from your external computer to your (LB) load balancer computer. Use that session to create a new ssh session between the LB and the RPi:

ssh pi@192.168.0.20

or, if the RPi has had its ssh listening port changed as per method 2 below:

ssh -p 8051 pi@192.168.0.20

This method does NOT give the RPi's internet access on their own.

Access method 2: Chained port forwards

You will need to do port forwarding in two places (your router and then also on your load balancer) to be able to ssh to your RPi1 and RPi2 computers, and that is a different story than can they access the internet or not. Since you mention it already works, I assume port forwarding is already setup on your router for ssh to the load balancer. You will have to use two different ports to forward, one for each of RPi1 and RPi2. I have arbitrarily selected port 8051 and 8052, but your can change them.

However, before you start thinking about more port forwarding, you should make it so that your RPi1 and RPi2 computers can access the internet. You will need to make your load balancer into a router. It can be a very simple router, assuming the router at 192.168.1.254 takes care of firewall type stuff.

Fix your interfaces files. A suggestion (Edited to reflect the final version):

On the LB:

# The loopback network interface
auto lo eth1 eth0
iface lo inet loopback

iface eth1 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 8.8.8.8
dns-search google.com

iface eth0 inet static
address 192.168.0.10
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

RPi1: as per your edit. RPi2: Same, except for IP address.

First disable ufw, as in this case it wasn't adding any value and it conflicts with what we want to do:

sudo ufw disable

Now, here is an iptables rule set to try (edit has been tested by Maximilian, works fine):

#!/bin/sh
FWVER=0.01
#
# Maximilian rule set 2015.03.08 Ver:0.01
#     Port forward to RPi1 and RPi2
#     and be a NAT router for them also.
#
#     This may conflict with other stuff on the cluster computer,
#     I don't know.
#     If so, this may need to be merged somehow with whatever.
#
#     The router needs to be configured to forward ports 8051
#     and 8052 to 192.168.1.10
#     In turn, 192.168.1.10 will forward them again with this rule set.
#
#     run as sudo
#

echo "Loading Maximilian rule set version $FWVER..\n"

# The location of the iptables program
#
IPTABLES=/sbin/iptables

#Setting the EXTERNAL and INTERNAL interfaces and addresses for the network
#
EXTIF="eth1"
INTIF="eth0"
EXTIP="192.168.1.10"
INTIP="192.168.0.10"
RPI1="192.168.0.20"
RPI2="192.168.0.30"
UNIVERSE="0.0.0.0/0"

echo "  External Interface: $EXTIF  Internal Interface: $INTIF  External IP: $EXTIP  Internal IP: $INTIP  RPi1: $RPI1  RPi2: $RPI2"

#CRITICAL:  Enable IP forwarding since it is disabled by default
#
echo Enabling forwarding...
echo "1" > /proc/sys/net/ipv4/ip_forward

#Clearing any previous configuration
#
echo "  Clearing any existing rules and setting default policy to ACCEPT.."
$IPTABLES -P INPUT ACCEPT
$IPTABLES -F INPUT
$IPTABLES -P OUTPUT ACCEPT
$IPTABLES -F OUTPUT
$IPTABLES -P FORWARD ACCEPT
$IPTABLES -F FORWARD
$IPTABLES -t nat -F
# Delete user defined chains
$IPTABLES -X
# Reset all IPTABLES counters
$IPTABLES -Z
# While my references do not have it, I think this is needed.
$IPTABLES -t nat -Z

$IPTABLES -t nat -A PREROUTING -p tcp -i $EXTIF --dport 8051 -j DNAT --to-destination $RPI1:8051
$IPTABLES -t nat -A PREROUTING -p tcp -i $EXTIF --dport 8052 -j DNAT --to-destination $RPI2:8052

#
# FORWARD rules would only be if the default policy is not ACCEPT
#

$IPTABLES -t nat -A POSTROUTING -o $EXTIF -j SNAT --to $EXTIP

echo Maximilian rule set version $FWVER done.

Check by doing a ping from an an RPi:

ping 8.8.8.8

If that works, then try to access from the internet via ssh. For example if the external IP address of your router is 1.2.3.4:

ssh -p 8051 pi@1.2.3.4

Obvioulsy, you will have to setup your RPi1 SSH server to listen on port 8051, and your RPi2 SSH server to listen on port 8052.

Once you are happy with the iptables script and you want it to load automatically, then edit the /etc/network/interfaces and add a pre-up command (make the location and file name whatever you used):

# The loopback network interface
auto lo eth1 eth0
iface lo inet loopback
pre-up /home/maximilian/iptable

iface eth1 inet static
address 192.168.1.10
netmask 255.255.255.0
gateway 192.168.1.254
dns-nameservers 8.8.8.8
dns-search google.com

iface eth0 inet static
address 192.168.0.10
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

Side issue SSH password attacks:

Now, for your issue of hackers trying to break in via SSH password attack, I use this trick, which has been extremely effective for years now. However note that others will suggest using a different port and using keys instead of passwords. I do it this way because I like to study the attacks:

# Allow any related traffic coming back to the server in.
#
#
$IPTABLES -A INPUT -i $EXTIF -s $UNIVERSE -d $EXTIP -m state --state ESTABLISHED,RELATED -j ACCEPT
# Secure Shell on port 22.
#
# Dynamic Badguy List. Detect and DROP Bad IPs that do password attacks on SSH.
# Once they are on the BADGUY list then DROP all packets from them.
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
#$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 5400 --name BADGUY_SSH -j DROP
# Sometimes make the lock time very long. Typically to try to get rid of coordinated attacks from China.
$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j LOG --log-prefix "SSH BAD:" --log-level info
$IPTABLES -A INPUT -i $EXTIF -m recent --update --hitcount 3 --seconds 90000 --name BADGUY_SSH -j DROP
$IPTABLES -A INPUT -i $EXTIF -p tcp -m tcp --dport 22 -m recent --set --name BADGUY_SSH -j ACCEPT

But be careful that you do not lock yourself out, as I have done to myself when away on business trips. Note that I make one other change. I edit sshd.conf and add this:

#Limit the number of bad passwords per connection to 2. Default is 6.
#Then the iptables connection counter will kick in sooner to drop
#password attack hackers.
MaxAuthTries 2
Doug Smythies
  • 16,146
0

Acronyms

  • IN point is Router
  • OUT/Target resource is Rpi N
  • LB - Load Balancer

To be clear

As for the start, the think that you can't connect to RPi from outside doesn't mean that internet is not accessible from RPi itself. So it is "bad" check.

You could connect easy to RPi from LB, just ssh in to LB, and from LB ssh to any RPi you want.

Now about more complex things

Here is two tasks:

a) provide internet access for RPis ( RPi -> INET )

LB:

  • default route should be set via local ip address
  • forwarding should be enabled in kernel
  • firewall should allow forwarding

RPi:

  • as gateway could be used cluster ip, as dns - any dns server.

b) provide access from internet/router to RPIs ( IN -> RPis )

Between IN and OUT points is present LB, as result IN will not see RPis directly. To solve your problem, your cluster ip sub-net need to be routed by LB.

So if you:

  • modify route table on router(IN), example: route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.10
  • allow forwarding of packages on kernel level(LB): net.ipv4._ip_forward =1

  • allow forwarding on LB firewall

    you will be fine with accessing IN -> RPi. After that you will be able to make port forwarding to RPi from IN (router) directly.

All that ways realized with the think that your LB is in the middle.

As more simple variant, you could connect your switch to router directly, and build your network topology in one-ranged network.

Hint:

don't use ssh as tests, or netstat for port listening check. Currently you have problems with connectivity between networks, so traceroute, route commands from IN -> RPi, RPi -> IN, RPi -> INET will give more information about your problem

Reishin
  • 926