Cette technique marche aussi en ipv6. Je crois que l'équivalent consiste à mapper le domaine sur ::.

D'ailleurs si ce n'est pas fait, le simple mapping vers 0.0.0.0 ne garantit le blocage que si tous les clients sont uniquement ipv4. Ça se fait rare de nos jours. Un client ipv6 continuerait à obtenir la vraie ipv6 du domaine.

ça utilise des filtres avec IPv4

Que veux-tu dire ? Le filtrage se fait en général sur le nom de domaine, pas sur l'IP. Je doute que tes filtres soient vraiment des listes d'IPv4 à bannir.

Et par curiosité, tu as essayé d'utiliser uniquement ipv6 ? Je me demande si ça serait encore une contrainte aujourd'hui. Est-ce qu'il y a encore des serveurs sur internet qui ne sont accessibles qu'en ipv4 ? Ou inversement des clients qui sont seulement ipv4 ?

Puisqu'il n'y a plus d'ipv4 disponible, je me dis qu'il doit déjà y avoir des particuliers qui n'ont que de la v6, non ? Le CGNAT n'est qu'un pansement qui removede l'inéluctable.

Je viens de revérifier. Peut-être que j'ai mal interprété ton premier message. Mais je tiens à éviter toute confusion : CGNAT n'existe pas en ipv6. Si tu as du CGNAT, c'est sur la partie stack ipv4 fournie par SFR en parallèle de la stack ipv6. C'est contraignant parce que l'ipv4 est plus facile à gérer que l'ipv6 donc on la préfère quand c'est possible.

Le support semble pouvoir rebasculer en ipv4 full stack (en insistant pas mal). Et sinon la solution ultime c'est d'abandonner l'ipv4 et de migrer totalement vers l'ipv6 qui permet un accès total. Tes services ne seront alors plus accessibles en ipv4. Je ne sais pas à quel point c'est encore gênant en 2024, ça.

Je m'auto-réponds : tu pensais peut-être au CGN pour faire un tunnel IPv6 => IPv4 comme visible ici? Dans ce cas, tu n'as pas vraiment de l'IPv6, correct ? Est-ce que les appareils de ton réseau ont une IPv6 (autre que des link-local en fe80:, j'entends) ?

Du CGNAT sur de l'IPv6 ? Tu es sûr que ça existe ? Ma compréhension, c'est que le CGNAT est une astuce pour ralentir l'épuisement des IPv4 disponibles, en attribuant une même IPv4 à plusieurs abonnés. Chaque abonné se voit attribuer une part des ports disponibles. Free m'a un jour passé sur ce mode sans prévenir mais c'est heureusement désactivable en demandant une IPv4 full stack.

qui ne permet donc pas de faire de la redirection de port

