Forum Linux.général ipfilter, connexions établies, et délai

Posté par .
Tags : aucun
1
8
oct.
2009
Bonjour,

je remarque une chose qui me gêne pas mal avec ipfilter. J'ai une règle comme ça:

iptables --append FORWARD --match state --state ESTABLISHED,RELATED --jump ACCEPT

Très classique. Ca fonctionne.

Si j'ouvre une connexion qui ne transmet pas de données pendant 15 ou 20 minutes, ensuite il n'y a plus rien qui passe pour cette connexion.
Je constate ça avec ssh et vnc. Lorsque j'ai une connexion et que je réponds au téléphone, une fois l'appel terminé, plouf je n'ai plus la main :)

Si je supprime la règle, le problème disparaît.

La question est: comment allonger ou annuler ce délai ?
  • # netfilter et/ou ssh ?

    Posté par (page perso) . Évalué à 1.

    pour netfilter parmi ces entrées:
    ls -l /proc/sys/net/netfilter

    ou bien ssh

    http://pthree.org/2008/04/16/keeping-your-ssh-connection-ali(...)

    Système - Réseau - Sécurité Open Source

  • # Valeurs par défaut

    Posté par (page perso) . Évalué à 2.

    Utilise sysctl -a | grep conntrack pour visualiser les différentes valeurs. Par contre je ne sais pas où trouver la documentation pour savoir à quoi servent les paramètres en détail.
    Il y en a un nommé nf_conntrack_generic_timeout qui ressemble à la solution à ton problème.

    Quelqu'un sait où trouver la doc ?
  • # Ça ne vient peut-être pas de ton PC

    Posté par . Évalué à 3.

    Ce n'est pas forcément ton PC qui bug. J'en suis même quasiment sûr : c'est le modem de ton provider qui garde les connexions NATées un certains temps, et puis les jartes au bout d'un certains temps d'inactivité.

    Faudrait juste savoir si je ne me suis pas trompé sur le fait que tu parles de connexions à travers le net, et pas de connexions locales.
    • [^] # Re: Ça ne vient peut-être pas de ton PC

      Posté par . Évalué à 3.

      je suis du même avis.

      SSH, c'est une connexion TCP. Netfilter ne se base pas sur un délai pour connaître l'état de connexion, mais sur les paquets échangés. Tant qu'il n'y a pas de FIN/FIN-ACK ou TCP-RST il n'y a aucune raison que les paquets soient droppés.

      C'est facile à vérifier en rajoutant une règle LOG avant la règle DROP finale. Si des paquets sont droppés ils seront loggués. Si ils ne sont pas loggués, c'est que ce n'est pas netfilter le coupable...
      • [^] # Re: Ça ne vient peut-être pas de ton PC

        Posté par (page perso) . Évalué à 1.

        c'est vrai a un détail prêt: quand tu active du firewalling statefull (ce qui est automatique quand les règles font référence au états de connections) sur un routeur celui-ci doit garder un trace locale de toute les session ouvertes.

        Cette table (la table conntrack) n'est pas illimité aussi y a t'il des mechanisme de GC pour la nettoyer. Il faut donc compenser cela par l'activation du mechanisme tcp keepalive afin de générer en cas d'absence de traffic des paquet permettants aux divers pare-feu sur le chemin de savoir que la connection est toujours ouverte
        • [^] # Re: Ça ne vient peut-être pas de ton PC

          Posté par . Évalué à 2.

          Le keepalive c'est une bidouille crade. Un "bon" routeur est censé garder les connexions NATées aussi longtemps qu'il faut. S'il n'a plus assez de mémoire pour les garder, il faut qu'il le signale (ce serait intéressant de voir combien de connexions un routeur "classique" peut garder en mémoire. Pour une utilisation perso, les routeurs classiques devraient pouvoir supporter un nombre suffisant pour le "grand public". Ce n'est pas si énorme que ça (une dizaine d'octets par connexion ?) et si on a besoin de plus (beaucoup de machines avec beaucoup de connexions) on utilise un routeur professionnel, ou une bécane sous linux. Ou en dernier recours on peut aussi passer à IPv6 ...)
          • [^] # Re: Ça ne vient peut-être pas de ton PC

            Posté par (page perso) . Évalué à 1.

            Le peer to peer est un bon test dans ce cas.
            Atteint près de 62000 connections gardées en mémoire. ( 1Go de memoire )

            Il me semble avoir lu que le nb de connections conservées en mémoire est ajusté à la taille mémoire de la machine...
            ex: 256Mo <=> 16384 connections

            Système - Réseau - Sécurité Open Source

            • [^] # Re: Ça ne vient peut-être pas de ton PC

              Posté par . Évalué à 2.

              1024^3/62000 = 17318
              Je n'ai pas regardé en vrai, mais 17ko pour une connexion, ça me paraît énorme pour un kernel. Après, qu'une appli user-space prenne plus de place, OK, mais juste pour du routage, ça ne prendra pas autant. En plus, une appli P2P qui fait 62000 connexion, j'ai jamais vu ça .... (chez moi c'est juste quelques centaines au max)
              • [^] # Re: Ça ne vient peut-être pas de ton PC

                Posté par (page perso) . Évalué à 1.

                Je n'ai pas dit que l'appli avait 62000 connections, c'est juste le nombre de connections
                etablies conservées en mémoire par netfilter.
                Il me semble avoir lu qu'une connection prend 20 octets environ.
                C'est un calcul approximatif, la mémoire pour netfilter ne consomme pas tout, et heuresement...

                Système - Réseau - Sécurité Open Source

                • [^] # Re: Ça ne vient peut-être pas de ton PC

                  Posté par . Évalué à 2.

                  J'avoue ne pas trop comprendre ta réponse, et où tu veux en venir.

                  On parlait du conntrack qui bouffait de la mémoire, au final, avec 500o par connexion (avec un _x_ en français) ça nous fait 50Mo de RAM pour 100000 connexions, je trouve ça pas mal (oui, il faut changer le nombre max de connexions par défaut du kernel qui est assez faible).
  • # 500 octets par connection

    Posté par (page perso) . Évalué à 1.

    http://www.netfilter.org/documentation/FAQ/fr/netfilter-faq-(...)

    Système - Réseau - Sécurité Open Source

  • # memoire / nb connections

    Posté par (page perso) . Évalué à 1.

    http://209.85.229.132/search?q=cache:FtI89LOsWewJ:www.ssi.go(...)

    Système - Réseau - Sécurité Open Source

Suivre le flux des commentaires

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