web-dev-qa-db-fra.com

redirection de port ssh avec pare-feu-cmd

J'essaie de faire un tunnel ssh dans un serveur derrière NAT:

ssh depuis un ordinateur portable -> Hôte avec redirection de port dans le pare-feu -> Entrez directement dans l'invité (172.16.0.2, derrière l'hôte NAT).

Utiliser iptables sur l'hôte - cela fonctionnera:

# iptables -I OUTPUT  -d 0.0.0.0/0 -j ACCEPT
# iptables -I FORWARD  -d 0.0.0.0/0 -j ACCEPT
# iptables -I INPUT  -d 0.0.0.0/0 -j ACCEPT
# iptables -t nat -I PREROUTING -d 0.0.0.0/0 -p tcp --dport 222 -j DNAT --to-destination 172.16.0.2:22

Cependant, iptables n'est pas enregistré lors du redémarrage de l'hôte, car le service firewalld est en cours d'exécution (firewalld est la valeur par défaut dans RHEL 7).

J'essaie donc de faire la même chose redirection de port avec firewall-cmd.

Utilisation de firewall-cmd sur l'hôte - cela ne fonctionnera PAS:

# firewall-cmd --permanent --zone=public --add-forward-port=port=222:proto=tcp:toport=22:toaddr=172.16.0.2'
# firewall-cmd --permanent --zone=public --add-masquerade
# firewall-cmd --permanent --direct --add-rule ipv4 filter FORWARD 0 -d 0.0.0.0/0 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule ipv4 filter OUTPUT 0 -d 0.0.0.0/0 -j ACCEPT
# firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -d 0.0.0.0/0 -j ACCEPT

# firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 0 -d 0.0.0.0/0 -p tcp --dport 222 -j DNAT --to-destination 172.16.0.2:22

# firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="0.0.0.0/0" forward-port port="222" protocol="tcp" to-port="22" to-addr='"172.16.0.2"

# firewall-cmd --reload

# firewall-cmd --list-all

public (active)
  target: default
  icmp-block-inversion: no
  interfaces: enp4s0f0
  sources: 
  services: ssh dhcpv6-client
  ports: 8139/tcp
  protocols: 
  masquerade: yes
  forward-ports: port=222:proto=tcp:toport=22:toaddr=172.16.0.2
  source-ports: 
  icmp-blocks: 
  rich rules: 
     rule family="ipv4" destination address="0.0.0.0/0" forward-port port="222" protocol="tcp" to-port="22" to-addr="172.16.0.2" 

# firewall-cmd --direct --get-all-rules

ipv4 filter INPUT 0 -d 0.0.0.0/0 -j ACCEPT
ipv4 filter OUTPUT 0 -d 0.0.0.0/0 -j ACCEPT
ipv4 filter FORWARD 0 -d 0.0.0.0/0 -j ACCEPT
ipv4 nat PREROUTING 0 -d 0.0.0.0/0 -p tcp --dport 222 -j DNAT --to-destination 172.16.0.2:22

Maintenant, lorsque vous essayez de vous connecter à l'invité - depuis mon ordinateur portable, via le port d'hôte 222 - la connexion ssh est refusée:

ssh -l stack my-Host -p 222
ssh: connect to Host my-Host port 222: Connection refused

Une idée de ce qui me manque?

linuxport-forwardingssh-tunnelfirewalld
6
Noam Manos

Tu pourrais essayer firewall-cmd --add-forward-port:

firewall-cmd --permanent --add-forward-port=port=222:proto=tcp:toaddr=172.x.x.x:toport=22
firewall-cmd --reload

Syntaxe générale ( https://firewalld.org/documentation/man-pages/firewall-cmd.html ):

firewall-cmd [--permanent] [--zone=zone] \
 --add-forward-port=port=portid[-portid]:proto=protocol[:toport=portid[-portid]][:toaddr=address[/mask]] \
 [--timeout=timeval]
4
mwfearnley

J'ai personnellement rencontré un problème similaire et cette solution est venue à mon secours. Veuillez essayer et faites-moi savoir si cela a aidé.

Il existe plusieurs façons d'accéder à un serveur derrière NAT: la redirection de port, vous pouvez configurer le routeur/pare-feu pour transférer le trafic entrant vers un serveur interne. En règle générale, vous devez spécifier le protocole (UDP/TCP), le port de service externe et le port de service interne.

Pour la redirection de port ssh avec firewall-cmd, veuillez essayer cette commande:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 222 -j DNAT \--to 172.x.x.x.:22

D'après le code donné, je comprends en quelque sorte que c'est ce que vous essayez d'atteindre. Assurez-vous donc de vérifier le port. Dans mon cas, j'ai essayé la même chose avec le port 80.

Cette règle spécifie la table NAT pour utiliser la chaîne PREROUTING intégrée pour transmettre les demandes HTTP entrantes exclusivement à l'adresse IP de destination répertoriée

0
James Andreson

Les "symptômes" et les données que vous présentez sont très similaires à ce que nous avons connu en utilisant KVM (libvirt) avec le "réseau par défaut". Pour cette raison, nous trouvons la réponse ci-dessous très pertinente ...

La "seule" façon dont nous pouvons faire un port en avant en utilisant KVM (libvirt) avec le "réseau par défaut" (virbr0) utilise le hack/contournement informé par @Antony Nguyen. Ou plus simplement vous peut utiliser libvirt-hook-qem .

Ce fil a une explication complète de la façon de résoudre ce problème pour CentOS 7 (et certainement pour d'autres distributions) en utilisant libvirt-hook-qemu: https://superuser.com/a/1475915/19584 .

0
Eduardo Lucio

Il semble que vos problèmes ne soient pas un problème avec vos commandes firewall-cmd, mais quelque chose à voir avec OpenStack?

Pour référence, je posterai la réponse finale (par James Slagle, probablement celui-ci ) sur le rapport Bugzilla que vous avez fait - juste au cas où cela aiderait quelqu'un:

Comme suggéré par Eric, ce problème est lié au déploiement OSP, changeant ainsi les propriétaires de bogues en TripleO.

Notez qu'il est connu pour effectuer OSP 14 et ci-dessous.

Non, ce n'est pas correct en fonction de la façon dont j'interprète le bogue. Vous essayez d'ajouter des règles de pare-feu sur l'hôte (titan08) qui héberge un VM appelé undercloud-0.

undercloud-0 est l'endroit où OpenStack est installé. Mais il n'y a pas de rpm ou de configuration OpenStack effectués sur l'hôte physique lui-même (titan08).

Dans ce cas, il semble que cela concerne entièrement la configuration du pare-feu de l'hôte physique et non d'OpenStack vm.

Comme Eric l'a souligné, les règles que vous essayez d'ajouter avec firewalld ne sont pas enregistrées sur l'hôte physique (titan08).

Ma compréhension est-elle correcte?

Lorsque vous installez OpenStack sur une machine virtuelle, il n'apporte aucune modification à l'hôte physique lui-même.

0
mwfearnley