Forum Linux.noyau Pourquoi ça (SSH de l’hôte vers l’invité) ça passe, mais d’autres port non ?

Posté par  . Licence CC By‑SA.
Étiquettes :
1
31
juil.
2019
Host is up (0.00035s latency).

PORT     STATE    SERVICE
22/tcp   open     ssh
80/tcp   filtered http
161/tcp  filtered snmp
162/tcp  filtered snmptrap
443/tcp  filtered https
5000/tcp filtered upnp

Mais bon, sang, le FW de l’hôte laisse bien passer ça (j’ai même essayé d’arrêter shorewall et de mettre les policies à ACCEPT, rien à faire, et puis quand j’ai des DROP je les vois… je ne peux pas me connecter de mon hôte vers mon invité, en dehors de SSSH ?!

Il va sans dire qu’il n’y a pas de règles iptables sur l’invité en question et un netstat montre que ce qui doit écouter écoute :

   # netstat -atupn -4
Connexions Internet actives (serveurs et établies)
Proto Recv-Q Send-Q Adresse locale          Adresse distante        Etat        PID/Program name    
tcp        0      0 192.168.122.200:5000    0.0.0.0:*               LISTEN      12092/httpd         
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1208/sshd           
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1736/master         
tcp        0      0 192.168.122.200:22      192.168.122.1:58730     ESTABLISHED 11967/sshd: root@pt 
tcp        0      0 192.168.122.200:36350   192.168.122.200:5000    TIME_WAIT   -                   
udp        0      0 127.0.0.1:323           0.0.0.0:*                           772/chronyd

Visiblement je me rends compte que virtd filtre des trucs de sa propre initiative :

Est-ce que ça auraut un rapport avec ça ? :

# virsh nwfilter-list
 UUID                                   Name
-----------------------------------------------------------------
 f0095d3c-2a43-4fdb-90be-367351e746d0   allow-arp
 ea2d0580-dfe5-4f72-b45b-ebb6ccc36f9f   allow-dhcp
 16545e1c-4eab-4c7c-8cf5-9ac69a63c192   allow-dhcp-server
 f1f3e58b-067b-46da-b128-c65281ab1d25   allow-incoming-ipv4
 42670326-c796-4ed7-8147-4db92f3c0877   allow-ipv4
 249a164c-0f06-46a7-ad15-ced2cb2d577c   clean-traffic
 030d6745-cb75-445e-aaee-c30c21264e6a   clean-traffic-gateway
 c7fabe81-b6fe-435a-852a-fca898139ca0   no-arp-ip-spoofing
 b7cb5aef-4af9-4e45-af07-3c29989c1dc1   no-arp-mac-spoofing
 c4752f50-46a5-4253-a7e7-78242aabca28   no-arp-spoofing
 cb9b2de9-96d2-4563-8faf-423513af84d2   no-ip-multicast
 42861a2e-a7ca-4cd4-8332-e2b8e47cce99   no-ip-spoofing
 087a28fc-d43f-4e8d-8e59-2c40756aa7b3   no-mac-broadcast
 1e48e5d2-f9eb-4190-b240-1718ed086543   no-mac-spoofing
 5e592d8a-ac5f-4e0a-acb2-cf804b3ad389   no-other-l2-traffic
 e829939a-52be-4250-9ad4-57111757d845   no-other-rarp-traffic
 3c43389d-acf7-423d-91dd-be70e8fbfba5   qemu-announce-self
 124c42fb-0cfc-4c22-a10f-deb4d1080962   qemu-announce-self-rarp

# virsh nwfilter-dumpxml allow-ipv4
<filter name='allow-ipv4' chain='ipv4' priority='-700'>
  <uuid>42670326-c796-4ed7-8147-4db92f3c0877</uuid>
  <rule action='accept' direction='inout' priority='500'/>
</filter>

Par où dois-je commencer ?

  • # tcpdump/wireshark

    Posté par  (site web personnel) . Évalué à 2.

    Dans ces cas-la, j'aime bien utiliser tcpdump/wireshark. Cela permet de voir quels paquets passent (syn ack)

  • # juste au cas ou

    Posté par  . Évalué à 2.

    sans vouloir insulter ton cerveau, pour arrêter shorewall tu modifie bien le fichier /etc/default/shorewall et tu met la valeur kivabien a : no

    et ensuite tu redémarre.

    et depuis de nouvelle version de shorewall, la config des interface nécessite un poil de réflexion.

    moi je resterai avec shorewall jusqu'a ce que cela marche.

    • [^] # Re: juste au cas ou

      Posté par  . Évalué à 3.

      Tu peux insulter mon intelligence aussi fort que tu veux, si ça permet de résoudre mon problème !

      Non, je fais shorewall stop puis iptables -P ACCEPT INPUT (idem avec OUTPUT et FORWARD)

      Avec ça « tout passe » ? Non ?

      Ensuite shorewall start pour remettre en place les règles.

      • [^] # Re: juste au cas ou

        Posté par  . Évalué à 2. Dernière modification le 31 juillet 2019 à 21:28.

        il me semble que si tu fait shorewall stop, cela risque de merdouiller grave avec les regle iptable que tu rentre par la suite, j'ai du le lire dans la doc il y a longtemps :).

        tu devrais vraiment soit supprimer shorewall, soit ne pas le lancer au demarrage avec /etc/default/shorewall

        et continuer tes essais

    • [^] # Re: juste au cas ou

      Posté par  . Évalué à 3. 

         WARNING: The CHAIN_SCRIPTS configuration option is no longer supported /etc/shorewall/shorewall.conf (line 147)
   WARNING: The INLINE_MATCHES configuration option is no longer supported /etc/shorewall/shorewall.conf (line 183)
   WARNING: The LOAD_HELPERS_ONLY configuration option is no longer supported /etc/shorewall/shorewall.conf (line 191)
   WARNING: The MAPOLDACTIONS configuration option is no longer supported /etc/shorewall/shorewall.conf (line 199)
   WARNING: The MODULE_SUFFIX configuration option is no longer supported /etc/shorewall/shorewall.conf (line 205)

      Je ferais peut-être bien de repartir de zéro au niveau de la configuration de Shorewall.

      Quand je fais iptables -L -v je vois pas les règles correspondantes à mes règles shorewawll… Pourtant avant ça marchait :/

      Bon, je m’y penche pas ce soir de toute façon :)

      • [^] # Re: juste au cas ou

        Posté par  . Évalué à 3. Dernière modification le 31 juillet 2019 à 21:18. 

        ERROR: Unknown Action (Drop) in DROP_DEFAULT setting /usr/share/shorewall/actions.std (EOF)

        Complètement pété en fait mon shorewall :/

  • # Bon

    Posté par  . Évalué à 3.

    J’ai viré Shorewall.

    Le routage me semble OK, je peux pinguer de l’hôte vers l’invité et inversement.

    Donc pour moi, mais je peux me tromper, le pb est forcément au niveaudes filtrage "nwfilter" de la la virtualisation, non ?

    • [^] # Re: Bon

      Posté par  . Évalué à 3.

      si en virant shorewall ca refonctionne
      le probleme vient de shorewall, pas de la virtualisation

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.