Impossible de périphériques SSH dans le sous-réseau
J'ai trois ordinateurs configurés comme ceci:
Mais j'ai des problèmes pour comprendre comment configurer le /etc/network/interfaces pour chaque appareil afin qu'ils puissent tous accéder à Internet.
J'ai essayé ceci:
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
Je teste s'ils sont connectés à Internet en essayant de les connecter à ssh mais je ne peux que ssh avec succès dans le Load Balancer. Pouvez-vous repérer tout ce qui pourrait être à l'origine du problème?
J'ai également essayé sshing comme ceci:
ssh -t 192.168.1.10 ssh 192.168.0.20
Mais ça ne marche pas
Modifier pour Doug Smythies
J'ai essayé tout ce que vous avez suggéré et il n'y a pas eu d'erreurs mais cela n'a pas fonctionné! Je vais essayer maintenant avec
EXTIF="eth1"
INTIF="eth0"
L'inverse parce que je pense que c'est?
Donc les RPi1s /etc/network/interfaces le fichier ressemble à ceci:
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
mais malheureusement je ne peux pas le modifier maintenant car je ne suis pas près du Pi! Et je ne serai pas dans plusieurs semaines.
J'ai essayé de faire un ping sur 8.8.8.8 avant de partir et cela disait quelque chose comme:
Réseau 192.168.1.10 inaccessible
Encore et encore.
Dois-je également ouvrir des ports sur le routeur? J'ai configuré pour transférer les ports 8051 et 8052 vers 192.168.1.10.
Oh et j'ai aussi édité le fichier sshd sur RPi1 pour écouter le port 8051
modifier 2
J'ai réessayé:
ssh -p 8051 [email protected]
Et je reçois l'erreur:
ssh_exchange_identification: Connexion fermée par l'hôte distant
J'ai l'impression que nous nous rapprochons!
modifier 3
Mais quand j'essaie localement (en utilisant teamviewer sur un ordinateur local) de ssh comme:
192.168.0.20:8051
Ça ne marche pas. Ce que je suppose est un très mauvais signe!
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
De notre longue session de chat: Votre configuration souffre/souffrait de: Problèmes avec votre routeur ne transmettant pas comme prévu; Les pirates tentent de s'introduire via le port 22 existant et opérationnel vers votre ordinateur d'équilibrage de charge; ufw étant activé, gênant le script iptables suggéré.
Méthode d'accès 1: chaînage des sessions SSH:
Créez une session ssh de la manière habituelle de votre ordinateur externe vers votre ordinateur d'équilibrage de charge (LB). Utilisez cette session pour créer une nouvelle session ssh entre le LB et le RPi:
ssh [email protected]
ou, si le RPi a vu son port d'écoute ssh changé selon la méthode 2 ci-dessous:
ssh -p 8051 [email protected]
Cette méthode ne PAS donne l'accès Internet du RPi par ses propres moyens.
Méthode d'accès 2: port enchaîné vers l'avant
Vous devrez effectuer une redirection de port à deux endroits (votre routeur, puis également sur votre équilibreur de charge) pour pouvoir accéder à vos ordinateurs RPi1 et RPi2, et c'est une autre histoire que d'accéder à Internet ou non. Puisque vous mentionnez que cela fonctionne déjà, je suppose que la redirection de port est déjà configurée sur votre routeur pour ssh vers l'équilibreur de charge. Vous devrez utiliser deux ports différents pour transférer, un pour chacun des RPi1 et RPi2. J'ai arbitrairement sélectionné les ports 8051 et 8052, mais vous pouvez les modifier.
Cependant, avant de commencer à penser à plus de redirection de port, vous devez vous assurer que vos ordinateurs RPi1 et RPi2 puissent accéder à Internet. Vous devrez transformer votre équilibreur de charge en routeur. Il peut s'agir d'un routeur très simple, en supposant que le routeur à 192.168.1.254 s'occupe des choses de type pare-feu.
Corrigez vos fichiers d'interfaces. Une suggestion (modifiée pour refléter la version finale):
Sur le 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: selon votre édition. RPi2: idem, sauf pour l'adresse IP.
Tout d'abord, désactivez ufw, car dans ce cas, il n'ajoutait aucune valeur et il est en conflit avec ce que nous voulons faire:
Sudo ufw disable
Maintenant, voici un ensemble de règles iptables à essayer (la modification a été testée par Maximilian, fonctionne très bien):
#!/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.
Vérifiez en faisant un ping depuis un RPi:
ping 8.8.8.8
Si cela fonctionne, essayez d'accéder à partir d'Internet via ssh. Par exemple, si l'adresse IP externe de votre routeur est 1.2.3.4:
ssh -p 8051 [email protected]
Évidemment, vous devrez configurer votre serveur RPi1 SSH pour écouter sur le port 8051, et votre serveur RPi2 SSH pour écouter sur le port 8052.
Une fois que vous êtes satisfait du script iptables et que vous souhaitez qu'il se charge automatiquement, modifiez les interfaces/etc/network/et ajoutez une commande de pré-installation (définissez l'emplacement et le nom de fichier comme vous l'avez utilisé):
# 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
Attaques secondaires de mot de passe SSH:
Maintenant, pour votre problème de pirates essayant de s'introduire via une attaque par mot de passe SSH, j'utilise cette astuce, qui est extrêmement efficace depuis des années. Notez cependant que d'autres suggéreront d'utiliser un port différent et d'utiliser des clés au lieu de mots de passe. Je le fais de cette façon parce que j'aime étudier les attaques:
# 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
Mais faites attention à ne pas vous enfermer, comme je me suis fait moi-même en voyage d'affaires. Notez que j'apporte une autre modification. J'édite sshd.conf et j'ajoute ceci:
#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
Acronymes
- Le point IN est un routeur
- OUT/La ressource cible est Rpi N
- LB - Load Balancer
Pour être clair
Quant au début, penser que vous ne pouvez pas vous connecter à RPi de l'extérieur ne signifie pas qu'Internet n'est pas accessible à partir de RPi lui-même. C'est donc un "mauvais" chèque.
Vous pouvez vous connecter facilement à RPi à partir de LB, juste ssh à LB et de LB ssh à n'importe quel RPi que vous voulez.
Maintenant sur des choses plus complexes
Voici deux tâches:
a) fournir un accès Internet aux RPis (RPi -> INET)
KG:
- la route par défaut doit être définie via l'adresse IP locale
- le transfert doit être activé dans le noyau
- le pare-feu devrait permettre le transfert
RPi:
- comme passerelle pourrait être utilisé cluster ip, comme dns - n'importe quel serveur DNS.
b) fournir un accès d'Internet/routeur aux RPI (IN -> RPis)
Entre les points IN et OUT est présent LB, car le résultat IN ne verra pas RPis directement. Pour résoudre votre problème, votre sous-réseau IP de cluster doit être routé par LB.
Donc si vous:
- modifier la table de routage sur le routeur (IN), exemple: route add -net 192.168.0.0 netmask 255.255.255.0 gw 192.168.1.10
- autoriser le transfert de paquets au niveau du noyau (LB): net.ipv4._ip_forward = 1
autoriser le transfert sur le pare-feu LB
vous serez bien avec l'accès à IN -> RPi. Après cela, vous pourrez effectuer la redirection de port vers RPi depuis IN (routeur) directement.
Tout cela réalisé avec la pensée que votre LB est au milieu.
Comme variante plus simple, vous pouvez connecter directement votre commutateur au routeur et créer votre topologie de réseau dans un réseau à distance unique.
Allusion:
n'utilisez pas ssh comme test ou netstat pour la vérification d'écoute de port. Actuellement, vous avez des problèmes de connectivité entre les réseaux, donc traceroute, les commandes de route depuis IN -> RPi, RPi -> IN, RPi -> INET vous donneront plus d'informations sur votre problème