Reprise du message précédent :
C’est noté, thanks

J'ai une petite question "routage" @home :
j'ai enfin fermé l'accès depuis l'extérieur aux ports 80 et 443 de mon serveur @home qui héberge des sites en cours de développement, de la domotique, mon nextcloud...
J'ai conservé juste un accès VPN via wireguard, qui tourne sur mon routeur opnsense (virtualisé, sous proxmox, sur la même machine que le serveur web).
Par contre je rencontre un problème un peu étrange :  
j'utilise de la résolution de noms pour accéder à certains services en https, ça permet d'éviter que les navigateurs ne couinent quand on utilise l'ip à la place parce que le certificat ne correspond pas au domaine.
Donc typiquement j'ai home.mondomaine.com et nextcloud.mondomaine.com qui reroutent vers mon ip publique + en local j'ai mon serveur dns (pihole) qui reroute ces noms vers les ip locales (192.168.1.7 par exemple).
Avant de bloquer l'accès http/s depuis l'extérieur, ça fonctionnait nickel en utilisant l'ip publique.
Et quand j'étais chez moi ça utilisait l'ip interne, le tout sans jamais couiner en terme de certificat https.
 
Chose étrange, depuis que j'ai fermé l'accès extérieur, quand je suis hors de chez moi, que j'active le VPN, j'accède bien à mes ip... mais la résolution de nom déconne :
A priori le DNS utilisé n'est pas celui de chez moi mais celui du FAI (smartphone Android)... donc home.mondomaine.com renvoie vers mon ip publique et c'est bloqué.
Dans le profil wireguard sur le smartphone on peut spécifier un DNS, j'ai forcé celui de chez moi (192.168.1.254, ip de mon pihole) mais ça ne fonctionne pas.
L'ip du smartphone que j'ai via wireguard est une ip en 172.16.1.x donc je ne sais pas si c'est une histoire de ne pas être sur le même sous-réseau, ça dépasse un peu mes compétences. Je ne vois rien dans wireguard (ni côté serveur ni client) pour améliorer ça.
C'est quoi l'astuce ?

comment ton serveur DNS perso sait joindre le réseau "clients VPN wireguard", d'un point de vue routage ?

 
... je ne sais pas.  
- dans la config wireguard (côté serveur) il n'y a rien de spécial, ça a fonctionné direct : une fois connecté depuis l'extérieur via wireguard, je pinge et accède en http(s) librement à toutes les ip en 19.168.1.x Il y a juste une règle pour autoriser les clients wireguard à ressortir vers le net. Le tuto que j'avais suivi : https://www.youtube.com/watch?v=gNyIACWc60w
- j'ai tenté aussi l'approche inverse, à savoir ouvrir le http/s aux clients wireguard (c'est un alias existant dans la config opnsense) pour que le smartphone puisse passer par l'ip publique, mais ça n'a rien changé.
 
J'ai du mal à comprendre pourquoi je peux pinguer le serveur pihole, je peux même manager son interface sur son ip mais qu'à priori l'utiliser pour la résolution dns ne fonctionne pas il n'y a pas de règle spécifique pour n'autoriser que le icmp/http/... entre wg et lan par exemple.

niveau config du serveur DNS y'a pas une ACL autorisant à ne servir que certains clients/IP (histoire qu'il ne soit pas résolveur public par défaut) ?

C'est ça !!!
J'ai été voir dans la config de pihole et dans settings/dns il y a une option "interface settings" pour choisir sur quelle interface pihole répond, ça me semblait sans rapport vu que globalement ça passe par la même interface réseau (en gros le "eth0" du conteneur LXC sur lequel tourne pihole), mais en fait c'est plus subtil que ça
 
Le réglage par défaut c'est "Allow only local requests" et ça précise surtout "Allows only queries from devices that are at most one hop away (local devices)".
Donc j'imagine que le passage par wireguard rajoute un second "saut" dans l'histoire.
J'ai activé le niveau suivant "Respond only on interface eth0" et hop ça marche.
 
Merci beaucoup pour avoir pointé la bonne direction
 
A priori pas de risque particulier dans la mesure où le serveur en question n'est jamais exposé vers l'extérieur (pas de NAT vers lui).
 
