Fausse alerte, je n’avais pas fait d’erreur et même après reboot, toujours la même annonce et ip6tables-save retourne l’invite.
[code]ricardo@jessie-ssd:~$ sudo update-rc.d "default"
update-rc.d: error: not enough arguments
usage: update-rc.d [-n] [-f] remove
update-rc.d [-n] disable|enable [S|2|3|4|5]
-n: not really
-f: force
The disable|enable API is not stable and might change in the future.[/code]
Mon script :
[code]#!/bin/sh
case “$1” in
’start’)
/sbin/ip6tables-restore < /etc/config_parefeuIP6
RETVAL=$?
;;
‘stop’)
/sbin/ip6tables-save > /etc/config_parefeuIP6
RETVAL=$?
;;
‘clean’)
/sbin/ip6tables -t filter -F
/sbin/ip6tables -t nat -F
/sbin/ip6tables -t mangle -F
/sbin/ip6tables -t raw -F
/sbin/ip6tables -t filter -P INPUT ACCEPT
/sbin/ip6tables -t filter -P OUTPUT ACCEPT
/sbin/ip6tables -t filter -P FORWARD ACCEPT
/sbin/ip6tables -t nat -P PREROUTING ACCEPT
/sbin/ip6tables -t nat -P POSTROUTING ACCEPT
/sbin/ip6tables -t nat -P OUTPUT ACCEPT
/sbin/ip6tables -t mangle -P PREROUTING ACCEPT
/sbin/ip6tables -t mangle -P OUTPUT ACCEPT
/sbin/ip6tables -t mangle -P POSTROUTING ACCEPT
/sbin/ip6tables -t mangle -P FORWARD ACCEPT
/sbin/ip6tables -t mangle -P INPUT ACCEPT
/sbin/ip6tables -t raw -P OUTPUT ACCEPT
/sbin/ip6tables -t raw -P PREROUTING ACCEPT
RETVAL=$?
;;
‘restart’)
$0 stop && $0 start
RETVAL=$?
;;
*)
echo "Usage: $0 { start | stop | restart | clean}"
RETVAL=1
;;
esac
exit $RETVAL
[/code]
Les règles envoyées par ip6tables-save récupéré sans faire de update-rc.d “default” et sans rebooter
[code]# Generated by ip6tables-save v1.4.21 on Sat Feb 13 01:44:49 2016
*filter
:INPUT DROP [10:720]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1:72]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m comment --comment SSH -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -m comment --comment CUPS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -m comment --comment ZIMBRA -j ACCEPT
COMMIT
Sitôt après, le config_parefeuIP6 se vide.
Je crois savoir que tu es fâché avec les pages de manuel mais quand même, la syntaxe applicable est mentionnée dans les 5 premières lignes. Quand j’écris “seulement”, c’est pour dire qu’on n’a pas besoin de spécifier start/stop, les niveaux d’exécution et numéros de séquence. Il faut évidemment toujours spécifier le nom du script.
Et au temps pour moi, il s’agit de “defaults” au pluriel.
Non, votre Honneur ! je teste toujours toutes les possibilités et j’avais bien fait l’essai avec :
update-c.d "default"
update-c.d mon_parefeuIP6 "default"
update-c.d /etc/init.d/mon_parefeuIP6 "default"
Mais, je n’avais pas non plus fait attention à l’absence du S.
Je teste tout à l’heure.
Tout s’est bien passé mais je suis toujours en IPv4
J’ai recommencé tout le processus, j’ai vérifié tous les fichiers et j’ai la réponse à ip6tables-save qui va bien, j’ai même rebooté la machine, mais “Wat is my IP” et d’autres moyens me renvoient tous mon IP v4.
Quelque chose qui doit bloquer dans ip6tables ?
[code]ricardo@jessie-ssd:~$ sudo ip6tables-save
[sudo] password for ricardo:
*filter
:INPUT DROP [29:4338]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [65:9567]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -m comment --comment SSH -j ACCEPT
-A INPUT -p tcp -m tcp --dport 631 -m comment --comment CUPS -j ACCEPT
-A INPUT -p tcp -m tcp --dport 143 -m comment --comment ZIMBRA -j ACCEPT
COMMIT
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [7:671]
:POSTROUTING ACCEPT [7:671]
COMMIT
*mangle
:PREROUTING ACCEPT [59:9387]
:INPUT ACCEPT [59:9387]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [65:9567]
:POSTROUTING ACCEPT [90:13401]
COMMIT
*raw
:PREROUTING ACCEPT [59:9387]
:OUTPUT ACCEPT [65:9567]
COMMIT
[/code]
Si l’IPv6 fonctionne sans filtrage, alors c’est ton jeu de règles qui bloque. Sinon, il y a un autre problème à résoudre avant de s’attaquer au filtrage (si on mélange tout en même temps on ne s’en sortira jamais).
Si c’est bien ton jeu de règles qui bloque, tu as dû manquer le passage où j’écrivais :
Complément d’information, ayant retrouvé mes notes :
Pour des exemples (incomplets) de règles, voir cet autre fil récent sur l’IPv6 : https://www.debian-fr.org/iptables-et-ipv6-t54564.html
[quote=“PascalHambourg”]Si l’IPv6 fonctionne sans filtrage, alors c’est ton jeu de règles qui bloque. Sinon, il y a un autre problème à résoudre avant de s’attaquer au filtrage (si on mélange tout en même temps on ne s’en sortira jamais).
Si c’est bien ton jeu de règles qui bloque, tu as dû manquer le passage où j’écrivais :
Complément d’information, ayant retrouvé mes notes :
Pour des exemples (incomplets) de règles, voir cet autre fil récent sur l’IPv6 : https://www.debian-fr.org/iptables-et-ipv6-t54564.html[/quote]
Ça ne peut qu’être les règles, à mon avis, Sans parefeu, hier soir, j’accédais à mon IPv6.
En effet, je ne me suis pas occupé de ça, peux-tu me dire ce que je dois entrer conrètement, merci.
EDIT :
Mes machines ne sont que SSH au niveau serveur.
Je peux, mais je pense que tu aurais pu les écrire toi-même à partir des informations fournies.
# NDP pour toute interface de type broadcast
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-solicitation -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type neighbour-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type router-advertisement -m hl --hl-eq 255 -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type neighbour-solicitation -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type neighbour-advertisement -j ACCEPT
ip6tables -A OUTPUT -p icmpv6 --icmpv6-type router-solicitation -j ACCEPT
La correspondance “hl” sert à vérifier que les paquets NDP entrants proviennent bien du réseau local et pas au-delà. Dans le cas contraire ils auraient une valeur de “hop limit” (nombre de sauts restants) forcément inférieure à 255 (valeur maxi) puisqu’ils auraient transité par au moins un routeur (ce qui n’est pas censé arriver), décrémentant la valeur.
Une version plus simple mais moins stricte basée sur l’état de suivi de connexion :
ip6tables -A INPUT -m state --state UNTRACKED -j ACCEPT
ip6tables -A OUTPUT -m state --state UNTRACKED -j ACCEPT
Tu peux ignorer les règles de la chaîne OUTPUT si sa politique par défaut est ACCEPT.
Client ou serveur, cela n’a pas d’incidence sur le protocole NDP. La différence est entre hôte et routeur. Néanmoins tes règles autorisent les connexions entrantes SSH, IMAP et CUPS. Ce n’est utile que si ces services écoutent en IPV6 (cf. [mono]netstat -6ln[/mono]) et si tu veux qu’ils soient accessibles en IPv6, pas seulement depuis ton LAN mais aussi depuis l’extérieur. Pas convaincu que ce soit souhaitable pour CUPS notamment. Tu peux ajouter des critères pour restreindre en fonction de l’adresse source, par exemple à ton seul préfixe /60 :
Bingo 
Bien que OUTPUT soit ACCEPT chez moi, j’ai quand même placé les dernières lignes. Si un jour je devais modifier la table en DROP, ça serait fait.
Je vais faire aussi pour ma seconde machine.
La cohabitation avec le pare-feu en IPv4 ne semble pas poser de problème. Est-ce qu’il serait préférable de le désactiver, sans pour ça le supprimer complètement, sachant que les noms de fichier sont différents ?
Plus qu’à faire un tuto “pour les nuls” avec ces nouvelles données.
La semaine prochaine, si tout va bien.
Merci, Pascal.
Avec la double pile, IPv4 et IPv6 (adressage, routage, filtrage…) sont indépendants. Si tu veux tu peux appliquer les règles iptables et ip6tables avec le même script.
Comme ça ne pose pas de problème, je préfère laisser en l’état, ça m’évitera les erreurs possibles dans X mois, où je ne me souviendrai plus de ce que je fais aujourd’hui.
À ce sujet, ajouter des commentaires autres qu’à la fin d’une règle, peut-on avec un simple # en tête de ligne ?
Comment le faire, a posteriori, en éditant le fichier /etc/config_parefeu ?
autrement ?
=================
EDIT :
Quand on tape [mono]/sbin/ifconfig[/mono], on lit plusieurs ligne d’IPs :
[mono]adr inet6: 2a01:xxxxxxxxxxxx Scope:Global
adr inet6: fe80:zzzzzzxxxxxx Scope:Lien
adr inet6: 2a01:xxxxxxyyyyyy Scope:Global[/mono]
Je suppose que la première ligne correspond à l’IP de la machine sur laquelle on se trouve, et que la troisième montre celle d’une autre machine du LAN.
Ma supposition est-elle bonne ?
Non, toutes ces adresses IPv6 appartiennent à l’interface.
Celle marquée “Scope:Lien” (c’est un peu bizarre de mélanger un mot anglais et un mot français), qui devrait commencer par “fe80” (aurais-tu mal copié-collé ?), est une adresse dite “link local” basée sur l’adresse MAC de l’interface, dont la portée et l’usage sont limités au domaine de diffusion (réseau local) pour les opérations de bas niveau telles que la résolution NDP (remplaçant la résolution ARP).
Celles marquées “Scope:Global” sont basées sur le ou les préfixes globaux annoncés par le routeur IPv6 (ici la freebox) qui commencent par “2a01” chez Free. Pour chaque préfixe global, le noyau génère une adresse permanente basée sur l’adresse MAC de l’interface, et une ou plusieurs adresses temporaires basées sur un identifiant pseudo-aléatoire afin d’améliorer le respect de la vie privée (“Privacy extensions”). Un réglage du noyau permet de spécifier quel type d’adresse on souhaite utiliser en priorité par défaut, chacun ayant ses avantages et inconvénients.
PS : Tu peux ajouter des commentaires en début de ligne commençant par # dans le fichier généré par iptables-save mais ils seront écrasés lorsque le fichier sera regénéré. J’ignore si on peut en mettre en fin de ligne.
Tu peux aussi mettre des commentaires directement dans les règles créées avec l’option [mono]-m comment --comment “commentaire”[/mono].
Merci.
Pour les commentaires dans la ligne de la règle, je sais et je fais déjà.
Sur une machine en texte seul (mon serveur de videosurveillance), quelle commande permet de connaitre l’IPv6 ?
Sinon, j’ai configuré proprement et testé mes trois machines en IPv6.
En espérant pouvoir continuer tout cet apprentissage que tu nous as apporté.
[mono]ifconfig[/mono] ou [mono]ip -6 addr[/mono] affiche les adresses IPv6 attachées aux interfaces réseau.
[mono]ifconfig[/mono] ou [mono]ip -6 addr[/mono] affiche les adresses IPv6 attachées aux interfaces réseau.[/quote]
Vu !
[mono]ip -6 addr[/mono] court à taper, en simple utilisateur et clair .
J’ai porté la modification dans mon message précédent, concernant l’adresse MAC.
Pour que ce soit parfait tu aurais pu aussi mettre des “zzzz” dans une des deux adresses globales pour marquer la partie commune avec l’adresse lien-local, basée sur l’adresse MAC.
A yé !
Ce n’est pas ridicule cette restriction, alors que l’IP V6 est accessible ?
Je te remercie d’avoir porté cette information à ma connaissance.
Ce serait ridicule si l’IPv4 était une technologie tombée en désuétude dont on pouvait désormais se passer sans gros inconvénient. Mais c’est loin d’être le cas. L’IPv6 ne permet de communiquer qu’avec d’autres “sites” (au sens large, je ne parle pas seulement de sites web) qui sont eux aussi en IPv6. Or il reste encore de gros morceaux d’internet qui ne sont toujours pas accessibles en IPv6 mais seulement en IPv4. Si tu veux en faire l’expérience, il te suffit de couper l’IPv4 sur ta machine et voir ce qui marche encore, comme ce forum.
Ce partage de ports est à peine moins pire que du NAT opérateur (Carrier-grade NAT ou CG-NAT évoqué dans les commentaires de l’article) où le client ne reçoit carrément qu’une adresse IP privée. J’y vois immédiatement plusieurs problèmes :
Je suppose qu’il s’agit des ports TCP et UDP, mais quid des autres protocoles, ceux qui ont des ports mais sont moins répandus comme SCTP (quel dommage), et surtout ceux qui n’ont pas de ports comme ICMP (pourra-t-on encore utiliser ping), GRE (utilisé par les VPN PPTP), IPSec ESP/AH, 6in4, IP-in-IP… ? En gros tous les protocoles déjà laissés pour compte par le NAT.
Il y aura forcément du PAT (port address translation) opérateur quand un poste client utilisera un port source hors de la plage allouée à l’abonné. Cela a les mêmes inconvénients que le NAT.
Le mode de fonctionnement sans NAT (appelé abusivement “bridge”) de la box est-il encore disponible ?
Quid des redirections de ports et DMZ ?
Ça va compliquer l’identification en cas d’infraction, de bannissement… L’adresse IPv4 publique seule ne suffira pas puisqu’elle peut être partagée entre plusieurs abonnés, il faudra aussi prendre en compte le port source. Pas sûr que cette information figurer dans tous les logs, les en-têtes de mails…
En tout cas ce genre d’initiative illustre, s’il en était encore besoin, la gravité de la pénurie d’adresses IPv4 qui est à l’origine du développement d’IPv6 et qui est maintenant aigüe. IPv4 qu’on essaie de faire durer le plus longtemps possible avec les conséquences négatives que l’on voit, pour le plus grand malheur de tous.
Et ne me dites pas qu’il n’y avait pas de pénurie avant puisque chaque abonné recevait une adresse IPv4 pour lui seul. Une seule adresse, quand la plupart des foyers ont plusieurs appareils connectés, alors qu’on distribue sans compter des milliards d’adresses IPv6 qui ne servent à rien. Si ce n’était pas déjà de la pénurie…
[quote=“PascalHambourg”]Je te remercie d’avoir porté cette information à ma connaissance.
…