Ce n'est pas tout à fait vrai. Tu peux continuer à rediriger des ports mais si le FAI ne t'a pas attribué la première tranche des ports (les plus utiles pour faire de l'auto hébergement), l'intérêt est moindre. Tu ne pourras pas héberger de service https sur 443, par exemple.

Je ne suis pas sûr non plus que la notion de redirection de port ait encore un sens en IPv6. Pas au sens de la NAT en tout cas, qui est une techno typiquement IPv4, allant de pair avec les plages d'adresses privées (type 192.168.x.y). Tout ceci étant un contournement pour ralentir l'épuisement des IPv4 disponibles. En IPv6, il n'y a pas de risque d'épuisement donc les FAI attribuent une plage de 2^64 IPs à chaque abonné. Y a de quoi faire.

Quant à l'exposition par défaut du serveur SSH, je ne sais plus trop ce qu'il en est aujourd'hui mais à une époque pas si lointaine, Debian l'activait. Bon il fallait avoir coché l'option "serveurs usuels du système" ou un truc comme ça à l'install. Mais le serveur était configuré par défaut pour accepter les connexions par mot de passe, ce qui n'était pas glop glop.

Pour moi, le plus grand danger, ce sont les petits appareils comme les caméras. Combien sont déballées, branchées et restent là avec leur mot de passe "admin1234" d'usine ? Tant que la cam est derrière une NAT IPv4, le danger est moindre. Mais si elle devient publique, c'est beaucoup moins rigolo.

Oui, UPnP est une autre faille de sécurité qu'il vaut mieux désactiver à mon avis.

Contre la fédé avec des géants du domaine. Cet article de la quadrature du net sur le sujet est intéressant. Il évoque le précédent de XMPP et GTalk avant que Google transforme GTalk en Hangout et le sorte de XMPP. Le risque que Méta bouffe le fedivers après avoir capté son public est réel.

C'est aussi ce que je pense. Hélas les commentaires mis en avant en bas de l'article me font douter. J'espère que c'est juste une sélection biaisée.

Le risque est d'avoir une surintensité sur ton périphérique à 1000€, pour économiser sur un câble à 10€.

J'ai pas compris ce que tu voulais dire ici. Un câble ne peut pas causer une surintensité sur l'appareil qu'il alimente. En revanche, un câble de mauvaise qualité aura une impédance trop importante, ce qui causera une chute de tension telle que l'appareil n'aura pas la tension nécessaire et ne démarrera pas ou ne fonctionnera pas bien.

Un câble ne peut que limiter l'intensité du circuit, il ne peut pas l'augmenter. Ce n'est pas un composant actif comme peut l'être un générateur.

J'ai essayé de lire le post de Leung mais il a été supprimé on dirait.

If you can read French, this article gives a great counterpoint on the situation https://contre-attaque.net/2023/09/15/niger-un-diplomate-francais-otage-de-macron/ Macron might very well be up to escalating the situation to the point he can engage Niger militarily.

Ah mais c'était sur une commu dédiée et non sur France, je viens seulement de comprendre. Bon bah je m'abonne, alors, merci !

Dac, désolé pour le doublon que j'ai raté. Et effectivement, la vidéo est à juste titre excellemment bien notée !

Et d'ailleurs, voici le lien de la vidéo sur tournesol https://tournesol.app/entities/yt:kR3JaROyKuA que j'aurais dû utiliser dans la première place !

J'ai un serveur Debian chez moi qui expose un mélange de partages NFS/Samba accessibles par les machines du réseau local et un Nextcloud avec synchro sur les machines locales ainsi que les smartphones. Historiquement, je n'ai eu que les partages NFS pendant des années avant d'ajouter Nextcloud et j'étais initialement un peu réticent à tout passer brutalement sous Nextcloud (au cas où ça n'aurait pas bien marché) donc c'est un peu le bronx parce que j'ai des documents sur l'un et pas sur l'autre. A terme, faut que je franchisse le pas de tout passer sur Nextcloud.

Pour les sauvegardes : un script maison basé sur rsync qui sauvegarde quotidiennement le /etc du serveur ainsi que les données partagées (incluant les données des différents services web, dont Nextcloud) sur une machine locale (pour le côté pratique) ainsi que sur un raspberry loin de chez moi (pour le côté sécurité).

J'utilise rsync en mode incrémental avec l'option --link-dest (crée un hard link quand un fichier n'a pas changé depuis le précédent snapshot, cf cet article) pour ne payer que le coût de ce qui a changé tout en ayant un snapshot intégral chaque jour. Ca rend le filesystem du backup un peu lent à maintenir quand il faut supprimer des vieux snapshots mais c'est sacrément pratique et économe en espace disque.

Les autres machines locales ou les téléphones ne sont pas censés contenir des données importantes donc je ne les sauvegarde pas (enfin, un peu mais c'est très artisanal donc je ne compte pas dessus).

EDIT : mise en forme, ajout de l'info sur --link-dest et l'article explicatif

Mon relevé de température en région lyonnaise ces derniers jours :

Show

Ça fait une dizaine d'années que j'ai une sonde de température extérieure et je vois nettement la translation vers le haut d'années en années. Je plains ceux qui vivent en appart' sans possibilité d'aérer efficacement la nuit.