Qu’appelles-tu « tunnel » ? Un tunnel via VPN ? Car la solution qu’on est entrain de débattre passe justement par un tunnel (c’est le principe de « Cloudflared »).
C’etait un peu une solution que j avais créé en utilisant un sous domaine dédié aux API mais du coup je trouvais aussi que ca faisait un doublon non protégé et que donc cloudflare access/auth était facilement contournable.
J’avoue j’en ai eu marre de tourner en rond… j ai viré access/auth.
j’ai ajouté des protections cloudflare style geoip et un fil2ban sur jeedom… un gros mdp et ca devrait le faire! 
Déjà comme tu l expliquait tunnel, pas de port ouverts…
Bon courage a ceux qui se frottent a cloudflare car c’est cotton a prendre en main…
Merci pour tes conseils Dreaky!
1 « J'aime »
On parle de la même chose alors. Mais moi je ne passe pas par « application », il y a le nom de domaine principal, disons blablabla.fr, et j’ai créé un tunnel par machine, donc par exemple pour jeedom: https://jeedom.blablabla.fr et mon jeedom de dev: https://jeedomdev.blablabla.fr
Ça apporte quoi de passer par application ?
Tu peux (entre autre) rajouter une couche d’auth géré par cloudflare, qui demande à l’utilisateur de se connecter via son compte google pour du MFA (google au choix, tu peux choisir plein de provider différents), et valider via ton smartphone. Ca fait qu’avant de devoir taper sur ton domaine, ça tape d’abord sur cloudflare. C’est redoutable en terme de sécurité par rapport à tous les botnets qui tentent un accès 58 fois par jour.
Et donc ça fait poper un écran de ce type avant d’arriver à service hébergé (jeedom ou autre) :
La contre partie, ça nécessite un chouille plus de config pour autoriser les services externes (donc les serveur google pour google home par exemple), et by-passer cet écran.
Un peu de lecture
Car si vous regardez vos logs, vous seriez étonnés de la quantité de botnets qui frappent à la porte de vos appli auto-hébergées chaque jour… Personnellement pour aujourd’hui, j’ai 540 tentatives d’accès…
Ok je vais lire ça, merci