Salut,
Je deviens dingue, il me faut des idées, mais au point où j'en suis je prends même un simple support psychologique.
Au boulot, on a dans la nature (enfin, chez les clients) des routeurs 4G/WiFi. L'idée est d'offrir une connexion OpenVPN aux objets connectés qu'on a chez eux (logs, stats, maintenance…). Le routeur entre sur notre LAN via un OpenVPN.
J'ai deux routeurs de marque différente, mais tous les deux basés sur OpenWRT (je vais tâcher de trouver les versions précises, mais vu ce qu'il m'arrive, je doute que ça influe). Disons que les deux sont sur des versions récentes style de 2018.
Depuis mon PC (et bien d'autres testés sur le LAN de l'entreprise), je pingue et je peux me connecter en SSH sur les deux, en utilisant donc l'adresse IP du sous-reseau OpenVPN. Pas de soucis, le routage est bien fait.
Sur ce même LAN j'ai un Proxmox qui possède plusieurs VMs. Je n'ai fait aucun réglage spécifique, les VMs sont vues par le réseau comme des machines physique, sont sur le même sous réseau, et reçoivent leur IP par le serveur DHCP du LAN.
Mon pb c'est que depuis une VM Debian buster (et pas une autre), je n'arrive à me connecter qu'à l'un des deux routeurs… je pingue bien chacun, pas de pb, mais lors d'une connexion sur l'un des deux routeurs ça part en timeout :
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 10.8.0.221 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.8.0.221 [10.8.0.221] port 22.
debug1: connect to address 10.8.0.221 port 22: Connection timed out
ssh: connect to host 10.8.0.221 port 22: Connection timed out
Pour comparaison, même VM mais sur le routeur qui fonctionne :
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d 10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 10.8.0.18 is address
debug2: ssh_connect_direct
debug1: Connecting to 10.8.0.18 [10.8.0.18] port 22.
debug1: Connection established.
[...]
J'ai beau chercher partout, je ne vois pas de config spécifique, rien dans le ~/.ssh/config. Et même résultats avec un sudo ssh histoire de tester un utilisateur différent.
Bref, je ne comprends pô pourquoi ma connexion SSH part en timeout alors que je pingue sans pb.
Une idée ? Merci !
# vieux ssh vs new ssh
Posté par NeoX . Évalué à 3.
j'ai eu le cas à une époque, c'était que le ssh du client était plus recent que le ssh du serveur, et il n'était pas d'accord sur le protocole ssh à utiliser (au dela de v1/v2, y a avait une histoire de rsa/dsa/ecdsa.
ssh -vvv login@machinele vvv devrait et dire ou ca échoue
[^] # Re: vieux ssh vs new ssh
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 31 mars 2021 à 16:55.
les 2 traces que j'ai envoyé sont avec -vvv… on ne voit rien ça part en timeout avant les négociations, dès les premières lignes.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: vieux ssh vs new ssh
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Si ce n'est pas au niveau client/serveur SSH, alors c'est le réseau (de toute façon les timeout sont quasi toujours un souci réseau qui dit que ton client a toqué mais qu'on lui a pas répondu pendant un certain temps) Il est possible qu'en face tu ais un de ces cas :
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Traceroute
Posté par claudex . Évalué à 4.
Si tu fais un traceroute dans les deux sens, tu as bien quelque chose de cohérent ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3.
Pas mieux, on voit la même chose :(
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par claudex . Évalué à 4.
Et depuis 10.8.0.18, ça fait bien le même chemin inverse pour joindre ta VM ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 31 mars 2021 à 17:16.
Oui, et aussi depuis 10.8.0.221 (que pour rappel je peux y accéder depuis mon PC ainsi que d'autres machines).
Et pour rappel depuis ma VM qui "déconne" (je ne saurais dire si ça vient d'elle mais c'est là où j'ai le soucis) je ping sans pb (ainsi que wget de la page d'accueil), donc je doute une histoire de route.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par claudex . Évalué à 6.
C'est difficile de savoir si tu ping bien la machine à laquelle tu pense.
Ça par contre, tu ne l'avais pas dit il me semble. Du coup, à part un parefeu quelque part, je ne vois pas trop.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par claudex . Évalué à 4.
Dans les logs ssh de la machine de destination, tu vois la tentative de connexion ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par claudex . Évalué à 4.
Si tu ne la vois pas, tu peux aussi faire un tcpdump sur ta destination pour voir si tu vois le paquet sur le port 22 arriver.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3.
La destinataire est sous OpenWRT je maîtrise pas trop…
Rien dans les logs (
logread), et pas detcpdumpdisponible (et c'est une machine en prod, je veux pas trop installer).En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 01 avril 2021 à 09:25.
Bon, j'ai mis tcpdump, tant pis, on a un truc, mais j'y comprends rien. Tu peux jeter un oeil stp ?
Et après j'ai le client qui part en timeout.
Pour comparaison, si je lance le SSH depuis mon PC qui marche j'ai :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par NeoX . Évalué à 3.
regarde si tu peux tcpdump le flux dans les deux sens, voire simplement sur la machine local
sur le debian par exemple
tcpdump -vnni any host 10.8.0.221 and port 22ainsi tu verras la sortie (debian -> 10.8.0.221) mais aussi le retour (si ca fonctionne)
s'il n'y a pas de retour, c'est que quelqu'un bloque
- le debian en sortie par les routes tu pingues peut-être une autre machine que celle que tu penses (mauvaise route)
- le debian en sortie par le firewall (blocage flux sortant)
- le WRT en entrant ou en sortant (firewall, config ssh, host deny, route retour different pour la machine 11.197 de la machine 11.132
- sur le firewall/openvpn, une regle de NAT qui ne NAT pas certaines IPs quand on traverse dans le VPN
[^] # Re: Traceroute
Posté par claudex . Évalué à 4.
Il vaut mieux utiliser
host 192.168.11.132comme ça tu vois les réponses aussi. Là on voit que la machine essaye de se connecter mais on ne voit pas si une réponse est envoyée.« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par claudex . Évalué à 4.
en tant qu'option de filtre tcpdump au cas où ce n'était pas clair.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3. Dernière modification le 01 avril 2021 à 09:25.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par claudex . Évalué à 5.
D'après ce qu'on voit, ta machine ne répond pas (pas de SYN-ACK en réponse au SYN). La cause première, c'est une règle de pare-feu. Tu n'aurais pas un fail2ban un peu agressif sur cette machine ? (ça expliquerait pourquoi tu as le problème sur une machine et pas l'autre)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3.
Vu en bas avec la règle iptable, oui c'est bien ça.
Alors techniquement j'ai regardé, je ne vois pas de paquets installés, je ne vois pas de règle explicite dans l'interface (encore heureux) mais ça sent bien le ban automatique après quelques essais infructueux (et c'est logique vu l'utilisation de la machine bannie). Je ne comprends pas comment c'est arrivé là, mais au moins ça explique !
Je vais creuser maintenant, mais en attendant j'ai viré le fichier
blocklist, rebooté, et je peux m'y connecter.Merci à tout le monde, j'ai même appris quelques rudiments de
tcpdumpgrâce à vous (la honte, j'avais jamais fait ça alors que putain que c'est simple dans un tel cas).En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3.
Ah bon ? Pour moi ça a toujours été une évidence, mais je veux bien quelques explications de "pièges à con" :)
Non, je ne l'avais pas dit en effet
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Traceroute
Posté par claudex . Évalué à 7.
Dès que tu as un bridge (ou plusieurs interfaces, même si c'est plus rare). Par exemple, tu as installé docker sur ta machine, par défaut il prend 172.17/16. Et donc tu as 172.17.0.1 qui est sur ta machine, tu vas pourvoir le ping (très vite même) mais tu ne joindra pas la machine distante sur ton réseau qui a la même IP.
Tu peux aussi avoir un réseau à part (pour du backup par exemple ou du storage) qui va être le même qu'un autre réseau utilisé ailleurs.
Quand tu ping, tu sais que tu peux joindre cette IP mais tu n'as aucune idée de qui t'a répondu.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Traceroute
Posté par gUI (Mastodon) . Évalué à 3.
C'est noté merci !
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# problème de mtu ?
Posté par didg . Évalué à 2.
Regarder l'option --mssfix d'openvpn
[^] # Re: problème de mtu ?
Posté par gUI (Mastodon) . Évalué à 3.
Pas de réglage spécifique, mais en effet c'est une bonne idée, les phénomènes chelou et réglages MTU sont souvent liés.
Depuis la machine où le SSH échoue, je pingue même avec un gros paquet :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
# firewall ?
Posté par seb . Évalué à 5.
Salut,
Une règle iptables
iptables -L -n pour voir.
[^] # Re: firewall ?
Posté par gUI (Mastodon) . Évalué à 6.
Bingo !!!
Sur la passerelle récalcitrante je lis (entre autre…)
Évidemment je n'ai jamais mis ça explicitement, reste à savoir ce qui l'a créé. Je suppose une histoire de ban à cause d'erreurs de mots de passe, mais comment le supprimer etc.
Merci !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: firewall ?
Posté par gUI (Mastodon) . Évalué à 6.
Bon bin au moins c'est explicite :
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: firewall ?
Posté par gUI (Mastodon) . Évalué à 5.
Une fois le fichier viré et la machine rebooté, ça marche bcp mieux évidemment.
Merci !!!
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.