RDP & Guacamole

Et non, je ne suis hélas pas parti en vacances au Mexique déguster du guacamole arrosé de téquila ! Mais j'ai trouvé la solution que je cherchait depuis longtemps pour sécuriser les accès RDP. Comme chacun le sait il n'est vraiment pas conseillé de laisser ouvert sur internet le port RDP qui est plutôt vulnérable. Hélas pensant le confinement beaucoup de clients ont du mettre en place des solutions dans l'urgence et dans bien des cas il était impossible de verrouiller au minimum ce port sur une IP fixe....

Bien sur Microsoft a une solution (RDP Gateway), couteuse et complexe, donc pas adaptée à de petites entreprises dont les couts IT explosent déjà. Je restait donc en éveil à la recherche d'une solution quand je suis tombé sur le projet open-source Guacamole en HTML5. Et surprise, celui ci fonctionne vraiment bien ! Le principe est simple et reprends celui des autres projets, une machine va servir de proxy afin d'exposer le RDP (mais aussi SSH, Telnet et VNC).

Installation

S'il est possible d'installer Guacamole en natif comme c'est très bien expliqué ici, après avoir testé différentes options, par facilité je vais faire ça sous Docker en utilisant ce projet.

Je vais donc monter une VM Linux Ubuntu et y configurer Docker et Docker Compose. Pour cette partie je vous laisse chercher, d'autres expliquent mieux que moi.

Pour déployer Guacamole on a besoin de 3 services :

  • GUACD : Le cœur de Guacamole qui va servir à connecter les différents services (RDP, SSH, etc...)
  • PostgreSQL : Une base de donnée (qui peut être également MySQL ou encore l'utilisation d'une base externe)
  • Guacamole : Le composant FrontEnd qui va gérer les connections, les services et les utilisateurs.

Docker Compose

L'auteur de l'intégration a eu la bonne idée de nous fournir un script d'installation. On va donc l'utiliser et on se servira de Docker Compose plus tard afin d'ajuster la configuration.

sudo git clone "https://github.com/boschkundendienst/guacamole-docker-compose.git"
cd guacamole-docker-compose
./prepare.sh
sudo docker-compose up -d

Si tout se passe bien on peut se connecter sur https://ip_serveur:8443/guacamole. Le nom d'utilisateur par défaut est guacadmin avec mot de passe guacadmin. La première chose à faire est bien sur de le changer.

On pourra facilement configurer un serveur RDP et s'y connecter pour avoir les premières impressions. Je trouve que le rendu RDP en HTML5 est fluide, même en regardant des vidéos sur YouTube à une bonne résolution. Attention à ne pas perdre de vue que c'est le serveur Guacamole qui doit encaisser le trafic entrant et sortant. Selon l'usage et le nombre de clients il faudra donc le dimensionner correctement.

Je ne vais pas m'étendre sur les différentes options, l'interface et claire, la documentation également et d'autres en parlent très bien.

Sécurisation

Il n'est bien sur pas question d'exposer ce serveur directement sur internet et je vais tester deux solutions de reverse proxy, je commence par éditer le fichier docker-compose.yml afin de supprimer le proxy Nginx préinstallé histoire de ne pas empiler les proxys. J'ajuste également en 8080:8080 pour une utilisation en direct et REMOTE_IP_VALVE_ENABLED: 'true'  pour activer le proxy externe et WEBAPP_CONTEXT: 'ROOT' afin que Guacamole soit accessible en racine :

version: '2.0'
networks:
  guacnetwork_compose:
    driver: bridge

services:
  # guacd
  guacd:
    container_name: guacd_compose
    image: guacamole/guacd
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./drive:/drive:rw
    - ./record:/record:rw
  # postgres
  postgres:
    container_name: postgres_guacamole_compose
    environment:
      PGDATA: /var/lib/postgresql/data/guacamole
      POSTGRES_DB: guacamole_db
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: postgres:15.2-alpine
    networks:
      guacnetwork_compose:
    restart: always
    volumes:
    - ./init:/docker-entrypoint-initdb.d:z
    - ./data:/var/lib/postgresql/data:Z

  guacamole:
    container_name: guacamole_compose
    depends_on:
    - guacd
    - postgres
    environment:
      REMOTE_IP_VALVE_ENABLED: 'true'   # On active ici l'utilisation via un proxy externe
      WEBAPP_CONTEXT: 'ROOT'
      GUACD_HOSTNAME: guacd
      POSTGRES_DATABASE: guacamole_db
      POSTGRES_HOSTNAME: postgres
      POSTGRES_PASSWORD: 'ChooseYourOwnPasswordHere1234'
      POSTGRES_USER: guacamole_user
    image: guacamole/guacamole
    volumes:
    - ./custom/server.xml:/home/administrator/guacamole-docker-compose/server.xml
    links:
    - guacd
    networks:
      guacnetwork_compose:
    ports:
    - 8080:8080
    restart: always

Je relance docker :

administrator@guacamole:~/guacamole-docker-compose$ sudo docker-compose up -d

En local je me connecte maintenant en http://ip_serveur:8080 sans SSL car le SSL sera géré par le proxy.

Option 1 : pfsense

