Forum Linux.général [RÉSOLU] Connexion SSH : je deviens dingue... Help !

Posté par  . Licence CC By‑SA.
3
31
mar.
2021

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  . É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@machine

    le vvv devrait et dire ou ca échoue

    • [^] # Re: vieux ssh vs new ssh

      Posté par  . Évalué à 3. Dernière modification le 31/03/21 à 16:55.

      le vvv devrait et dire ou ca échoue

      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  . É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 :

        • si c'est un routeur/firewall, le trafic SSH n'est peut être pas routé ou peut-être pas autorisé (mais dans ce cas, au lieu de répondre "vas te faire foutre" ou "je ne veux pas", les paquets sont juste drop et ça fait comme si le serveur ne répond pas ou si le paquet s'est perdu dans la nature)
        • si c'est le serveur final, il se peut que le parefeu interne ne réponde pas à certains réseaux pour ce protocole applicatif (et que les paquets soit drop au lieu de reject avec message) ; il y a d'autres cas aussi mais l'erreur aurait été différente
        • comme pour les routeurs, il faut voir si sur ton serveur VPN tu n'as pas de filtrage réseau, et que dans la configuration que le routage est assuré dans l'autre sens aussi (ça ne devrait pas arriver sauf si configuration tordue)

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Traceroute

    Posté par  . É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  . Évalué à 3.

      Pas mieux, on voit la même chose :(

      $ traceroute 10.8.0.221
      traceroute to 10.8.0.221 (10.8.0.221), 30 hops max, 60 byte packets
       1  192.168.11.253 (192.168.11.253)  0.248 ms  0.217 ms  0.193 ms
       2  10.8.0.221 (10.8.0.221)  78.379 ms  86.536 ms  86.534 ms
      $ traceroute 10.8.0.18
      traceroute to 10.8.0.18 (10.8.0.18), 30 hops max, 60 byte packets
       1  192.168.11.253 (192.168.11.253)  0.256 ms  0.239 ms  0.227 ms
       2  10.8.0.18 (10.8.0.18)  32.583 ms  32.558 ms  44.856 ms

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: Traceroute

        Posté par  . É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  . Évalué à 3. Dernière modification le 31/03/21 à 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  . Évalué à 6.

            je ping sans pb

            C'est difficile de savoir si tu ping bien la machine à laquelle tu pense.

            (ainsi que wget de la page d'accueil),

            Ç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  . É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  . É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  . Évalué à 3.

                  La destinataire est sous OpenWRT je maîtrise pas trop…

                  Rien dans les logs (logread), et pas de tcpdump disponible (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  . Évalué à 3. Dernière modification le 01/04/21 à 09:25.

                  Bon, j'ai mis tcpdump, tant pis, on a un truc, mais j'y comprends rien. Tu peux jeter un oeil stp ?

                  # tcpdump -i tun0 'src 192.168.11.132'
                  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                  listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
                  18:13:07.637315 IP 192.168.11.132.46164 > 10.8.0.221.ssh: Flags [S], seq 330599139, win 64240, options [mss 1308,sackOK,TS val 2921873725 ecr 0,nop,wscale 7], length 0
                  18:13:08.642302 IP 192.168.11.132.46164 > 10.8.0.221.ssh: Flags [S], seq 330599139, win 64240, options [mss 1308,sackOK,TS val 2921874738 ecr 0,nop,wscale 7], length 0
                  18:13:10.732475 IP 192.168.11.132.46164 > 10.8.0.221.ssh: Flags [S], seq 330599139, win 64240, options [mss 1308,sackOK,TS val 2921876754 ecr 0,nop,wscale 7], length 0
                  18:13:14.788536 IP 192.168.11.132.46164 > 10.8.0.221.ssh: Flags [S], seq 330599139, win 64240, options [mss 1308,sackOK,TS val 2921880818 ecr 0,nop,wscale 7], length 0
                  18:13:22.913643 IP 192.168.11.132.46164 > 10.8.0.221.ssh: Flags [S], seq 330599139, win 64240, options [mss 1308,sackOK,TS val 2921889010 ecr 0,nop,wscale 7], length 0
                  

                  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 :

                  # tcpdump -i tun0 'src 192.168.11.197'
                  tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                  listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
                  18:15:40.632910 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 633492880, win 501, options [nop,nop,TS val 3211209424 ecr 481193], length 0
                  18:15:42.197768 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 1, win 501, options [nop,nop,TS val 3211211466 ecr 481225,nop,nop,sack 1 {4294967233:1}], length 0
                  18:15:42.198271 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 1, win 501, options [nop,nop,TS val 3211211478 ecr 481257,nop,nop,sack 1 {4294967233:1}], length 0
                  18:15:46.288963 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 209, win 501, options [nop,nop,TS val 3211215580 ecr 481630], length 0
                  18:15:46.289665 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 209, win 501, options [nop,nop,TS val 3211215591 ecr 481677,nop,nop,sack 1 {1:209}], length 0
                  18:15:46.290148 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 209, win 501, options [nop,nop,TS val 3211215606 ecr 481762,nop,nop,sack 1 {1:209}], length 0
                  18:15:46.423783 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 769, win 501, options [nop,nop,TS val 3211215751 ecr 481827], length 0
                  18:15:46.789005 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 1457, win 501, options [nop,nop,TS val 3211216157 ecr 481867], length 0
                  18:15:47.074308 IP 192.168.11.197.47702 > 10.8.0.221.ssh: Flags [S], seq 1859648379, win 64240, options [mss 1308,sackOK,TS val 3211216380 ecr 0,nop,wscale 7], length 0
                  18:15:47.254071 IP 192.168.11.197.47702 > 10.8.0.221.ssh: Flags [.], ack 3218373460, win 502, options [nop,nop,TS val 3211216538 ecr 481906], length 0
                  18:15:47.712887 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], seq 0:29, ack 1, win 501, options [nop,nop,TS val 3211216539 ecr 481906,[bad opt]>
                  18:15:47.714033 IP 192.168.11.197.47702 > 10.8.0.221.ssh: Flags [P.], seq 0:41, ack 1, win 502, options [nop,nop,TS val 3211217029 ecr 481906], length 41
                  18:15:47.884860 IP 192.168.11.197.47624 > 10.8.0.221.ssh: Flags [.], ack 1985, win 501, options [nop,nop,TS val 3211217195 ecr 481924], length 0
                  18:15:47.885389 IP 192.168.11.197.47702 > 10.8.0.221.ssh: Flags [.], ack 350, win 501, options [nop,nop,TS val 3211217210 ecr 481972], length 0
                  

                  En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                  • [^] # Re: Traceroute

                    Posté par  . É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 22

                    ainsi 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  . Évalué à 4.

                    Il vaut mieux utiliser host 192.168.11.132 comme ç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  . É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  . Évalué à 3. Dernière modification le 01/04/21 à 09:25.

                      # tcpdump -i tun0 host 192.168.11.132
                      tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
                      listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
                      09:15:55.362232 IP 192.168.11.132.46174 > 10.8.0.221.ssh: Flags [S], seq 2532807099, win 64240, options [mss 1308,sackOK,TS val 2976040999 ecr 0,nop,wscale 7], length 0
                      09:15:56.320343 IP 192.168.11.132.46174 > 10.8.0.221.ssh: Flags [S], seq 2532807099, win 64240, options [mss 1308,sackOK,TS val 2976042002 ecr 0,nop,wscale 7], length 0
                      09:15:58.400988 IP 192.168.11.132.46174 > 10.8.0.221.ssh: Flags [S], seq 2532807099, win 64240, options [mss 1308,sackOK,TS val 2976044018 ecr 0,nop,wscale 7], length 0
                      09:16:02.400868 IP 0.0.0.0 > 10.8.0.221:  hopopt 40
                      09:16:10.640729 IP 192.168.11.132.46174 > 10.8.0.221.ssh: Flags [S], seq 2532807099, win 64240, options [mss 1308,sackOK,TS val 2976056274 ecr 0,nop,wscale 7], length 0
                      

                      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

                      • [^] # Re: Traceroute

                        Posté par  . É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  . Évalué à 3.

                          La cause première, c'est une règle de pare-feu. Tu n'aurais pas un fail2ban un peu agressif sur cette machine ?

                          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 tcpdump grâ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  . Évalué à 3.

              C'est difficile de savoir si tu ping bien la machine à laquelle tu pense.

              Ah bon ? Pour moi ça a toujours été une évidence, mais je veux bien quelques explications de "pièges à con" :)

              Ça par contre, tu ne l'avais pas dit il me semble

              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  . Évalué à 7.

                Ah bon ? Pour moi ça a toujours été une évidence, mais je veux bien quelques explications de "pièges à con" :)

                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  . É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  . Évalué à 2.

    Regarder l'option --mssfix d'openvpn

    • [^] # Re: problème de mtu ?

      Posté par  . É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 :

      #ping -s 1500 10.8.0.221
      PING 10.8.0.221 (10.8.0.221) 1500(1528) bytes of data.
      1508 bytes from 10.8.0.221: icmp_seq=1 ttl=63 time=175 ms
      1508 bytes from 10.8.0.221: icmp_seq=2 ttl=63 time=121 ms
      

      En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # firewall ?

    Posté par  . Évalué à 5.

    Salut,

    Une règle iptables

    iptables -L -n pour voir.

    • [^] # Re: firewall ?

      Posté par  . Évalué à 6.

      Bingo !!!

      Sur la passerelle récalcitrante je lis (entre autre…)

      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  192.168.11.132       0.0.0.0/0            multiport dports 22 /* blocklist */
      DROP       tcp  --  10.8.0.1             0.0.0.0/0            multiport dports 22 /* blocklist */
      

      É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  . Évalué à 6.

        Bon bin au moins c'est explicite :

        # cat /etc/config/blocklist 
        
        config dropbear
            option ip '10.8.0.1'
            option date '1590670564'
        
        config dropbear
            option ip '192.168.11.132'
            option date '1617196744'
        

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

      • [^] # Re: firewall ?

        Posté par  . É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.