D'ailleurs j'aimerai bien un jour héberger un pihole soit sur un serveur chez un hébergeur, soit chez moi mais avec un accès depuis l'extérieur, mais c'est compliqué de pouvoir y avoir un accès depuis un smartphone (ip qui change en parmanence) sans l'ouvrir à tous les vents + sans devoir avoir un VPN activé en permanence (batterie, débit). C'est quoi l'approche intelligente du problème ?

pour du résolveur DNS, si ton client n'est ni sur le LAN ni VPN ni en IP fixe je pense que c'est mort.
 
Après ton VPN tu dois pouvoir le configurer pour faire du split tunneling, si ton problème c'est le débit et la surconsommation issue du chiffrement des données.

Selon l'humeur j'ai 2 profils pour le VPN : soit 0.0.0.0/0 (tout le trafic passe par lui), soit seulement 192.168.1.0/24
C'est ça que tu appelles split tunnelling ? (ne faire passer que le trafic vers 192.168.1.x via le VPN ?)

oui

Je suis en train d'essayer Truenas Scale pour mon nouveau serveur, ça à l'air plutôt bien.


 
Je suis en train regarder un peu la configuration du merdier.

Perso, j'adore.
Je suis total novice et utilisateur "casual", mais déjà, c'est tellement plus agréable à l'emploi que OMV !
On est presque dans le confort d'un DSM (j'ai bien dit "presque" hein ).
 
Par contre, la gestion des droits SMB m'ont un peu surpris, y a des trucs à bidouiller pour pas se retrouver avec un partage en lecture seule d'origine.

Ouai j'arrive à activer le service SMB, mais pour le moment mon user n'a pas de droit en ecriture, un RTFM s'impose je pense

 
Je l'ai installé vite fait sans pousser encore.
 
C'est sa partie virtu qui m'intéresse (suite à l'arrêt d'HyperV server par MS), et la possibilité de faire du iscsi

Ce machin est un simili proxmox intégrant un orchestrateur de VM et de conteneurs en plus de gérer les apps?

Y'a aussi la notion de partage et de de sécurité il me semble.

Ouais j'en ai chié pour ça, j'ai pas compris, et leur système de templating de droits est pas très explicite pour le coup.
En plus, suivant l'OS que tu utilises pour attaquer, y a du cache qui fait que t'as l'impression de rien changer, mais au reboot t'as plus accès ...
De mon côté, c'est "tombé en marche" et je serai bien incapable de te dire comment, sans trifouiller un peu...
OMV c'est chiant, y a 23 manips à faire avant d'avoir factuellement ton partage, mais au moins sorti du pipeline, ça fonctionne

C'est plutôt nas avec une couche superviseur oui.
 
Je vais bientôt recevoir 2 baies de 24 hdds, je vais utiliser truenas pour faire le nas et faire de la virtualisation de plex/sonar/radar et autre.
 
Je voulais partir sur un promox, mais je trouve la gestion des disques dur et des grappes galères.

Perso j'avais testé mais je suis parti sur Unraid
 