J'ai un pfsense installé avec HAProxy et Acme pour gérer les certificats Lets'Encrypt, je vais donc me servir de ca pour publier le service. Sur HAProxy on configure le BackEnd et le FronteEnd qui lui utilisera le certificat préalablement créé avec Acme. Dans ma configuration je partage l'IP avec plusieurs sites et ce qui est important c'est d'activer l'option forwardfor qui permettra de transférer les adresses sources à Guacamole.

Je mets ici le code de configuration qui sera utile à ceux qui n'utilisent pas HAProxy sous pfsense qui lui dispose d'une interface graphique. Comme on peut le constater le HTTP to HTTPS se fait au niveau du HAProxy et c'est lui également qui redirigera les requetés HTTTP vers HTTPS et mon serveur sera accessible sur https://guacamole.mondomaine.tld :

global
  maxconn     10000
  stats socket /tmp/haproxy.socket level admin  expose-fd listeners
  uid     80
  gid     80
  nbproc      1
  nbthread      1
  hard-stop-after   15m
  chroot        /tmp/haproxy_chroot
  daemon
  tune.ssl.default-dh-param 1024
  server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
  bind 127.0.0.1:2200 name localstats
  mode http
  stats enable
  stats admin if TRUE
  stats show-legends
  stats uri /haproxy/haproxy_stats.php?haproxystats=1
  timeout client 5000
  timeout connect 5000
  timeout server 5000

frontend Shared_WAN-merged
  bind      x.x.x.x:443 (IP WAN) name x.x.x.x:443 (IP WAN)   ssl crt-list /var/etc/haproxy/Shared_WAN.crt_list  
  mode      http
  log       global
  option    http-keep-alive
  option    forwardfor
  acl https ssl_fc
  http-request set-header   X-Forwarded-Proto http if !https
  http-request set-header   X-Forwarded-Proto https if https
  timeout client    30000
  acl     Admin var(txn.txnhost)      -m str -i admin.domain.tld
  acl     guacamole var(txn.txnhost)  -m str -i guacamole.domain.tld
  http-request set-var(txn.txnhost) hdr(host)
  use_backend Admin_ipvANY  if  Admin 
  use_backend Guacamole_8443_ipvANY  if  guacamole 

frontend http-to-https
  bind            x.x.x.x:80 (IP WAN) name x.x.x.x:80 (IP WAN)
  mode            http
  log             global
  option          http-keep-alive
  timeout client  30000
  http-request redirect code 301 location https://%[hdr(host)]%[path]  

backend Admin_ipvANY
  mode     http
  id       100
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   admin 192.168.55.44:80 id 101  

backend Guacamole_8443_ipvANY
  mode     http
  id       102
  log      global
  timeout  connect   30000
  timeout  server    30000
  retries  3
  server   guacamole 192.168.66.55:8080 id 101

Option 2 : CloudFlared

Cette option est encore plus simple pour ceux qui disposent d'un domaine chez Cloudflare. On va utiliser les possibilités offertes gratuitement par Cloudflared et ajouter une couche de sécurité supplémentaire.

On commence par créer un tunnel CloudFlared avec une instance Docker supplémentaire (le code est fournit par le site de configuration Zero Trust de Cloudflare)

docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token eyJhIjoiZjk0YjdkZTBiMzFmYWNkNjZlshhsgfhsfghsgfhgfhssgfhsfgzRiMC00MmNlLWJjMghsfghsghsgfhsgfhsgfhsgmpaR00tyyretu(-yenebybvewWXpGaUxUazVNell0TnpRek56WXhNMlkxWXpFeiJ9

Ensuite une fois que le tunnel est monté

On va publier et pointant sur l'ip privée et le port de notre serveur, cela va automatiquement créer l'entrée DNS dans CloudFlare et gérer la problématique du certificat. Ll sera accessible en SSL. :

Ensuite on va ajouter une couche de sécurité supplémentaire en créant une application de type SelfHosted à laquelle on affecte une policie qui impose un code supplémentaire lors d'une connexion. Ce code sera envoyé sur le mail de l'utilisateur sur une adresse individuelle ou un domaine spécifique. Ce n'est pas tout à fait du MFA, mais on considère que si l'utilisateur reçoit bien le code sur son mail professionnel, il s'agit bien de lui et on peut lui permettre de saisir son login / password pour accéder au service :

C'est la méthode la plus simple et de nombreuses option sont exploitables, de même qu'il est possible d'utiliser de nombreux providers externes d'authentification :

Lorsqu'il souhaite se connecter, l'utilisateur tombe sur un portail que l'on peu personnaliser aux couleurs de l'entreprise.

Voilà, et surtout maintenant on retrouve bien les IP publiques dans le log de Guacamole :

Il n'y a plus qu'a ajuster les différentes options de Guacamole et pour ça la documentation est très bien faite. Et bien sur si on se sert de Guacamole pour exposer des serveurs RDP accessibles sur l'internet on prendra soin de restreindre leur usage à l'IP publique du serveur Guacamole, ou mieux de faire transiter ce flux par un tunnel (Wireguard, Tailscale ou Zerotier par exemple que l'on peu facilement installer sur les deux serveurs).

Tailscale Access Controls

J'ai souvent parlé de Zerotier que j'utilise au quotidien, mais qui dans sa version gratuite comporte quelques limitations en terme de contrôle d'accès dans un environnement mixant du site-to-site et des clients isolés. J'ai donc voulut voir ce que proposait Tailscale, qui est un VPN managé relativement similaire reposant sur Wireguard. Tous deux offrent des fonctionnalités gratuites et payantes. Si payer ne doit pas être un problème dans un environnement de production, c'est un peu différent en mode home lab.... d'autant plus que certaines fonctionnalités de la version gratuite ne se retrouvent que dans la version Premium à $18 /mois/utilisateur.

La version gratuite des Tailscale est plutôt généreuse, elle propose 100 nodes et 3 utilisateurs (à condition de disposer d'un "custom domain" (je vais utiliser des comptes Microsoft 365, mais plusieurs autres possibilités sont disponibles : SSO Identity Providers). On peut donc disposer de 3 comptes sur un même domaine. Je parle de comptes car nativement (et normalement) le contrôle d'accès se fait sur l'utilisateur. Manque de chance j'ai besoin de gérer 4 utilisateurs, et je ne suis pas prêt à payer 4 x $18, ce qui me ferait plus de $ 800 par an !

J'ai donc cherché à contourner et je vais finalement gérer mes autorisations à partir des machines Tailscale que j'ai approuvées (mode NFS pour ceux qui se souviennent). Dans cet usage je ne cherche pas faire communiquer les clients Tailscale entre eux mais à leur permettre d'accéder à des ressources situées sur différents subnets sur lesquels je souhaite restreindre les possibilités.

Pour la suite on considère que le réseaux Tailscale est configuré avec les nodes qui servent à joindre les subnets.

Je vais créer deux utilisateurs :

[email protected]
[email protected]

Le premier compte qui sera également le mien va également me permettre de configurer et approuver les machines clientes.

Le second servira à connecter mes utilisateurs et je pourrais approuver leurs machines. Ce compte étant protégé en MFA, il nécessitera une validation de ma part. Une fois la machine connectée, je désactive l'expiration de la clé et on passe au contrôle s'accès :

{
  "acls": [
    {"action": "accept", "src": ["[email protected]"], "dst": ["*:*"]}, // Ici l'admin dispose de tous les droits
    
    // Autorisation par machines
    {
      "action": "accept",
      "src": ["azura", "lydia"],      // Ici deux clients Tailscale
      "dst": [
        "pipa:25,53",                 // On autorise le host qui supporte le DNS si on veut utiliser les noms courts...
        "mixa:80,443,445,3389",
        "nona:80,443,445,1443,3389",  // Ports autorisés

        "lab-1:*",

        "192.168.2.12:80,443,9100,5001,3389", // Par IP + ports
        "192.168.6.0/24:*",                   // Par subnet
      ],
    },
  ],
  "hosts": {
    "azura": "100.1.2.3",        // Client Tailscale
    "lydia": "100.5.2.3",        // Client Tailscale

    "mixa":  "192.168.1.4",      // Host on subnet
    "nona":  "192.168.2.8",      // Host on subnet
    "pipa":  "192.168.2.1",      // Host on subnet

    "lab-1": "192.168.6.0/24", // subnet
  },

}

Dans l'ordre :

  1. J'autorise l'admin à tout voir.
  2. Ensuite j'autorise les machines azura et lydia à accéder uniquement aux hosts que j'aurais défini avec une restriction sur certains ports. C'est possible en définissant les hosts plus loin ou en se servant directement des adresses IP. L'ICMP (ping) est ouvert automatiquement vers les destinations autorisées.
  3. Je défini les clients et serveurs.

Voilà. Je n'ai pas creusé toutes les possibilité offertes par le contrôle d'accès proposé par Tailscale, la liste est longue et le documentation plutôt bien faire. Idées bienvenues !

VMWare ESXi sur Nuc 9 & SSD firmware...

Comme je vous en avait parlé ici, j'ai remplacé mon serveur ESXi HP ML350p par un Nuc 9. Depuis plus de 6 mois ça fonctionne très bien.

Dans ce Nuc j'ai installé deux SSD NVMe Samsung 980 Pro. Les performance sont au top, mais voilà que plusieurs utilisateurs se plaignent que leurs SSD s'usent prématurément et finissent par passer en R/O. C'est d'autant plus fâcheux que sous ESX on ne dispose de rien pour surveiller les disques sur un NUC, celui ci ne remontant pas de données IPML comme le ferait un vrai serveur. Après avoir fait un peu la sourde oreille, Samsung a fini par sortir la mise à jour idoine.

Sous Windows il est très facile de mettre à jour (ou de migrer) un SSD, il suffit de lancer Samsung Magician et le tour est joué ! Sous VMWare ESXi rien de tout ça et il va falloir le faire à la mano. Heureusement pour cela Samsung fournit également les firmawares sous la forme d'une ISO, il suffit, en principe, de le griller sur une clé USB et de booter avec et de faire la mise à jour. Mais ça c'est la théorie. Dans la pratique j'ai appris à mes dépends que cette clé basée sur un vieux Linux était incapable de booter sur du matériel moderne, et quand elle boote certains disent même qu'elle ne reconnait que les claviers PS2... Allons donc !

Après quelques recherches j'ai découvert qu'il existait un contournement possible mis en pratique par la communauté Linux, mais nullement supportée par Samsung qui doit considérer que ses SSD sont destinés uniquement à l'environnement Windows, tout comme VMWare qui a sa liste de hardware supporté...

L'astuce consiste à booter sous Linux, un Live CD Ubuntu. Facile, non pas si simple car ce live CD ne voulait lui non plus pas booter. Le bios de ce Nuc n'étant pas de toute fraicheur j'en profite pour le mettre à jour sans plus de succès.

J'ai fini par trouver que pour booter sous Ubuntu il fallait désactiver TPM et SGX. Ca ne s'invente pas mais j'ai fini par pouvoir booter mon Ubuntu Live.

Une fois sur le desktop de mon Ubuntu je copie l'ISO de mise à jour (Samsung_SSD_980_PRO_5B2QGXA7.iso) que j'ai au préalable préparée sur une autre clé USB vers le répertoire Home et je monte le volume. Ensuite toujours depuis l'interface graphique j'extrait le fichier initrd un répertoire (/home/samsung par exemple). Ensuite je vais jusqu'à /home/samsung/initrd/root/fumagician et je peux lancer la mise à jour de mes SSD :

sudo ./fumagicien

Je fais la mise à jour de mes deux SSD et je relance le Nuc. Attention, le bon numéro de version n'apparaitra qu'âpres le prochain redémarrage. Donc même si c'est un peu fastidieux, je vous conseille de relancer le Live CD pour vérifier. De même si vous avez d'autres machines à mettre à jour, vous pouvez sauvegarder fumagician sur une clé pour éviter l'étape de l'extraction. 

Il existe une autre méthode en CLI pour les barbus, elle demandera toutefois de connecter le Live CE au réseau si on veut éviter l'étape de la clé USB, mais in fine ça revient au même :

wget https://semiconductor.samsung.com/resources/software-resources/Samsung_SSD_980_PRO_5B2QGXA7.iso
apt-get -y install gzip unzip wget cpio
mkdir /mnt/iso
sudo mount -o loop ./Samsung_SSD_980_PRO_5B2QGXA7.iso /mnt/iso/
mkdir /tmp/fwupdate
cd /tmp/fwupdate
gzip -dc /mnt/iso/initrd | cpio -idv --no-absolute-filenames
cd root/fumagician/
sudo ./fumagician

Voilà comment occuper (perdre) un après-midi d'hiver !

Attention toutefois, si vous avez créé un volume RAID, ce qui est discutable avec des SSD, il semblerait que vous ne puissiez les voir sans repasser le bios en AHCI.

Sources

 

Microsoft mon amour !

Et non, ce n'est pas une déclaration ! J'ai longtemps été in love avec Microsoft, mais comme on le sait, les histoires d'amour finissent souvent mal ! Blague à part, en imposant d'abord Exchange dans les entreprises, Microsoft telle une pieuvre avait bien préparé le terrain afin que celles-ci migrent vers Exchange Online, une des briques de la méga suite 365. Le résultat est qu'aujourd'hui la domination est quasi totale, domination que les autres acteurs ont bien du mal à concurrencer. Bien ou pas, ce n'est pas l'objet de cet article, par contre cette domination devrait imposer un devoir d'exemplarité, et force est de constater que ce n'est pas toujours le cas, loin s'en faut !

En devenant l'acteur majeur de la messagerie d'entreprise, Microsoft est également devenu un acteur majeur du spam. Face à cette déferlante certains acteurs moins conséquents n'ont d'autre choix que d'imposer régulièrement le blocage des adresses IP de Microsoft, une pratique certes discutable, mais également adoptée par Microsoft lui même pour son service grand public Hotmail (comme on peut le lire 1 | 2 | 3 )

Dans la pratique on se retrouve avec une messagerie professionnelle incapable d'envoyer des messages vers certaines destinations, @free.fr et @orange.fr par exemple, mais pas que. La situation peut se débloquer toute seule et alors les messages prennent du retard, ou sont simplement renvoyés à l'expéditeur via un NDR.

L'un de nos collègue, Marc, a eu l'opportunité d’échanger avec le responsable de la messagerie chez Free et il lui a posé la question :

Pensez vous qu’il puisse être envisageable d’exploiter d’autres mécanismes permettant un filtrage avec une granularité plus fine (genre trio DKIM, SPF, DMARC) ?

    • Non, pas à ce jour et probablement pas dans un futur proche.
    • Le premier problème est que la situation dans laquelle vous êtes ne concerne qu'Office365 et aucun autre hébergeur de messagerie. Il y a bien des problèmes avec Gmail mais les solutions techniques mises en place chez eux n'ont rien à voir avec celles d'Office365 et les dommages collatéraux en sont drastiquement réduits.
    • Le second problème est que si nous devions basculer sur une réputation par domaine en nous basant sur les signatures DKIM, il nous faudrait également prendre en compte les sceaux ARC (signature de l'intermédiaire technique) et qu'ici, il y a un sceau ARC sur microsoft.com sur les mails sortant d'Office365 et qu'il y a un risque conséquent pour que ce soit toute la plateforme Office365 qui se retrouve bloquée.
    • Le troisième problème est que nous avons pu constater ces dernières années des campagnes de spams expédiées au travers de comptes compromis. Sur certaines journées en décembre dernier, c'est plus de 1500 domaines qui participaient ainsi aux envois rien que pour Office365. Il est délicat de mettre en place une whiteliste concernant un domaine ou un compte car cela revient à retirer toutes nos protections alors que nous gérons pas ce domaine ou ce compte.

Dans ces conditions et puisque Microsoft ne réagit pas plus, il faut trouver un contournement qui va nous permettre de rerouter les messages destinés aux domaines qui pratiquent de tels blocages. D’aucuns diront que continuer à utiliser en 2022 un compte de messagerie chez un FAI n’est pas une bonne idée, mais peu importe, dans le cadre d’une relation commerciale on ne commence pas par expliquer la vie au client, mais à entretenir la relation avec lui et ainsi lui apporter des solution viable. On est tous d'accord, on ne devrait pas avoir à apporter une telle solution !

Contournement

Sur Microsoft 365, Exchange Online plus précisément, nous allons utiliser une règle et un connecteur pour dérouter les messages destinés au domaine free.fr  et orange.fr vers un serveur SMTP externe qui va servir de relais. S’il existe bien des services de relai SMTP sur Internet, ces services nécessitent soit une authentification, soit une restriction sur une adresse IP. Problème, il n’est pas possible de s’authentifier sur un connecteur sortant, et Microsoft utilise une multitude d’adresses IP sur ses serveurs SMTP.

*.protection.outlook.com : 40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14, 52.238.78.88/32, 104.47.0.0/17

Il va donc nous falloir monter un serveur SMTP externe sur lequel on va autoriser le relai depuis ces blocks d’adresses IP. Il existe toutefois un petit risque que d’autres administrateurs trouvent la faille et se servent de notre serveur. Ce risque est faible, et au pire on changera notre adresse IP.

Le relai

Ou relais, une fois de plus les anglais font plus simple avec relay, smtp-relay. Bref, pour monter un tel serveur il existe certainement plusieurs produits possibles, pour peu que ces logiciels soient capable de gérer de multiples plages d’adresses IP sources à relayer. J’ai utilisé HMailServer sous Windows car je le connais bien, mais on doit pouvoir faire ça sous Linux à moindre frais. Quant à la restriction au niveau des IP sources, ça peut aussi se faire au niveau du firewall.

Dans HMailServer (IP Ranges) on va déclarer nos adresses IP autorisés sans authentification, celle des serveur Microsoft 365 :

On répète ça pour chaque plage d’IP et ensuite de la même façon on va déclarer nos relais autorisés, les mêmes IP :

C'est un peu fastidieux et ce serait plus simple de déclarer 107.47.0.0/17, mais ici c’est ainsi.

Ensuite on s’assurera que notre serveur est correctement installé (il n’accepte rien d’autre) et est correctement déclaré et configuré (SPF, reverse IP, etc...) pour les domaines pour lesquels il devra assurer le transit. On fait un Telnet sur mx1.free.fr afin de s’assurer que l’on peut bien les joindre et  que notre IP publique n'est pas elle aussi blacklistée.

A ce stade on se connecte à l’administration Exchange de Microsoft 365 dans laquelle on va faire en sorte que tous les mails à destination de Free et Orange devront transiter via l’IP de notre serveur relai.

Exchange Online

Pour ce faire on va commencer par créer un connecteur qui s'appliquera aux messages sortant d'Exchange Online vers ce qui s'appelle ici Organisation Partenaire :

Le choix suivant est important :

  1. Soit on décide que ce connecteur s'applique à tous les messages à destination de Free et Orange, auquel cas on configure simplement ces domaines. C'est la solution la plus simple pour un tenant qui ne gère qu'un seul domaine.
  2. Soit on décide que ce connecteur ne s'applique qu'au messages qui ont été redirigés par une règle. On utilisera cette option dans le cas ou on souhaite rediriger uniquement certains mails, expéditeurs ou domaines sources, qui seront le fruit d'une règle à créer.

Ensuite se pose la question de la validation du connecteur ou l'on utilisera une adresse @free.fr par exemple. Dans la pratique validé ou pas le connecteur fonctionne tout de même....

Si l'on a fait le choix 2 il va nous falloir créer une règle pour que cela fonctionne. Dans cette règle on va demander à ce que :

  • le destinataire soit sur le domaine free.fr
  • le domaine de l'expéditeur
  • Et enfin que ce trafic transite via le connecteur précédemment créé.

Cela va nous permettre de ne dérouter vers notre MTA premise uniquement les domaines sources qui y seront configurés. Ce cas est spécifique à des tenant "partagés" ou plusieurs domaines coexistent, mais cela peut également permettre d'utiliser plusieurs serveurs relais en fonction des domaines sources.

Il est bien sur possible de faire ceci en PowerShell, vous trouverez les détails dans cet excellent article.

Synology mon amour....

J'utilise des NAS Synology à titre professionnel depuis plus de 10 ans avec une plutôt bonne expérience. J'en ai par exemple de gros qui fonctionnent encore très bien mais par exemple un RS3411xs de 2011 mérite d'être changé préventivement...

Je commande donc un RS3621RPxs et 6 disques Western Digital Ultrastar HC530, un modèle que j'avais utilisé avec succès il y a deux mois dans un RS820RP+. Disque de classe entreprise. Et là c'est le flop, dans ce dernier NAS il apparaissent comme disques non vérifiés et impossible de les monter en SHR, alors que ce disque est compatible avec le RS820RP+ !

Me voici donc partit à la recherche d'informations, le constat est des plus simples et probablement surtout mercantile. Synology vend maintenant ses propres disques en apposant leur étiquette sur des disques Toshiba, et les disques concurrents encore présent dans les listes de compatibilité sont de plus en plus rares. Rien de bien neuf sous le soleil, HPE, Dell et d'autres ont les mêmes pratiques. Saut que Synology nous avait d'une part habitué à pouvoir utiliser n'importe quel disque, le credo des fabricants de NAS, et surtout que les disques estampillés Synology sont peu disponibles et coutent souvent jusqu'à 30/40 % plus cher. Scandaleux, et les groupes d'utilisateurs ne se privent pas pour le dire et orienter les clients vers d'autres solutions.

Bref, j'ai donc 6 disque de 16 TO sur les bras. On va voir qu'il existe des contournements, mais pour des questions légales et de responsabilité vis à vis de mon client, je ne peux pas me permettre d'utiliser ces disque en production sensible. Donc Synology à gagné, et je repasse une commande de 6 disques Synology que je vais monter en stockage de VM. Quant aux 6 premiers je vais les utiliser dans un second groupe dédié à des sauvegardes secondaires en utilisant un contournement.

Synology

Dans la terminologie de Synology, il existe 3 classes de disques :

  • Compatible : Les disques compatibles ont été testés par Synology et sont certifiés pour fonctionner sans limitation.
  • Incompatible : les disques incompatibles sont « mis sur liste noire » par Synology et ne peuvent pas être utilisés (les disques SMR sont inclus dans ce lot). Rien que du normal.
  • Non vérifié : un disque qui n'a pas été testé par Synology est défini comme un lecteur non vérifié. Ca ne veut pas dire qu'il n'est pas 100% compatible, et ici c'est bien plus contestable.

Les disques non vérifiés sont utilisables dans un état non pris en charge avec les contraintes suivantes :

  • L'état d'un disque non vérifié peut apparaître comme non vérifié dans le gestionnaire de stockage de DSM.
  • Des avertissements s'afficheront lors de la sélection de lecteurs non vérifiés pour créer un pool de stockage.
  • Il est parfois impossible de créer des volumes de type SHR avec des disques non vérifiés.
  • Les pools de stockage contenant des lecteurs non vérifiés peuvent afficher un état de danger pouvant faire peur.
  • DSM peut envoyer des notifications d'avertissement lorsque des lecteurs non vérifiés sont en cours d'utilisation.
  • Les informations sur le lecteur telles que l'état de l'allocation, le nombre de secteurs défectueux, la température, le numéro de série, 4K natif peuvent ne pas être affichées.
  • La prise en charge de Synology sera limitée si le problème de prise en charge peut être lié au lecteur non vérifié (la décision de refuser la prise en charge reste à la discrétion de Synology)
  • L'utilisation de disques non vérifiés n'a aucun effet sur la garantie matérielle de Synology

Bien sur cette liste n'est pas exhaustive et malheureusement Synology est resté vague sur le fonctionnement de leur classification de disques et de SSD. Par exemple…

  • Les disques approuvés comme compatibles pour un modèle de NAS peuvent être non vérifiés pour un autre modèle.
  • Les disques approuvés comme compatibles peuvent voir leur classification changée en incompatible ou non vérifié sans préavis par Synology.
  • La compatibilité du lecteur est liée à la version du micrologiciel du lecteur.
  • Le test des disques nouvellement sortis est souvent retardé de plusieurs mois.
  • Le résultat de ces classifications de disques est que l'achat de disques compatibles est souvent limité à des disques rares dans le commerce, avec des micrologiciels obsolètes, qui sont soit indisponibles à la vente, soit en nombre insuffisant, auprès de fournisseurs non éprouvés, à des coûts non compétitifs.

De manière réaliste, un disque SATA de classe NAS/Enterprise utilisant la technologie CMR devrait convenir. Bien sur tout cela vaut pour les SSD...

Contournements

Dans tous les cas, et quelque soient les disques utilisés, on commence toujours par monter un volume et stresser les disques avant une mise en production, en faisant par exemple de gros transferts de données pendant quelques jours... Et si ça se passe mal on n'hésite pas à renvoyer les disques.

Si ça se passe bien on peut envisager deux contournements, l'un va faire croire que le disque a été vérifié, et l'autre que l'on ne s'occupe pas de vérifications... Et rien ne dit que de futures mises à jour ne rendront pas ce contournement obsolète.

Attention : S'agissant de modifications de fichiers système, vous savez et comprenez ce que vous faites, je décline toute forme de responsabilité, tout comme les personnes qui ont trouvé ces hacks et les ont divulgués sur les forums cités en sources (non, ce n'es pas moi qui ait trouvé !).

Cette mise en garde étant posée, j'ai trouvé deux possibilités :

Première option, ajout du disque dans la liste de compatibilité

On active SSH, on se connecte au NAS et on fait :

sudo-i

Qui va vous redemander le mot de passe pour cette élévation. Enduite on va dans le répertoire idoine :

cd /var/lib/disk-compatibility

Et on repère les fichiers *_host.db et *_host.db.new qu'il faudra éditer, par exemple dans mon cas rs3621rpxs_host_v7.db et rs3621rpxs_host_v7.db.new. Attention, tout ça peut évoluer avec le temps et les révisions. Avant d'éditer, je vous conseille de faire une copie de sauvegarde de l'original et de chercher les information de vos disques avec :

sudo smartctl -i /dev/sdc

Qui devrait retourner quelque chose du genre !

Model Family:     Ultrastar
Device Model:     WDC  WUH721816ALE6L4
Serial Number:    3WJAK3BJ
LU WWN Device Id: 5 000cca 284e0faf1
Firmware Version: PCGNW232
User Capacity:    16,000,900,661,248 bytes [16.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    7200 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   Unknown(0x0ffc) (unknown minor revision code: 0x009c)
SATA Version is:  SATA >3.2 (0x1ff), 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Tue Oct 18 19:04:29 2022 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

Ensuite on édite avec VI et ça devrait donner quelque chose de ce genre :

{"model":"WUH721816ALE6L4","firmware":"PCGNW232","rec_intvl”:[1]},

Et si on est pas sur, le mieux est d'aller lire, si on en dispose, ces informations dans un fichier pour un autre NAS ou le disque est indiqué compatible (notamment la dernière information en fin de ligne).

Seconde option, ne pas vérifier la compatibilité

Attention : Il y a de grandes chances que cette manipulation saute lors des mises à jour. Il faut donc la refaire à chaque fois, et toujours en partant du fichier original qui contient d'autres informations qui peuvent évoluer. (Je viens d'en faire les frais lors de l'application de 7.1.1-42962 Update 4, mais c'est probablement le cas de chaque mise à jour).

J'aurais tendance à préférer cette option bien plus simple. Mais ça sous entend que nos disque soient testés et non incompatibles. On passe toujours par SSH et on va éditer ce fichier :

/etc.defaults/synoinfo.conf

Et dans ce fichier on va passer cette ligne de yes à no.

support_disk_compatibility="no"

On peut bien sur éditer le fichier directement avec VI, mais pour ceux qui ne seraient pas à l'aise avec ce dinosaure, je conseille de commencer par faire une copie de sauvegarde de ce fichier dans un partage, de sauvegarder cette copie ailleurs et ensuite de l'éditer avec son éditeur préféré, puis d'aller remplacer le fichier original :

sudo cp /etc.defaults/synoinfo.conf /volume2/Backups/

On édite, et :

sudo cp /volume2/Backups/synoinfo.conf /etc.defaults

On sauvegarde et on redémarre le NAS et nos disques ne devrait plus s'afficher en rouge. Cependant ça ne joue pas sur les unités d'extension.

Conclusion

Synology nous enfume mais ils font de bons produits et je n'ai pas envie de vous dire qu'il va falloir changer de crèmerie. D'autant plus que d'autres fabricants seront surement tentés de faire de même. Pour autant je me poserait la question lors de mes prochains investissement ou conseils.

Dans l'absolu que ces avertissements soient présents, pour de louables raisons, est une bonne chose. Il serait par contre raisonnable que l'utilisateur informé puisse les supprimer, notamment quand un disque est largement reconnue par la communauté. Mais il y a également les mauvaises raisons, comme pour les extensions mémoire ou une barrette Crucial à 100 € fonctionnera parfaitement là ou Synology nous en demande près de 400 ! On pourrait également parler de la collecte de données, pas pire que d'autres...

Une alternative consistera à intégrer du logiciel Open Source (FreeNAS, TrueNAS, etc.) dans des serveurs recyclés disposant d'un bon support disque (HPE par exemple) que l'on trouve à des tarifs intéressant sur le marché du reconditionné. Ca fait du NAS dédié stockage pas cher et fiable. Je précise stockage, car contrairement à ce que veulent nous faire croire les fabricants, il faut, à mon sens, oublier l'idée d'installer tout et n'importe quoi sur un NAS, mais c'est là un autre débat....

Sources

 

Home Assistant & Wake on Lan

L'heure est aux économies d'énergies et il parait qu'il faut éteindre "la" Wi-Fi ! Ce n'est peut être pas ce qui consomme le plus et notre domotique fait certainement mieux.... Par contre nombre d'entre nous ont des PC énergivores qui mériteraient de passer en veille. Sauf que dans la pratique on laisse souvent ce PC allumé en se disant que l'on pourra en avoir besoin depuis l'extérieur... Ce que j'ai longtemps fait !

Un PC moderne avec un SSD sait sortir de veille en quelques secondes. Alors pourquoi ne pas ressortit une vieille fonctionnalité très peu utilisée, le Wake on Lan.

Sous Linux, Windows, voire même les mobiles il existe des application GUI ou CLI. Il faut tout de même savoir que Wake on Lan n'a pas été conçu à l'époque pour fonctionner à distance, et même s'il existe des possibilités ça reste compliqué. Alors pourquoi ne pas simplement utiliser Home Assistant qui lui sera toujours disponible, voire même simplement ajouter ça à un ESP existant, sous ESP Home par exemple..

La première chose pour vos tests sera de vérifier en local que le Wake on Lan fonctionne (il y a pas mal d'utilitaires et d'explications sur ce site).

Avec Home Assistant

On commence par ajouter l'intégration au fichier de configuration et on redémarre :

wake_on_lan:

Ensuite on peur créer un switch: , mais aujourd'hui on préfèrera un button: dans Lovelace qui actionnera le service correspondant :

  - action_name: 'Sleep/UnSleep'
    double_tap_action:
      action: call-service
      service: button.press
      target:
        entity_id: button.lia_monitors_off
      action: call-service
      confirmation:
        text: Etes vous sur ?
    tap_action:
      action: call-service
      service: wake_on_lan.send_magic_packet
      data:
        mac: 00-0C-29-FB-77-97
    icon: mdi:microsoft-windows
    name: 'Windows 10 PC'
    type: button

Vous remarquerez que j'ai configuré ça sur le tap_action:, le double_tap_action: étant lui configuré pour la commande de mise en veille via Home Assistant Agent.

Avec ESP Home

J'ai un client full cloud qui dispose d'une douzaine de PC, mais pas de serveur et encore moins de Home Assistant. La première solution était de laisser un PC allumé et y installer de quoi faire du Wake on Lan en remote. Il y a également des possibilités via TeamViewer et hélas pas de base dans l'UDM Pro d'Ubiquiti. On verra ce l'on utilisera mais j'ai également pensé faire ça via un simple ESP qui lui pourrait resté allumé...

Dans ESP Home on va éditer la config et simplement ajouter (attention, ici les séparateurs ne sont pas des "-" mais ":") :

web_server:    

button:
- platform: wake_on_lan
  name: "VM Annia"
  target_mac_address: 00:0C:29:FB:77:97

A partir de là il est possible de presser notre button: qui remonte dans Home Assistant, sur la page web de l'Esp, mais également via la commande curl (la doc est ici) :

curl -X POST http://192.168.210.153/button/vm_annia/press

Et comme on ne va pas demander à l'utilisateur final de faire un "curl" on va lui emballer tout ça dans une page web accessible que l'on sécurisera afin que lui seul puisse y accéder, en partant de cette base :

<HTML>
<center>

	<form name="myform" action="http://192.168.210.153/button/vm_annia/press" method="post">
  	<button>PC Annia ON</button>
	</form>

</center>
</HTML>

Variante avec un WebHook

L'ESP remonte sur Home Assistant via ESPHome. De fait on peu presser un bouton pour réveiller le PC distant, voire même intégrer ce bouton sur un autre Home Assistant en remote. Mais il est également possible de créer un WebHook et de déclencher avec un raccourcis depuis le PC de l'utilisateur distant :

- alias: Réveil PC Carole (WebHook)
  description: ""
  trigger:
    - platform: webhook
      webhook_id: "secret-id"
  condition: []
  action:
    - service: button.press
      data: {}
      target:
        entity_id: button.reveil_pc_carole
  mode: single

Et le raccourcis à créer sur le PC de l'utilisateur qui doit réveiller son PC de bureau...

curl -X POST https://ha-online.suptel.org/api/webhook/<secret-id>

Infos

  • Attention, Microsoft a introduit un concept de veille moderne qui souvent demandera à être désactivé. Des infos ici et .
  • Il n'est pas possible de réveiller un PC connecté en Wi-Fi ou en Ethernet via USB.
  • A noter que la Freebox dispose d'une option permettant de laisser passer du Wake on Lan. Ce n'est pas le cas pour tous les routeurs et il faut parfois ruser avec le port 9.

Sources

 

Windows et le yoyo des écrans....

Sous Windows lorsqu'on utilise plusieurs écrans se pose un problème majeur : si un des écrans passe en veille, déconnecté ou non alimenté, toutes les fenêtres ouvertes passent sur l'écran qui reste disponible. Dans l'absolu c'est logique sur un laptop sur lequel on connecte occasionnellement un écran externe, par contre sur un PC fixe que l'on utilise en permanence avec trois écrans il est extrêmement désagréable de devoir réorganiser ses fenêtres tous les matins... (sujet déjà évoqué ici).

La faute à qui, à quoi ?

Le problème se situe au niveau de la gestion de l'EDID (ici pour les détails).  Il s'agit d'une implémentation dans les écrans qui va transmettre à Windows pas mal d'informations, dont :

  • La résolution d’écran,
  • La profondeur de couleur prise en charge,
  • La résolution et fréquence d’images prises en charge,
  • Le rapport hauteur / largeur
  • Le format audio pris en charge, par exemple, par exemple sur un téléviseur ne prend en charge que les formats 2.0 ou 5.1,

Selon l’année de production du téléviseur ou du moniteur, la version prise en charge d’EDID peut être 1.0, 1.4, 2.0, 3.0 ou plus. Ces informations ne sont bien sur pas modifiables par l'utilisateur mais en dur dans l'écran. A noter également que certains moniteurs permettent de désactiver une partie des informations transmises via le port HDMI ou DP. On peut alors faire un réglage manuel et Windows ne verra pas l'écran disparaitre. Ca résout le problème.

Mais hélas ce n'est pas le cas de mes écrans Samsung.

Il faut savoir que sous Windows il n'y a absolument aucune solutions native ou via un utilitaire pour désactiver l'auto détection des écrans. Ca existait jadis sous Windows 7, sous la forme d'une clé de registre, mais depuis que Windows est devenu avant tout un outil de collecte de données c'est terminé, le marketing a probablement décidé d'éliminer tout ce qui pourrait générer du support... Et pourtant la demande est bien présente !

Contournement

J'ai exploré le net dans tous les sens et les seules solutions disponibles sont matérielles. Il s'agit de dongle HDMI qui se branchent sur le port HDMI ou DP (ou via un adaptateur USB-S) entre le PC et les écrans. Il s'agit d'un émulateur EDID qui va faire croire à Windows (ça doit être identique sous MacOS) que l'écran est présent alors même qu'il est en veille, off ou débranché.