détails de / proc / net / ip_conntrack / nf_conntrack

Je suis à la recherche d'une documentation détaillée sur le contenu des fichiers /proc/net/nf_conntrack et/ou /proc/net/ip_contrack sur les systèmes linux.

Oui, je sais, il existe de nombreux utilitaires qui peut me montrer le contenu de ces fichiers dans un format lisible par l'homme, mais... j'aimerais le faire sur un routeur SOHO, avec de la Tomate USB firmware (par Shibby).
Le optware autant que je sache, obsolète et la entware ne contient aucun de ces utilitaires, donc je voudrais écrire un script au lieu d'eux, mais je n'ai pas trouver une description détaillée de ces fichiers. 🙁

source d'informationauteur

  1. 27

    Le format d'une ligne de /proc/net/ip_conntrack est la même que pour /proc/net/nf_conntracksauf les deux premières colonnes sont manquantes.

    Je vais essayer de résumer le format de ce fichier, ce que je comprends de la net/netfilter/nf_conntrack_standalone.cnet/netfilter/nf_conntrack_acct.c et la net/netfilter/nf_conntrack_proto_*.c noyau fichiers sources. Le terme layer se réfère à la OSI couche de protocole modèle.

    • Première colonne: Le protocole de couche réseau name (eg. ipv4).
    • Deuxième colonne: Le protocole de couche réseau numéro.
    • Troisième colonne: La transmission de la couche de protocole name (eg. tcp).
    • Quatrième colonne: La transmission de la couche de protocole de numéro.
    • Cinquième colonne: secondes jusqu'à ce que l'entrée est invalidé.
    • Sixième colonne (Pas tous les protocoles): l'état de La connexion.

    Toutes les autres colonnes sont nommées (key=value) ou représentent des drapeaux ([UNREPLIED][ASSURED]...). Une ligne peut contenir jusqu'à deux colonnes ayant le même nom (par exemple. src et dst). Ensuite, la première occurrence se rapporte à la demande de la direction et de la deuxième occurrence se rapporte à la réponse de la direction.

    Signification des drapeaux:

    • [ASSURED]: Le trafic a été vu dans les deux (ie. demande et réponse).
    • [UNREPLIED]: La circulation n'a pas été vu dans la réponse de la direction, mais. Dans le cas où la connexion de suivi cache débordements, ces connexions sont supprimées en premier.

    Veuillez noter que certains noms de colonnes n'apparaissent que pour des protocoles spécifiques (par exemple. sport et dport pour TCP et UDP, type et code pour ICMP). D'autres noms de colonne (par exemple. mark) n'apparaissent que si le noyau a été construit avec des options spécifiques.

    Exemples:

    • ipv4 2 tcp 6 300 ESTABLISHED src=1.1.1.2 dst=2.2.2.2 sport=2000 dport=80 src=2.2.2.2 dst=1.1.1.1 sport=80 dport=12000 [ASSURED] mark=0 use=2 appartient à une connexion TCP à partir de l'hôte 1.1.1.2, port 2000, pour accueillir 2.2.2.2, le port 80, à partir de laquelle les réponses sont envoyées à l'hôte 1.1.1.1, port 12000, le calendrier dans cinq minutes. Pour cette connexion, les paquets ont été observés dans les deux directions.
    • ipv4 2 icmp 1 3 src=1.1.1.2 dst=1.1.1.1 type=8 code=0 id=32354 src=1.1.1.1 dst=1.1.1.2 type=0 code=0 id=32354 mark=0 use=2 appartient à une requête d'écho ICMP paquet à partir de l'hôte 1.1.1.2 pour accueillir 1.1.1.1 avec un attendu de l'écho du paquet de réponse de l'hôte 1.1.1.1 pour accueillir 1.1.1.2, le calendrier en trois secondes.

    La réponse de l'hôte de destination n'est pas nécessairement la même que la source de la demande d'accueil, comme le demande l'adresse de la source peut avoir été camouflés par la réponse de l'hôte de destination.

    Veuillez noter que les informations suivantes peuvent ne pas être à jour!

    Champs disponibles pour toutes les entrées:

    • bytes (si la comptabilité est activé, demande et réponse)
    • delta-time (si CONFIG_NF_CONNTRACK_TIMESTAMP est activé)
    • dst (demande et réponse)
    • mark (si CONFIG_NF_CONNTRACK_MARK est activé)
    • packets (si la comptabilité est activé, demande et réponse)
    • secctx (si CONFIG_NF_CONNTRACK_SECMARK est activé)
    • src (demande et réponse)
    • use
    • zone (si CONFIG_NF_CONNTRACK_ZONES est activé)

    Champs disponibles pour dccpsctptcpudp et udplite protocoles de couche de transmission:

    • dport (demande et réponse)
    • sport (demande et réponse)

    Champs disponibles pour icmp de transmission protocole de couche:

    • code (demande et réponse)
    • id (demande et réponse)
    • type (demande et réponse)

    Champs disponibles pour gre de transmission protocole de couche:

    • dstkey (demande et réponse)
    • srckey (demande et réponse)
    • stream_timeout
    • timeout

    Valeurs autorisées pour le sixième champ:

    • dccp de transmission protocole de couche
      • CLOSEREQ
      • CLOSING
      • IGNORE
      • INVALID
      • NONE
      • OPEN
      • PARTOPEN
      • REQUEST
      • RESPOND
      • TIME_WAIT
    • sctp de transmission protocole de couche
      • CLOSED
      • COOKIE_ECHOED
      • COOKIE_WAIT
      • ESTABLISHED
      • NONE
      • SHUTDOWN_ACK_SENT
      • SHUTDOWN_RECD
      • SHUTDOWN_SENT
    • tcp de transmission protocole de couche
      • CLOSE
      • CLOSE_WAIT
      • ESTABLISHED
      • FIN_WAIT
      • LAST_ACK
      • NONE
      • SYN_RECV
      • SYN_SENT
      • SYN_SENT2
      • TIME_WAIT
  2. -1

    Le fichier ip_conntrack ne contient que des ipv4 spécifiques conntrack entrées alors que nf_conntrack comprend à la fois ipv4 et ipv6 protocole conntrack entrées.

    nf_conntrack fichier est enregistré avec le système de fichiers proc à l'aide de code

    net/netfilter/nf_conntrack_standalone.c

    alors que ip_conntrack fichier est enregistré avec le système de fichiers proc par le code

    net/netfilter/nf_conntrack_l3proto_ipv4_compat.c