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

Posté par gremous le 08 octobre 2009 à 13:35.

Étiquettes : aucune

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 nono14 (site web personnel) le 08 octobre 2009 à 14:23. É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 Kerro le 08 octobre 2009 à 15:01. É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 benoar le 10 octobre 2009 à 06:57. É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 nodens le 10 octobre 2009 à 15:36. É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 -=[ silmaril ]=- (site web personnel) le 10 octobre 2009 à 23:12. É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 benoar le 13 octobre 2009 à 00:47. É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 nono14 (site web personnel) le 13 octobre 2009 à 21:32. É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 benoar le 14 octobre 2009 à 05:44. É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 nono14 (site web personnel) le 14 octobre 2009 à 13:18. É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 benoar le 15 octobre 2009 à 08:06. É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 nono14 (site web personnel) le 14 octobre 2009 à 13:27. Évalué à 1.

http://www.netfilter.org/documentation/FAQ/fr/netfilter-faq-(...)
Système - Réseau - Sécurité Open Source
# memoire / nb connections

Posté par nono14 (site web personnel) le 14 octobre 2009 à 13:32. É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.