Marmotte a écrit 8 commentaires

Mon domaine est chez eux depuis 12 ans, jamais de problème (ni technique, ni autre).
J'aime bien leurs valeurs qui semblent sincères.

On peut définir des NS custom.
L'interface propose de modifier la zone DNS enregistrement par enregistrement ou avec un grand champ texte (interface "expert"), les modifications sont versionnées.

Point négatif pour certains, pas d'API, mais ça ne me dérange pas, je n'en ai pas l'utilité.

il me semble que la puissance du truc c'est tout de même d'en faire son seul et unique 2FA.

Ça dépend de l'implémentation du service.

De mémoire, sur GitLab, tu ne peux pas enregistrer une clé physique tant que tu n'as pas une autre méthode de 2FA déjà activée.

Merci pour cette présentation :)

Je trouve que le paragraphe "Tutoriel : Installer Wireguard côté serveur sur Debian/Ubuntu" est mal nommé, ça pourrait être "Tutoriel : Installer Wireguard sur Debian/Ubuntu" tout court, puisqu'il n'y a aucune notion de client ou serveur avec Wireguard, juste des peers qui se connectent entre eux.

Pour donner une autre idée/vision, je l'utilise sur des machines Debian dont le réseau est géré par systemd-networkd, et ça tombe bien, puisqu'il y est géré nativement depuis un bon moment.

Je n'installe aucun paquet sur les serveurs, uniquement le paquet wireguard-tools sur ma station de travail pour générer les clés avec la commande wg genkey | tee /dev/stderr | wg pubkey, ça affiche les deux dans la console sans écrire de fichier (la clé privée en premier, et la clé publique en dessous).
Pour les clés preshared, j'utilise juste wg genpsk sans rediriger dans un fichier, puisque je vais juste copier/coller les clés dans la conf.

Ensuite, je crée juste deux fichiers de conf par serveur :
/etc/systemd/network/50-wg0.netdev (avec des droits en root:systemd-network 0640 puisqu'il contient des secrets)

[NetDev]
Name=wg0
Kind=wireguard

[WireGuard]
PrivateKey=<server1_private_key>
# Port d'écoute, si la machine est joignable directement par d'autres
ListenPort=<port>

[WireGuardPeer]
PublicKey=<server2_public_key>
PresharedKey=<preshared_key>
# Adresse de la machine distante, si elle est joignable directement
Endpoint=<remote_peer_public_ip>:<port>
AllowedIPs=<remote_peer_vpn_ip>/32
AllowedIPs=<remote_subnet1>/<mask>
AllowedIPs=<remote_subnet2>/<mask>

/etc/systemd/network/50-wg0.network

[Match]
Name=wg0

[Network]
Address=<server1_peer_vpn_ip>/<mask>

[Route]
Destination=<remote_subnet1>/<mask>
Scope=link

[Route]
Destination=<remote_subnet2>/<mask>
Scope=link

Un restart du service systemd-networkd et… tadaaa !

Bonus : Si le réseau de la machine n'est pas géré par systemd-networkd, on peut quand même l'utiliser pour Wireguard en lui demandant d'ignorer les autres interfaces avec quelque chose comme :

[Match]
Name=!en* wl*

Chez moi, j'ai juste quelques machines très peu gourmandes :

• Un NanoPi R2S (~40€ neuf fin 2020, incluant boîtier métal, carte µSD et alim) pour la partie réseau avec un port Ethernet sur la box, l'autre vers le LAN : routeur, firewall (nftables), DHCP/DNS (dnsmasq + AdGuard Home), VPN (wireshark intégré dans systemd-networkd)
• Un point d'accès WiFi avec 4 ports ethernet (Netgear R6400, ~60€ d'occasion fin 2020), fonctions routeur désactivées
• Un PC assemblé (~260€ neuf sans les disques mi 2019) avec un petit Celeron (carte mère ASRock J3455-ITX) et 4 disques mécaniques (RAID1 BTRFS) : NAS (Samba), DLNA, monitoring (InfluxDB/Grafana), backups (serveur Borg/Restic) et NUT pour surveiller l'onduleur (connecté en USB)

Tout est totalement passif, donc aucun bruit de ventilation, et les températures restent convenables (~40°C dans le NAS, ~48°C pour le NanoPi en ce chaud mois de juillet).

Sur l'onduleur, en plus de ces trois machines là, j'ai la base du téléphone fixe et les deux box Orange (il y a une box 4G pour accompagner l'ADSL 1.2 Mbps).
La consommation total de tout ça est de 53.4W en moyenne sur un an, ce qui donne un peu moins de 80€ d'électricité par an.

Toutes mes données sont chez moi et pas sur un cloud pour plusieurs raisons, dans l'ordre :

• J'aime pas confier mes données à quelqu'un d'autre
• Je veux que ça continue de fonctionner en cas de coupure internet
• ADSL lent (et pas stable du tout) et 4G "limitée" en data

Cependant, j'ai quand même des sauvegardes distantes, réalisées via Borg (exclusivement), sur un Kimsufi.

Il y a une différence assez importante entre zram et zswap :

• zram crée un ramdisk compressé, qu'on peut ensuite utiliser comme n'importe quel autre block device
• zswap est une sorte de cache compressé dans la ram où sont envoyées les données à destination de la swap

zram est "aunotome", alors que zswap nécessite en plus un espace de swap existant (quelle que soit sa forme). Sur mes machines ARM qui fonctionnent sur une carte SD, j'utilise zram, puisque je ne mets pas d'espace de swap sur la carte SD :)

En fait, tu peux choisir :
- RAID1 "standard" : BTRFS s'assure qu'il existe deux copies de chaque bloc de données sur deux disques physiques différents (= 1.5TB utiles sur 3 disques de 1TB, 2TB utiles sur 2x1TB+2TB, par exemple).
- RAID1C3 : BTRFS s'assure qu'il existe trois copies de chaque bloc de données sur trois disques physiques différents (= 1TB utile sur 3 disques de 1TB).

J'ai déjà tenté ça aussi, et si je me rappelle bien, c'était une histoire de Xorg qui ne peut pas charger plusieurs drivers graphiques différents en même temps.
Je n'ai pas de seconde carte graphique pour tester, mais si c'est bien ça, il serait théoriquement possible d'utiliser deux cartes graphiques "identiques" (= utilisant le même driver) en même temps.

Je peux aussi confirmer que les deux puces graphiques sont bien actives en même temps, parce que, même si je ne peux pas envoyer d'image via le port HDMI de la carte mère, je peux y envoyer du son sur un écran connecté dessus, tout en ayant des images et du son envoyés sur un autre écran connecté sur la carte graphique.

certes avec une carte graphique mais c'est plutot pratique pour debugger.

Bof, je préfère la console série en mini-USB du Sheevaplug, ça évite d'avoir à sortir un écran et un clavier pour débugger :)