Je ne connaissais pas et je n’ai jamais porté ces deux ports sur mon parefeu.
Je viens de voir qu’ils géraient (certainement pas le bon terme) BOOTP server et BOOTP client.
Qu’est-ce exactement ?
BOOTP est l’ancêtre de DHCP qui utilise les mêmes ports.
Réponse de Normand : une qui ne gêne pas l’usage normal que tu comptes faire tout en préservant les ressources. Non, je ne me mouille pas, mais il n’y a pas de réponse universelle.
Avec la correspondance length. Mais cela risque de ne pas être efficace en IPv6 si la limite de taille est supérieure à la taille maximum des paquets (MTU) car les paquets de taille supérieure sont fragmentés et chaque fragment a une taille inférieure ou égale à la MTU. (En IPv4 le problème est masqué par conntrack qui réassemble les fragments).
A priori (mais ça m’étonne que tu sois passé à coté), il y a le module nf_conntrack_ipv6 qui peut/doit (?) procèder lui aussi à une defragmentation de l’ipv6.
Mais c’est juste ce que j’ai trouvé sur wikipedia par curiosité: je n’ai rien trouvé détaillant comment ça marche, et l’info peut dater de l’ipv6 expérimental et trainer là.
[mode delirium:engage]
Bon, Monsieur le Normand, beh oui, Pascal Le Normand 
- alors, là, PTDR 
; suis peut-être “sous influence”, mais ça ne m’empêche pas d’avoir de l’humour … hihihihihi-
mais non, pas Le Normand, puisqu’on te dit Hambourg … Quoi, de Hambourg ? mais non … tsss, laisse tomber, c’est pas grave -
y comprend rien lui, alors … ouais, c’est normal, fais pas attention.
[/mode delirium:ended]
Je me doute qu’il n’y a pas de réponse universelle, le propos est de comprendre justement comment “faire la recette”, quels éléments prendre en compte …
Exemple : choisir 3/s, soit, mais pourquoi, et pourquoi pas 10/s … etc, etc …
Or, ça, personne ne veut livrer ce genre d’informations.
Ok, creusons … un début de piste
Merci
C’est un point que je n’ai pas encore réussi à éclaircir. Du fait qu’un routeur IPv6 ne doit pas fragmenter, le conntrack IPv6 ne faisait qu’un réassemblage “virtuel”, et ensuite les fragments originels poursuivaient leur chemin. Ça a un peu changé depuis le noyau 3.7 et l’introduction du NAT IPv6, cf. la description suivante extraite du changelog :
commit 4cdd34084d539c758d00c5dc7bf95db2e4f2bc70
Author: Patrick McHardy kaber@trash.net
Date: Sun Aug 26 19:13:58 2012 +0200
netfilter: nf_conntrack_ipv6: improve fragmentation handling The IPv6 conntrack fragmentation currently has a couple of shortcomings. Fragmentes are collected in PREROUTING/OUTPUT, are defragmented, the defragmented packet is then passed to conntrack, the resulting conntrack information is attached to each original fragment and the fragments then continue their way through the stack. Helper invocation occurs in the POSTROUTING hook, at which point only the original fragments are available. The result of this is that fragmented packets are never passed to helpers. This patch improves the situation in the following way: - If a reassembled packet belongs to a connection that has a helper assigned, the reassembled packet is passed through the stack instead of the original fragments. - During defragmentation, the largest received fragment size is stored. On output, the packet is refragmented if required. If the largest received fragment size exceeds the outgoing MTU, a "packet too big" message is generated, thus behaving as if the original fragments were passed through the stack from an outside point of view. - The ipv6_helper() hook function can't receive fragments anymore for connections using a helper, so it is switched to use ipv6_skip_exthdr() instead of the netfilter specific nf_ct_ipv6_skip_exthdr() and the reassembled packets are passed to connection tracking helpers. The result of this is that we can properly track fragmented packets, but still generate ICMPv6 Packet too big messages if we would have before. This patch is also required as a precondition for IPv6 NAT, where NAT helpers might enlarge packets up to a point that they require fragmentation. In that case we can't generate Packet too big messages since the proper MTU can't be calculated in all cases (f.i. when changing textual representation of a variable amount of addresses), so the packet is transparently fragmented iff the original packet or fragments would have fit the outgoing MTU.
Le plus sûr, c’est encore de faire des tests pour vérifier.
Parce que c’est suffisant pour ton besoin que tu es le seul à pouvoir définir.
Si on doit débattre sur le présent fil, il serait souhaitable que tu ajoute une réponse dans ce sens avec le lien vers ici.
Sinon, les demandes vont fuser dans T&A.
Ton œuvre me semble parfaite mais j’attends la vérification et le feu vert du Chef pour l’appliquer à mon futur serveur.
C’est fait !
Loin s’en faut, je suis justement en train de me relire et corriger pour essayer de prendre en compte tout ce qui a été dit par PascalHambourg et PengouinPdt au-dessus.
Je n’ai pas encore tout lu mais une petite info mineure en passant à prendre en compte pour la partie réinitialisation du script (clean), assez ancienne mais peut-être méconnue. Depuis le noyau 2.6.36, la table nat a aussi une chaîne INPUT.
OK, merci à @PascalHambourg et @PengouinPdt pour les conseils 
.
J’ai tenté de tout intégrer dans le T&A, et je pense qu’on est bons ! La seule chose que je ne comprends toujours pas (et qui n’est donc qu’un bête copier/coller d’un post de Pascal) sont les règles NDP en icmpv6. Il y a donc peut-être des choses à y corriger.
Si vous pouviez faire une petite relecture, ça me rassurerait ! À vot’ bon cœur !
Édit : rappel de l’URL du T&A : https://www.debian-fr.org/t/pare-feu-ipv4-ipv6-versions-bureau-et-serveur.
Tu as lu cela où ?
Le manpage 1.4.21 n’en parle pas !
@seb-ksl: ça me semble correct …
Juste un léger détail, dans les règles ND-IPv6 pour serveur, ajoute une ligne vide entre les écritures INPUT et celles concernant OUTPUT … il m’a fallu quelques secondes pour comprendre la différence ténue … histoire d’aérer 
C’est fait
Pour un SERVEUR de courrier, que l’on n’utilise en direct seulement pour recevoir, l’expédition se faisant via le serveur du FAI (Free), je ne pense pas être obligé d’autoriser et de rediriger le port 25 ?
Pour la réception, j’autorise et je redirige le port 993 (imaps), suis obligé d’y ajouter le port 143 (imap2) ?
Merci pour ces précisions
@ricardo: Alors, à moins que je ne me trompe sérieusement …
Deux choses à gérer :
1/Il te faut envoyer, cela passe par SMTP(S?), donc à moins d’un changement érigé et dicté par le serveur du FAI, c’est le port 25 TCP, voire 465 TCP - pour sa version S - en sortie …
Il te faut bien-sûr autoriser les paquest relatifs ou établis en entrée correspondants.
2/ Autoriser l’entrée, protocole TCP, port 993, si tu ne souhaites ABSOLUMENT la connexion sur ce port - tu n’es en rien obligé d’avoir le port 143, et 993 sur lesquels les sockets s’ouvrent.
Il te faut bien-sûr autoriser là, aussi, les paquets relatifs et/ou établis, en entrée, comme en sortie.
Voili, voilou …
PS : Ne pas hésiter à corriger, si je me suis tromper
Les protocoles POP et IMAP ne servent que pour relever le courrier d’une boîte aux lettres. Donc à moins que ton serveur ne traite que des mails locaux ou les récupère sur d’autres serveurs de courrier par fetchmail ou équivalent, il va bien falloir un moyen de lui envoyer des mails depuis l’extérieur. C’est le rôle du protocole SMTP, qui utilise le port TCP 25 (en clair ou chiffrement explicite) ou 465 (chiffrement implicite).
Dans le changelog du noyau 2.6.36 :
commit c68cd6cc21eb329c47ff020ff7412bf58176984e
Author: Patrick McHardy kaber@trash.net
Date: Thu Jun 17 06:12:26 2010 +0200`
netfilter: nf_nat: support user-specified SNAT rules in LOCAL_IN`
Je reconnais que l’intitulé du patch n’est pas très parlant, et ce changement ne semble pas avoir été jugé assez important pour être mentionné par kernelnewbies.
http://kernelnewbies.org/Linux_2_6_36
Une phrase plus explicative est cachée au milieu de la description longue :
This patch adds a new INPUT chain to the NAT table and changes the targets performing SNAT to be usable in that chain.
Merci à vous deux.
Donc autorisation 25 et 993.
Salut tous,
J’ai un pc equipé avec du filaire et une carte wifi, selon si je me trouve au domicile j’utilise le filaire et en dehors le wifi, comment adapté ce script ?
Merci
Regarde donc ce post : Pare-feu IPv4/IPv6, versions bureau et serveur
Tu as exactement ce qu’il te faut pour une machine !
C’est bien sûr un script de base, à modifier selon tes besoins, mais dans le cas que tu décris, il ne devrait pas y avoir de modifications.
Ok, merci .