Ce qui serait intéressant est de voir/lire le fichier source relatif à la zone DNS du nom de domaine !
@Camaalot : vous gérez tout cela au-travers d’OMV - OpenMedia Vault - si j’ai bien compris, mais la partie DNS est gérée par la société tierce, n’est-ce pas ?!
J’aimerais comprendre : ce domaine est hébergée où ? sur votre lieu de travail ?!
Pourquoi ne pas géré le serveur DNS au-travers d’OMV ?
Sans aller jusqu’à gérer localement le serveur DNS, ce qui n’est pas très simple/rassurant pour un “débutant”, il y a peut-être moyen d’accéder directement au fichier de zone, sans passer par l’éditeur du registrar (mode expert ou quelque chose du genre) ?
Cela dit, si @Camaalot se sent de le faire, pourquoi pas ? c’est une expérience enrichissante ! Mais si j’ai bien compris, OMV était sur son routeur, plus ou moins hors service… Il faudrait bing ou autre sur son serveur.
??? étonnante réponse ! précise, stp !?
Effectivement !
Lapsus dactylographique : je parlais de bind, bien évidemment !
@jibe-74, @mattotop et @PengouinPdt,
Lorsque je me suis décidé à contacter la communauté pour tenter de régler ce problème, que je croyais banal, j’étais à des années-lumières de penser que cette discussion était pour aller aussi loin.
Je vais prendre un peu de temps mais je vais répondre à toutes les interrogations.
Tout d’abord, je pense sincèrement qu’il faut être gentilhomme pour revenir sur son post avec cette très belle attitude que démontre @jibe-74. Merci beaucoup.
Je m’attriste tout de même du départ de @mattotop.
Ce n’est pas @mattotop qui m’a fait adopter cette architecture. Le fait est que, comme je l’ai déjà dit plus haut, ça fait très peu de temps que je suis avec la compagnie Virgin Mobile comme FAI. Avant, j’étais avec un autre FAI qui fournissait un modem tout simple qui se connectait au routeur et je n’éprouvait aucun problèmes de connexion. Mais depuis, plusieurs fois par jour, le réseau se déconnectait sans raison apparentes. Peut-être était-ce un conflit entre le modem/routeur de Virgin et le wrt-3200ac de Linksys ? Toujours est-il que depuis que j’ai décidé de connecter le serveur directement sur le modem/routeur de Virgin, les problèmes de déconnexion ont cessés. Et, par le fait même l’architecture plus simple.
C’est l’architecture qui convient pour le moment, oui. Peut-être que plus tard je déciderai d’ajouter des postes. L’avenir le dira et on verra en temps et lieu.
J’ai testé le traceroute avec Nmap.
Effectivement qu’on peut s’étonner car on s’attend à ce Nmap nous indique la route qu’emprunte une demande d’accès à un ip ou à un domaine. Mais, ce qui n’est pas normal est qu’il n’y ait pas de résultat. Ceci veut nécessairement dire que le tracé est bloqué à quelque part, mais où ! C’était la même chose pour le ping. Pourquoi je peux sans problèmes pigner Google ou 8.8.8.8 et que je n’y arrive pas pour 192.168.2.13, 142.116.231.95 ou bien kaufranitz.net ?
À ce moment, m’est venu à l’idée du Firewall, iptables qui, peut-être, bloquait l’accès ?
Bon, tu réponds à ma question. Merci. J’ai plusieurs fois contacté Namecheap tout en mentionnant que je pouvais pas me connecter au domaine et en leur demandant si la config de mon A+ était bonne (Surtout que @ retournait toujours 127.0.0.1. (voyez plus haut, j’ai posté une image)). Il m’ont toujours répondu par l’affirmative.
Dans ma petite tête, la logique me disait qu’il y avait certainement un bug. Jamais ils ne m’ont proposé de configurer un CNAME pour www et URL redirect pour @ et que ddclient assurerait la mise à jour de l’ip. Voilà où est la logique. Ça j’aime.
Non, comme je disais plus haut, un FW qui bloque l’accès au domaine.
C’est simple, on veut que @.kaufranitz.net soit redirigé vers www.kaufranitz.net. Maintenant, c’est le contraire que se passe. www.kaufranitz.net est redirigé vers kaufranitz.net.
Excusez mon ignorance, mais c’est quoi le fichier source relatif à la zone DNS du nom de domaine ?
J’espère bien comprendre la question.
Non, OMV ne gère que la partie NAS. La partie DNS est gérée par Namecheap qui héberge le domaine.
La question mérite réflexion. Très intéressant.
Comme vous avez certainement remarqué depuis le début cette conversation, j’adore les expériences enrichissantes. Alors, pourquoi pas. Sans oublier que je dois continuer de monter mon serveur en configurant php7.3, letsencrypt et Nextcloud (L’application qui servira à ceux qui y auront accès d’accéder au serveur via internet. En l’occurrence ma fille à Strasbourg.)
Ah non ! OMV est installé sur debian et fonctionne vraiment très bien. J’aime beaucoup ce NAS.
Bing ou Bind ?
Ah voilà ma réponse.
Mais pourquoi ?
Merci pour ce retour enrichissant.
Bonne journée,
Camaalot
Ahhhhhhh!
C’est le modem/routeur qui bloque l’accès.
Je pouvais accéder au domaine parce que 192.168.2.13 était mode DMZ.
Maintenant que je l’ai enlevé, plus rien. &? /"jiH?*?""""@@@ !
Ou pire… mon FAI bloque l’accès.
Si je me branche à mon vpn, tout fonctionne et sans vpn, tout bloque.
Ah, le méchant FAI !
Salut,
Bon, beaucoup de questions… et beaucoup d’inconnues ! Je vais survoler un peu pour permettre un premier tri : on ne va pas pouvoir tout traiter à la fois, il va falloir établir des priorités et mettre les choses au clair pour savoir où on va. Tu as compris que ma démarche ne va pas constituer, comme le faisait @mattotop, à rafistoler, mais à s’assurer d’une bonne base et s’appuyer dessus pour répondre aux besoins.
Ok, donc on reste ainsi du point de vue câblage et plan d’adressage. Si tu as besoin d’autres postes, on verra comment faire, mais il ne sera pas forcément nécessaire de changer.
Oui, ce traceroute et ce ping qui ne passent pas, c’est curieux. Pas nécessairement gênant, puisque ça fonctionne, mais anormal. Si tu veux qu’on étudie pourquoi ça ne passe pas, il faudrait déjà me confirmer la manière dont est câblé ton poste de travail dans le réseau (désolé, je n’ai fait que survoler vos échanges avec @mattotop et ne sais pas ce qui est fait au final). En mentionnant bien les adresses IP, les différents réseaux etc. On fera déjà marcher en local, puis on verra côté WAN ensuite.
C’est assez curieux : c’est ce qui est recommandé par les RFC !
??? C’est quoi cette histoire d’URL redirect ? @ représente ton domaine principal, soit kaufranitz.net. Ta zone DNS doit prévoir un enregistrement A pour faire la correspondance entre le nom et l’adresse IP, il n’y a rien de plus à prévoir… Et je ne vois vraiment pas ce qu’est ce @.kaufranitz.net ! Peut-être encore un truc bizarre de ces interfaces “simplifiées” pour la gestion des zones, qui font qu’on n’y comprend rien !
Bon, je passe sur ce bizarre @.kaufranitz.net. Pour le reste, le DNS va donner l’adresse IP du domaine (mise à jour automatiquement par ddclient), et si la demande est pour www.kaufranitz.net, le CNAME renvoie sur cette même adresse. Donc, tout est normal. Les requêtes arrivent à ton serveur, qui les traite.
Si tu veux qu’une requête sur kaufranitz.net soit transformée en une requête sur www.kaufranitz.net, voire le http redirigé vers https, il va falloir bien définir ce que tu veux pour chaque URL possible, et ajuster la config de nginx en conséquence, éventuellement en ajoutant des redirections.
Actuellement, depuis chez moi, aussi bien http://kaufranitz.net que http://www.kaufranitz.net fonctionnent, en conservant l’URL telle que tapée. Est-ce utile de compliquer pour rediriger l’une vers l’autre ?
La mode actuelle étant la “simplification” par des interfaces incompréhensibles, lorsque tu veux modifier ta zone DNS tu arrives sur un éditeur comme tu nous l’as montré, et qui cache parfois certaines lignes générées automatiquement. Normalement, la configuration d’une zone DNS se fait par un fichier texte normalisé, qu’il devrait être possible de voir probablement en demandant un mode expert ou autre. Ça permet de bien voir tous les détails, exactement telle qu’est faite la config et d’être sûr de ce qu’on fait.
Ok, c’est donc bien ce que je pensais avoir compris.
Pour ce qui est de la gestion du DNS, on pourra le faire si tu veux. Mais, comme tu sembles avoir déjà pas mal de projets, ce n’est peut-être pas le plus urgent ? D’autant que je connais très mal OMV et n’en ai aucune pratique, donc il va falloir que je commence par bien comprendre qui fait quoi, et quelles sont les interactions entre la config Debian “normale” de ton serveur et OMV…
Bon, je ne sais pas ce que t’a fait faire @mattotop, mais il faut que le modem/routeur redirige les requêtes vers ton serveur. Pour ça, il y a souvent deux méthodes : le mode DMZ, ou la redirection de ports.
Le mode DMZ est bien pratique, parce que tout passe à travers, sans restrictions. Mais justement, puisqu’il n’y a pas de restrictions, tout arrive dans le LAN et ce n’est pas sécurisé ! (raison pour laquelle on préfère souvent séparer les réseaux LAN et DMZ).
Si tu veux supprimer le mode DMZ, ce qui est donc une bonne chose pour la sécurité, il faut faire de la redirection de ports, c’est à dire indiquer au modem quels ports il doit transmettre à quelle adresse. Donc, à minima, configurer le transfert du port 80 (http) vers l’adresse IP de ton serveur. Ça, ton FAI n’y peut rien !
L’histoire de ton VPN m’inquiète aussi : je le découvre… Selon ce qu’il relie à quoi, ce que tu constates peut être parfaitement normal. Mais il faudrait que je sache exactement à quoi il sert et comment il est configuré…
Bon, voilà déjà de quoi dégrossir un peu et établir des priorités. Il va falloir prendre les points un par un, en ayant une bonne vue d’ensemble, complète, pour s’assurer de partir sur de bonnes bases et mettre au point une configuration cohérente. À toi de me dire par où tu veux commencer et à me donner les éléments nécessaires.
Salut @jibe-74,
Wouah Ouh ! Que de matériel à répondre. J’aime ça !
Il est tard pour moi, alors demain je te réponds sans faute.
Camaalot
bonjour @jibe-74,
OK, je souscris mais, j’aimerais quand même noter que @mattotop à fait beaucoup d’effort pour dénouer la ba-balle. Et, encore une fois, je félicite sa patience.
Je t’envoie un autre image représentant l’architecture, en espérant que ce soit clair.
Note bien que l’ip attribué par Virgin Mobile est maintenant 142.117.56.140
Ce réseau est hyper simple. Il n’y rien de compliqué dans cette architecture, rien.
Effectivement, j’aime mieux commencer d’une manière assez simple pour pouvoir compliquer plus tard.
Tu argumenteras que le partage de fichiers qui se fait via smb pourrait être fait autrement. Je suis tout ouï.
Le traceroute et le ping doivent passer, c’est obligatoire. Comment vais-je pouvoir configurer letsencrypt si je peux même pas “pigner” mon propre serveur ? Il est essentiel de régler ce problème et, en fait, c’est le plus important, non !
J’ose me répéter mais voilà,
Je pense qu’ils ne se cassent pas trop la tête. Tant que les infos sont au bon endroit, pour eux, tout est parfait.
Même si tu sais, je donne le lien qui explique comment configurer un CNAME.
Par contre, j’ai une excellent question : On doit créer un A + dynamic record et un Cname record.
Dans un premier temps, je crée un A+ — Host: @ — Value: 127.0.0.1 (qui se mettra à jour avec l’ip attribuée par Virgin Mobile) et un CNAME — Host : www — Value: kaufranitz.net
Tu as absolument raison !!! Alors, on laisse tomber.
Si j’ai bien compris, les explications que j’ai donné plus haut devraient être exactes. Tu me dis.
Je te passe le vhost très simple de nginx :
server {
listen 80;
listen [::]:80;
server_name kaufranitz.net www. kaufranitz.net;
root /var/www/html/kaufranitz.net/;
#index
index index.html;
include nginxconfig.io/security.conf;
include nginxconfig.io/general.conf;
}
server {
listen 80;
listen [::]:80;
server_name kaufranitz.net;
return 301 http://www.kaufranitz.net$request_uri;
}
Mais encore ??? Suis-je stupide mais il est où ce fichier et on peut le lire avec quel logiciel ?
Debian (NGINX) gère le serveur et OMV le NAS, donc les disques durs.
Mais, ce que pourrais creuser et que @PengouinPdt proposait, est que OMV puisse gérer le dns grâce au plugin dnsmasq.
Je vois ça plus tard.
Évidemment que j’ai supprimé le DMZ.
Nom Protocole Port interne Port externe Addresse IP
OMV Les deux 8080 8080 192.168.2.13
Web Les deux 80 80 192.168.2.13
https Les deux 443 443 192.168.2.13
Ne t’en fais pas, NordVPN n’est utilisé que sur mon poste Windows. Il n’a rien à voir avec Debian.
Je pense que c’et bien parti, non! Avec toutes les infos que nous avons sous la main, on recmmence par le début et on avance.
Merci beaucoup,
Camaalot
Non en IPv4, ce n’est pas obligatoire ; il vaut mieux. En IPv6, c’est “obligatoire” (du moins pour le ping - mais je ne vais pas me “lancer” dans de longues explications, en gros, c’est tenu au fonctionnement du protocol IPv6 très fortement lié au protocol ICMPv6).
Ensuite, il peut y avoir différentes raisons qui expliquent la non communication du ping, de traceroute : un filtrage par pare-feu est la plus évidente. Reste à savoir si c’est le cas, et si oui, comment !?
Bref, je tente depuis chez moi de pinguer la nouvelle adresse IP 142.117.56.140, malheureusement :
$ ping -c3 142.117.56.140
PING 142.117.56.140 (142.117.56.140) 56(84) bytes of data.
--- 142.117.56.140 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2044ms
Idem pour l’ancienne - puis je fais la même chose pour le nom de domaine :
$ ping -c3 kaufranitz.net
PING kaufranitz.net (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.058 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.084 ms
64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.084 ms
--- kaufranitz.net ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2034ms
rtt min/avg/max/mdev = 0.058/0.075/0.084/0.012 ms
Quoi ? c’est localhost qui répond ! Vraiment pas normal…
(d’autant que je n’ai pas de resolveur DNS cache local).
Bien j’interroge par requête DNS :
$ dig kaufranitz.net
; <<>> DiG 9.11.14-3-Debian <<>> kaufranitz.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64131
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;kaufranitz.net. IN A
;; ANSWER SECTION:
kaufranitz.net. 60 IN A 127.0.0.1
;; Query time: 68 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: mer. févr. 12 01:18:43 CET 2020
;; MSG SIZE rcvd: 59
Donc, on voit bien que le nom de domaine kaufranitz.net a pour adresse ip 127.0.0.1 !!!
(et que c’est bien un résolveur DNS extérieur à chez moi qui a répondu ; en l’occurence celui de Quad9).
Bon, après avoir remonté la “chaîne” de réponses à des requêtes DNS, pour savoir où est la zone DNS correspondant à kaufranitz.net, délivrée par quel(s) serveur(s) DNS, je me mets à interroger les deux serveurs en question (à savoir dns1 et dns2 chez registrars-servers.com) - qui me répondent la même bizarrerie :
$ dig kaufranitz.net @dns1.registrar-servers.com A
; <<>> DiG 9.11.14-3-Debian <<>> kaufranitz.net @dns1.registrar-servers.com A
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29356
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;kaufranitz.net. IN A
;; ANSWER SECTION:
kaufranitz.net. 60 IN A 127.0.0.1
;; AUTHORITY SECTION:
kaufranitz.net. 1800 IN NS dns1.registrar-servers.com.
kaufranitz.net. 1800 IN NS dns2.registrar-servers.com.
;; Query time: 62 msec
;; SERVER: 2610:a1:1024::200#53(2610:a1:1024::200)
;; WHEN: mer. févr. 12 01:19:35 CET 2020
;; MSG SIZE rcvd: 118
kaufranitz.net est enregistré avec une adresse ip localhost. Cela signifie actuellement qu’à chaque fois que quelqu’un demande à aller sur kaufranitz.net, la machine informatique avec laquelle est envoyée la requête aura pour réponse que le nom de machine en question est local à elle-même !!!
Donc, la zone est vraiment mal gérée !
En passant, avoir sur la même machine, le site web et le réseau samba (Windows) n’est pas du meilleur acabit, d’autant si la machine en question est accessible sur Internet. Une faille en cascade permettrait d’atteindre aux différentes données “confidentielles”, voire aux autres machines - je laisse comprendre le résultat catastrophique. 
Merci @PengouinPdt pour cette longue réponse.
J’ai proposé cette piste d’entrée de jeu. Voir la toute première image que j’ai posté. La revoici un peu modifiée :
Ici, je ne connais rien à la configuration de iptables, mais j’imagine que quelque chose devrait passer.
Namecheap avait toujours 127.0.0.1 comme adresse ???!!! Étrangement, l’ip n’avait pas encore été mis à jour. Je l’ai fait moi-même.
C’est pourquoi j’ai écris à @jibe-74 :
S’il y a une autre solution, j’écoute !
Salut,
Je suis vraiment désolé : un imprévu va me tenir éloigné de ce forum pendant au moins plusieurs jours… J’espère que @PengouinPdt et d’autres pourront t’aider à progresser en attendant… Je fais mon possible pour revenir au plus vite…
Puisque je suis là et que ça, c’est assez simple, je donne mon avis sur ta question :
J’ai toujours trouvé un peu idiot d’utiliser un protocole plutôt orienté Windows pour traiter des partages sous Linux. Cela dit, il faut bien avouer que les autres protocoles ne sont pas toujours aussi souples et efficaces… Je dirais donc que c’est plus une affaire de choix personnel : soit tu préfères éviter ce protocole, et tu peux effectivement trouver des alternatives (nfs, sshfs…), soit tu en restes à cette solution assez classique qui a fait ses preuves…
Bon courage pour la suite, je reviens ASAP.
Il suffit de créer un alias (CNAME) dans la zone DNS, par exemple que la commande :
host dyn.lab3w.fr
Retourne l’alias CNAME de mon IP dynamique 
dyn.lab3w.fr is an alias for lab3w.strangled.net.
lab3w.strangled.net has address 86.205.6.216
Et associer : www IN CNAME dyn 
Cordialement,
Romain
Bonjour @ZW3B,
C’est ce que j’ai fait en créant un A+ dynamique host @ 142.117.56.140 et un CNAME host www et kaufranitz.net comme valeur.
Mais comment associe-t-on www IN CNAME dyn?
Merci
Camaalot
Tu crées :
dyn CNAME tonnom.strangled.net.
www CNAME dyn
Tout simplement, sans champ A.
Cordialement,
Romain
Bonne soirée