Vous n'êtes pas identifié(e).
Pages : 1
lorsque j’amène un pc en local je peut me connecté sur les deux serveur sans aucun probleme (ssh nom@iplocal -p xxxx ou yyyy)
sur les deux serveur les port sont ouvert dans iptables de la mème manière ... (chacun sur son port biensur)
lorsque de fait un
le port xxxx me revient "open" alors que le port yyyy est "flitred"
je soupçonne encore mon FAI d'avoir fait un tour de cochon avec sa box a 0.05€.....
d'ou ma question.... Comment identifié le problème ?? pour savoir si ca vient de mon serveur ou de ma box
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
xxx.xxx.xxx.xxx.yyyy étant l'ip WAN et le port
je vais pouvoir me rendre sur place demain si tout vas bien pour essayé de réglé le problème ... mais je ne sait pas de quel coté cherché ...
je vais essayé de redémarré la box .... normalement pas besoin mais elle est tellement POURRIE leur "box ozone" .... on sait jamais !!!
je veux changé de FAI mais pour le moment je suis bloqué .... :-( enfin c'est plus le sujet mdr...
Dernière modification par ahote (25-10-2019 17:12:56)
Hors ligne
Dernière modification par ahote (25-10-2019 18:37:54)
Hors ligne
lors d'un tcptraceroute les deux dernière ligne sont l'ip WAN de la box (les résultats identique sur le port xxxx et yyyy)
On peut voir ?
C'est le résultat nominal : une ligne pour la box, et une ligne pour le serveur final.
lorsque je fais un tcpdump depuis le client distant je n'ai aucun retour de paquet seulement des paquets envoyé :
En faisant quoi ? tcptraceroute ou ssh ?
Avec tcptraceroute, les réponses des routeurs intermédiaires (y compris la box) sont des paquets ICMP (type "time exceeded quand tout se passe bien). Seul le paquet de réponse finale du serveur devrait être un TCP SYN/ACK dans le cas d'un port ouvert, TCP RST dans le cas d'un port fermé (pas en écoute), et TCP RST ou ICMP dans le cas d'un port filtré. Si la box n'arrive pas à communiquer avec le serveur, elle peut renvoyer un ICMP "destination host unreachable".
Je pense que sur le client il vaudrait mieux capturer les paquets ayant l'adresse publique de la box.
j'ai aussi essayé de faire pasé par le serveur 1 pour me connecté au serveur 2
Est-ce que les règles iptables des deux serveurs l'autorisent ?
Le time-out et l'absence totale de réponse semblent indiquer que la résolution ARP au moins se fait bien, à vérifier avec "ip neigh", et c'est au niveau du trafic IP que ça coince.
nftable a remplacé ipables depuis deb 10 ?
Ça dépend de quoi on parle. Par défaut, le programme iptables utilise l'infrastructure nftables du noyau en mode de compatibilité au lieu de l'infrastructure iptables du noyau. Il reste possible de le reconfigurer pour utiliser l'infrastructure iptables du noyau comme avant.
petite question est ce que nftable est installé par défaut sous debian 10 ?
Non, d'après mon expérience c'est encore iptables qui est installé par défaut.
je ne connaissait pas nftable je me dit que peut être il tourne sans que je m'en soit aperçu
C'est le cas, mais ça devrait être transparent grâce à la couche de compatibilité avec iptables. Sauf si tes règles utilisent des correspondances ou des cibles incompatibles avec nftables.
Il vaut mieux montrer que raconter.
Hors ligne
C'est le résultat nominal : une ligne pour la box, et une ligne pour le serveur final
oui logique :-D
On peut voir ?
En faisant quoi ? tcptraceroute ou ssh ?
un ssh
Est-ce que les règles iptables des deux serveurs l'autorisent ?
je pense que oui mais pas sur ... il faudrait que je vérifie ....
Non, d'après mon expérience c'est encore iptables qui est installé par défaut.
iptables n’était pas présent, c'est moi qui l'ai installé
à vérifier avec "ip neigh",
tu veux que je vérifie quoi exactement ? (pas compris)
Dernière modification par ahote (25-10-2019 20:18:45)
Hors ligne
traceroute -T -O info --sport=yyyy xxx.xxx.xxx.xxx
Ce n'est pas le port source qui doit être spécifié mais le port destination. Par défaut, je suppose que ça cible le port 80 (HTTP).
u veux que je vérifie quoi exactement ?
Que tu exécutes cette commande sur le serveur 1 après le time out ssh (avec l'adresse privée) pour vérifier que l'adresse privée du serveur 2 est résolue en son adresse MAC. En fait tu peux remplacer ssh par n'importe quelle commande qui cible l'adresse privée, comme ping.
Dernière modification par raleur (25-10-2019 20:29:21)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Dernière modification par raleur (25-10-2019 20:59:41)
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
Hors ligne
Dernière modification par ahote (26-10-2019 13:15:19)
Hors ligne
Hors ligne
Pages : 1