Edit : principalement pour la plus grande simplicité/flexibilité d'unraid. Aussi parce qu'avec truenas il faut pas mal de ram (de la ECC en plus je crois que c'est mieux, et que ça en laisse moins pour les VM/Docker) et qu'on reste sur un système ou si trop de disque tombe, les datas sont morte contrairement a Unraid.

 
Mais c'est quoi la différence entre superviseur = proxmox sur lequel on installe un malheureux SMB et éventuellement n'importe quel système de stockage réseau, et cette solution initialement orientée NAS à laquelle a été ajoutée une couche superviseur?

Parce que hyperviseur + SMB != gestionnaire de fichier avec son cache intelligent et ses optimisations côté filesystem à mon avis.

D'ailleurs, un truc cool avec TrueNAS (activé d'origine d'ailleurs, Eee pense à checker sur ta VM si tu veux booster les perfs le plus possible), c'est qu'il active la compression ZFS sur les volumes.
Donc tu peux rapidement te retrouver avec plus d'espace que tu n'en as en vrai, pour des performances relativement correctes (puisque le cache utilise principalement la RAM).

Ok, merci pour la précision

J'ai pas de vm en fait, j'ai installé directement freenas sur une lame de mon serveur.

edit :

photo de la bête :

4 lames biproc Xeon E5-2630 v4 @ 2.2GHz, 128gb de ram ECC, 4 ssd 960gb intel DC S3520

Actuellement 1 lame avec TrueNas pour test et essai, les 3 autres avec proxmox

Ah mais oui c'est vrai, au temps pour moi

Alors jveux pas faire ma sucrée mais la gestion des droits smb sur TrueNAS c'est de la belle merde.

Mais ce qui est le pire c'est la gestion du réseau. Aucun moyen de niquer l'ipv6 et pire encore, quand tu lui configures le réseau en statique et seulement ipv4 il tente quand meme d'attraper une ipv6 en dhcp, ce qui dans mon cas fout la merde car j'ai un tunnel HE pour l'ipv6 et que ça force tout le trafic à passer par là, et donc bridé à 30Mbps au lieu de se cantonner à l'IPv4 configurée proprement

J'étais à 2 doigts d'installer une debian toute simple avec smb et basta...

Je suis dans une config qui fonctionne à peu près mais même les droits sont pas corrects.
exemple :
droit du groupe sur un dossier au niveau systeme et smb: rwx
Mon compte est membre du groupe. Je tente de supprimer un fichier : permission denied
wtf

Je passe sur les maj des apps qui foirent une fois sur 2. Je dois rester sur une vieille version de Plex car l'update ne finit jamais de se deployer...

Fun fact : pas de client ftp sur truenas putain
Si tu veux pousser un fichier depuis le NAS en ftp tu peux pas. Ah et evidemment impossible d'installer quoi que ce soit via apt sauf à bricoler un truc pas stable. TrueNAS reste as-is.

Bref, mettre ZFS sur une debian c'est probablement plus efficace que ce système. Au moins on peut y pousser des trucs via ansible, installer les softs manquants et la config réseau est respectée

Je ddécouvre juste donc je peux pas trop te dire, mais ftp est bien dans les services en tout cas :  

Client versus serveur, c'est pas trop pareil.

exact ^^

Je sais que je peux etre bête aprfois mais quand même

 
Je n'en ai jamais laissé en prod, à cause de la consommation. Par exemple sur certains Mikrotik, je crois que tu n'est pas sensé en mettre sur tous les ports quand ils sont "collés" entre eux.

Bon, mon serveur dédié oneprovider me fait des misères après 3 ans de fonctionnement stable.
 
J'ai une seule appli qui tourne dessus, ce matin je vois qu'elle n'est pas super réactive, je me connecte en SSH, je reboote, et là c'est le drame.  
 
- Plus de ping
- Console TTY de secours qui me dit "connection closed", même quand je reboote
- Redémarrage en mode récupération qui ne fonctionne pas plus, la console TTY me dit f#ck.
Seule chose que je sais, l'espace disque restant était de 40% / 350Go avant que je reboote, donc c'est pas un pb de disque plein.
 
Bref, j'avais un dédié sur oneprovider  

Et le /boot n'était pas plein ? Le nombre de fois où j'ai reboot avec le /boot saturé et que j'ai du passer en rescue mode

 
il n'est pas censé se remplir tout seul hein

Un apt upgrade de trop, le message d'erreur du dpkg-reconfigure pour le boot kernel qu'on n'a pas vu et hop, le drame

Possible, mais bon j'ai dû faire un ticket d'intervention.
Si je perds la machine, je réinstallerai un proxmox, même si c'est un Atom C2350 / 1.7 GHz / 2 coeurs. En 2019 ce n'était pas proposé ou alors j'ai pas vu.

 
je déconseille, c'est une machine trop anémique pour que ce soit réellement utilisable.

si je mets une VM debian avec une seule app web, j'ai un petit espoir que ça fonctionne

on perd un peu l'intérêt de l'hyperviseur là

Bah ça me permet de backup la VM tous les jours sur un serveur distant (chez moi en l'occurence) et de la déployer sur n'importe quelle nouvelle machine en 10mn.
Et ça me permet potentiellement de mettre proxmox en mode HA.
 
Là si je dois réinstaller, j'ai au moins 5h de paramétrage pour remettre en état identique.

tu peux peut-être mettre ton app au format Docker ?
 

Si mais pour la gestion des utilisateurs avec la gestion des droits, des comptes utilisateurs, ça devient vite l'usine alors que là j'ai un script d'installation et de gestion qui fait du bon job, et qui ne fonctionnera pas sous docker.

Pourquoi tu mets pas une interface style Virtualmin qui te permettra de backup et au besoin de migrer simplement sur un autre serveur.
 
Et l'install c'est un pauvre script, et ensuite tu as juste a pimper le truc.