J'ai deux serveurs. Le programme du premier doit communiquer avec le second sur le port 2194.
Je sais que ça ne fonctionne pas, car quand je le fais:
root@server1 [~]# telnet myserver2.com 2194
Trying 123.123.123.98...
telnet: connect to address 123.123.123.98: Connection timed out
telnet: Unable to connect to remote host: Connection timed out
server1# iptables -L -n
Chain INPUT (policy DROP)
...
...
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy DROP)
...
Chain LOCALINPUT (1 references)
target prot opt source destination
...
Chain LOCALOUTPUT (1 references)
target prot opt source destination
...
Chain LOGDROPIN (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
Chain LOGDROPOUT (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
linux
iptables
redhat
connection
siliconpi
la source
la source
Réponses:
Pour autoriser les connexions sortantes de server1 à server2 sur le port TCP 2194, utilisez ceci sur server1:
Pour autoriser les connexions entrantes de server1 à server2 sur le port TCP 2194, utilisez ceci sur server2:
la source
Quelques conseils
Le service que vous exécutez écoute-t-il uniquement sur localhost? Courir
Si vous voyez une ligne comme celle-
0.0.0.0:2194
là, ça va. Si vous voyez127.0.0.1:2194
alors vous écoutez uniquement sur les connexions locales (ou:::2194
et::1:2194
respectivement pour les adresses IPv6, affichées sous forme detcp6
lignes).Quelles sont les règles actuelles d'iptables?
La politique est-elle DROP / REJECT (si ce n'est pas le cas, pour toutes les chaînes)? Existe-t-il une règle spécifique pour le port dont vous avez besoin?
S'il s'agit d'un problème de pare-feu, vous pouvez soit modifier la règle incriminée, soit ajouter une règle comme
devrait faire l'affaire (non testé)
=== EDIT ===
Pour tester le problème de réseau, un bon outil est
tcpdump
. Exécutez-le sur les deux serveurs tout en essayant de vous connecter et voyez où vont les paquets. par exemple, sur le serveur 1, exécutez:et sur le serveur 2 exécutez:
Essayez ensuite de vous connecter. Vous devriez voir tous les paquets TCP vidés à l'écran, depuis la source et la destination. Avec ces informations, vous devriez être en mesure de localiser le problème.
la source