Problème de connection réseau sous debian 9 et NGINX

Support Debian
#21

Non.
C’est un détail, mais samba n’a rien avoir avec l’accés réseau, c’est un protocole pour partager des fichiers.
Par contre, je ne sais pas pkoi jibe dit qu’on a besoin d’infos sur tes postes windows, parce que fondamentalement, OSEF.

Non non.
Ici, tu confond la gestion de ton réseau qu’on est en train de faire (par ou passent les paquets pour aller d’un client internet à ton serveur ou une autre machine de ton réseau) avec la manière dont sont organisés tes services.
J’ai un peu introduit cette notion de service en te recommandant de limiter les redirections à ce que tu veux exposer sur internet (la redirection de ports sur 80 pour le http), mais c’etait un détail en plus du routage, juste pour sécuriser et éviter par exemple que ton samba soit distribué par internet (ce qui serait le cas, si tu utilisais la fonctionnalité “DMZ” qui renvoie tout le trafic sans distinguer les services au lieu des redirections de ports qui elles sont sélectives).

Dis plutôt que tu vas passer plusieurs heures à refuser de leur prescrire des antibios qui ne servent à rien contre le nCov.

#22

Effectivement, on sent bien que tu n’es pas spécialiste des réseaux :smiley: Pas de honte : chacun son métier.

Ce que j’essaie de te faire comprendre et que @mattotop te dit plus clairement, c’est qu’il faut bien distinguer deux choses : les tuyaux et l’eau qui circule dedans (j’allais dire les vaisseaux et le sang, mais je risque de dire de telles énormités que ça risque plutôt de t’embrouiller ! :smiley: ). Le problème que tu nous poses est effectivement que l’eau n’arrive pas au bon endroit, mais pour t’aider on a d’abord besoin de bien comprendre la tuyauterie. Après, on pourra t’expliquer comment envoyer l’eau chaude d’un côté, l’eau froide de l’autre etc.

C’est donc l’ensemble des tuyaux qu’on appelle “architecture réseau” et qui nous intéresse, comme le dit si bien @mattotop :

L’architecture réseau est représentable, comme je l’ai dit, en ASCII art, comme les deux exemples que j’ai dessinés sur ce post et celui de ce matin. Le plan d’adressage en est le complément indispensable.

Pour répondre à la question initiale (routage du protocole HTTP vers NGINX), effectivement, c’est inutile. Mais je crains un peu que les postes Windows soient très mal placés dans l’architecture, surtout lorsque @Camaalot nous dit :

J’ai un peu peur que le réseau des machines Windows soit relié derrière le serveur, et non directement au LAN. Soit :

Routeur ------------------- Serveur -------------- Réseau Windows

au lieu de :

Routeur (LAN ou DMZ) -------------- Serveur
^- (LAN) ------------------------------ Réseau Windows

J’essaie aussi de prévenir de futurs problèmes de routage, si on n’est pas bien d’accord sur la position exacte des postes Windows…

Je précise que @mattotop et moi avons deux manières assez différentes d’aborder le problème. Je ne sais pas laquelle est la mieux, elles peuvent d’ailleurs être complémentaires. @mattotop cherche à comprendre l’architecture existante et à la faire fonctionner, alors que perso, j’essaie d’expliquer la bonne architecture qui devrait être mise en place. J’ai en effet un peu peur que l’actuelle nous révèle de mauvaises surprises !

Je préfère donc proposer un plan d’adressage, facilement adaptable en fonction de l’existant avec un tout petit peu de compréhension des principes de base, plutôt qu’essayer de retrouver l’existant, qui ne sera utile que si l’architecture n’est pas à revoir.

Mais donc, que ce soit en suivant la méthode mattotop ou la mienne, il faut d’abord mettre en place un câblage et un adressage cohérents (ou, s’il est correct actuellement, qu’on en ait bien tous les éléments) - donc, la tuyauterie - , ce n’est qu’ensuite qu’on pourra s’occuper des flux de données entre les différentes machines et applications - l’eau qui circule dans les tuyaux.

#23

Absolument pas.
Je cherche à aider @caamalot à rendre accessible par Internet sur son nom de domaine ce qu’il distribue par son nginx, c’est tout. Pour ça j’avais besoin de quelques éléments de compréhension de la structure du réseau, mais non, je ne cherche pas du tout à faire fonctionner le reste de l’architecture.

Je ne savais d’ailleurs pas qu’il y avait des problèmes à régler avec son fonctionnement. :smile:

#24

Espérons que tu as raison ! :slight_smile:

J’ai un peu peur du contraire voyant les difficultés qu’il a à fournir les éléments nécessaires, mais espérons que je prends les devants pour rien !

#25

Salut @mattotop, @jibe-74,

Il est clair que les virus tels que le ncov sont des bestioles pour rendre la population malade et les vaccins pour la tuer (la population) graduellement. Bill Gates, très impliqué dans la fabrication de vaccins, a déjà affirmé que les vaccins étaient l’outil idéal pour réduire la population mondiale de 80%. Alors, avec les médicaments que l’on donne, on ne soigne pas, on rend la personne plus malade. Mais, c’est une autre histoire. Revenons à notre sujet, beaucoup plus intéressant.

Eh oui, je suis beaucoup plus callé en médecine et en psychologie humaine qu’en architecture de réseau. Je désire aussi faire mention de votre très bonne volonté. Je vous remercie beaucoup pour votre patience avec moi.:wink:

Je comprends bien que ce que vous désirez savoir est comment le sang doit passer des poumons par les artères pulmonaires au coeur. Le sang est pompé des ventricules aux oreillettes. (Là ça fait poum, poum) et sort du coeur par l’aorte, etc. :stuck_out_tongue_winking_eye:

C’est ça l’idée. Un “setup” aussi simple.

Serveur Debian -----> Routeur ----------> Modem -------------------------------------> Internet
192.168.2.13 -----> 192.168.2.11------> (lan) 192.168.2.1 - (wan) 142.116.229.209

Alors, on déactive DMZ sur le routeur ?

Sur le modem je fais :
Applications —Protocol --Source net-----Port from—Ip address-----Port to
Web --------------les deux —192.168.2.13—80-------------192.168.2.13—80
ssh----------------les deux— 192.168.2.13—22-------------192.168.2.13—22

Est-ce bien de cette façon ?:grimacing:

Aussi, est-ce que je garde la redirection sur le routeur aussi ? À tout le moins, j’imagine qu’elle doit être changée pour refléter les ip 92.168.2.13 !:confounded:

Camaalot

#26

Ah non, ça ne va pas du tout, c’est impossible une telle config.
D’abord tu disais que ton serveur debian avait pour adresse 192.168.1.135, et maintenant tu indiques 192.168.2.13, ça ne va pas.
Ensuite, le routeur comme le modem devraient avoir une adresse pour chaque segment de réseau qu’ils relient, et les paires d’adresses de chacun ne devraient pas être sur le même réseau de chaque coté, ce qui n’est pas le cas ici puisque dans ton schema, tout est sur le même réseau 192.168.2.
Bref,
ton schema devrait plutot être (je met verticalement pour rendre plus lisible):

serveur (IPS=192.168.1.135)
<->
(IPRI=192.168.1.?) ROUTEUR (IPRE=192.168.2.13)
<->
(IPMI=192.168.2.1) MODEM (IPME=<ip variable>)
<->
Internet

PUNAISE, je te l’ai dit 40 000 fois: OUI…
Comment peut tu encore poser la question aprés toutes les explications que je me suis fait ch… à bien rédiger pour que tu comprennes ?

Ca vaut aussi bien sur le routeur que le modem, il faut soit des redirections, soit une DMZ, mais pas les deux, et là on est parti pour des redirections.

NON NON ET NON.
Ca aussi je te l’ai dit 1000 milliard de fois et ça vaut la aussi pour le routeur aussi bien que le modem:
tu n’as pas à spécifier de valeur pour ce qui concerne l’adresse source de tes régles.
Ce n’est pas ce qui vient d’une seule adresse ip que tu veux renvoyer vers ton modem, mais c’est TOUTES les adresses “source” dont tu dois transmettre les paquets peut importe d’ou elles viennent .
Donc sur le routeur, là ou tu as fait ça:
(BAD BAD BAD)

Tu t’assures d’avoir remplacé la source que tu avais mise sur 192.168.1.135 dans chaque règle par “rien” ou n’importe quoi qui signifie “toutes les adresses” dans ton interface de configuration que je ne connais pas, ce qui donne:
(GOOD GOOD GOOD)

Et sur ton modem, là ou tu demandes s’il faut faire ça:
(BAD BAD BAD)

Tu fais
(MAYBE GOOD MAYBE GOOD MAYBE GOOD)

Attention:

  • je ne suis pas certain que 192.168.2.13 soit bien l’adresse de ton routeur coté modem, tu parlais aussi dans ton schema d’une adresse en 192.168.2.11 qui pourrait être la bonne, elle sortent d’où ces deux adresses ?
  • pour le ssh, la redirection ne peut pas marcher sur le port 22, car ton routeur utilise lui même le port 22 pour son propre accés ssh (j’ai vérifié). Il faudra ajuster la configuration du modem pour ouvrir le ssh de ton serveur sur un autre port, mais on verra plus tard, pour l’instant, ne t’occupes que des redirections du web sur le port 80, oublie le port 22 qui est un cas particulier.
#27

Salut,

[hors sujet]

Tu as des sources fiables et objectives, de vraies preuves ? On entend tellement tout et son contraire, avec de pseudo preuves invérifiables, que je ne sais vraiment pas quoi penser de la question…
[/Hors sujet]

C’est bien un peu ce que je craignais ! :wink:

Je pense donc, pour ne pas perdre notre temps et s’énerver, qu’on devrait d’abord aider @Camaalot à mettre en place une architecture réseau correcte sans du tout s’occuper des redirections et autres règles de routage, dont on s’occupera une fois que cette architecture sera décidée et mise en place de manière définitive. Le besoin me semble assez bien défini pour qu’on sache comment placer les tuyaux, on verra ensuite comment et où envoyer l’eau.

Ce que tu veux, @Camaalot, est somme toute très classique, et doit donc reposer sur une architecture classique et éprouvée. C’est déjà ce qu’il faut choisir (dans ton cas, il y a deux architectures éprouvées possibles) et mettre en place. Ce choix, j’en ai déjà parlé : c’est avec ou sans DMZ (ce qui n’a rien à voir, à ce stade, avec la configuration DMZ du routeur, qui est la conséquence de ce choix architectural et non le critère pour en décider).

Ces deux architectures ont chacune leurs avantages et inconvénients. Je pense que le meilleur critère de choix dans ce cas précis est ta capacité à mettre en place, le temps venu, les règles de routage nécessaires. En effet, si l’option DMZ est préférable sur le plan de la sécurité, elle entraîne une plus grande complexité des règles qui, si elles ne sont pas bien faites, risquent de faire perdre cet avantage. Or, il semble que tu aies des difficultés à bien comprendre le routage également, et @mattotop est plutôt parti pour te faire faire des redirections, plus adaptées à une architecture sans DMZ. Donc, à moins que toi ou @mattotop n’y voyez un inconvénient, je pars sur une architecture de ce type :

Serveur ------------ Switch -------- (LAN) Routeur (INTER) ------------ Modem (WAN)
Postes W$ ------------^

Les sigles entre parenthèses sont les différents réseaux, dont les adressages devront être bien séparés. Côté LAN (Local Access Network, ton réseau local), un switch permet d’interconnecter les postes de travail sous Windows, le serveur Debian et le routeur. J’appelle (INTER) le micro-réseau qui ne sert qu’à faire transiter les données du modem vers le routeur (et dans l’autre sens), et qui doit être bien séparé du LAN. Le WAN est le côté Internet (concrètement, ta ligne ADSL ou ta fibre).

Pour ce qui est des adressages, on va avoir deux plages d’adresses différentes pour la partie privée (LAN et INTER) et ton adresse IP publique (que tu nous indiques être 142.116.229.209 mais qui est une IP dynamique, donc susceptible de changer à n’importe quel moment). Je pars sur un adressage fixe partout (sauf côté WAN bien sûr), puisque c’est aussi dans ce sens que te conseille @mattotop et que ce sera certainement beaucoup plus simple à comprendre. Je te propose donc :

  • 192.168.1.x : réseau LAN (routeur : 192.168.1.1, serveur en LAN : 192.168.1.2, Windows : 192.168.1.10, 192.168.1.11 etc.)
  • 192.168.2.x : réseau intermédiaire (modem : 192.168.2.1, routeur 192.168.2.2)

Je laisse volontairement tomber l’adresse 192.168.1.135 dont je n’ai jamais compris si elle était sur le routeur (ce que j’ai cru comprendre de tes explications et schémas) ou côté serveur (ce que laissent croire les rêgles de routages que tu donnes). Il n’y a pas d’inconvénient à la conserver, à partir du moment où tu comprends parfaitement ce que tu fais et nous expliques clairement où elle se trouve. Mais comme elle est facile à changer, c’est peut-être plus simple de ne plus en parler pour éviter les confusions. À toi (et éventuellement mattotop s’il a une préférence) de voir…

Voilà. As-tu bien compris cette architecture et le plan d’adressage ? Si oui, et si @mattotop n’y voit pas d’inconvénient, on va partir là-dessus pour établir les règles de routage, qu’on verra dans un second temps pour ne pas aller trop vite et tout mélanger, et surtout pour partir sur quelque chose de bien défini, sur lequel nous soyons tous d’accord et donc stable et définitif.

Note que si tu mets en place dès maintenant cette architecture et cet adressage, il est fortement probable qu’il n’y ait plus grand chose qui fonctionne : les règles de routage actuelles ont de fortes chances de ne pas être adaptées. Mais on aura déjà les bons tuyaux aux bons endroits, il suffira d’ouvrir les bonnes vannes pour que tout fonctionne :slight_smile:

Dit autrement (et en espérant ne pas dire trop de bêtises), tu avais un appareil circulatoire où tu mélangeais circulation pulmonaire et l’autre (je ne sais plus son nom…). On commence donc par remettre un coeur compartimenté de la bonne manière et les bons circuits de circulation (veines et arthères). Du coup, plus rien ne fonctionne, puisqu’il faut encore que nous mettions en place les valvules et les règles de contraction du coeur, ce dont on va s’occuper prochainement.

Si tu ne veux pas risquer de n’avoir plus rien qui fonctionne en attendant, tu peux très bien te contenter d’étudier et comprendre l’architecture et le plan d’adressage que je propose, sans les mettre en place, et tu les mettras en place en même temps que les règles de routage. L’important, c’est de fixer ça de manière ferme et définitive, et de ne plus digresser avec des choix de branchements ou d’adresses.

#28

Non Jibe, c’est totalement superflu voire contre productif:
on a passé depuis longtemps les trucs de merdouillage qui énervent, l’existant est à un epsilon de marcher, autant aller jusqu’au bout.

Si tu veux lui recommander un truc bien carré, qui règle la place de chaque élément du réseau jusqu’au moindre passage d’électron quand il aura fini et que ça marche, libre à toi de lui recommander de la mise au carré, mais là, l’objectif est juste de rendre son site dispo sur le net.

#29

Euh… C’était dans ton post précédent, et @Camaalot n’a pas confirmé qu’il avait bien tout compris et remis d’aplomb…

Je souhaite vraiment que tu aies raison, mais n’y crois pas trop… En tous cas, pas sans que ce soit au détriment d’autres choses.

Ok. Si le but est de faire n’importe quoi “pourvu que ça fonctionne”, en se foutant de la sécurité, de l’évolution future et de comprendre le pourquoi et le comment, je te laisse faire : ce n’est pas ainsi que je travaille et on ne pourra qu’embrouiller un peu plus @Camaalot si on passe son temps à se contredire.

Reste que je pense que c’est à lui que revient la décision. Je reste à sa disposition s’il préfère ma méthode.

#30

Bonjour,

En réponse @mattotop

Calme-toi s.t.p. Je te demande de rester poli. Je sais très bien que je ne suis qu’un rookie dans ce domaine mais, j’ai beaucoup de bonne volonté, de désir d’apprendre et que j’ai réellement besoin que ça fonctionne.
Que dirais-tu si tu avais absolument besoin d’apprendre des notions de nursing et de médecine. Je m’énerve contre toi parce que tu n’arrive pas à comprendre certaines explications simples. Tu ne trouverais ça pas très cool de ma part… Non !
Rien ne t’oblige à merdouiller comme tu dis sauf que, de mon côté, j’apprécie vraiment beaucoup votre aide à vous deux.:grin:

Continuons si vous le voulez bien.

Je crois bien qu’il y avait quelque chose que je ne comprenais pas et surtout que, hier soir, j’ai été quelque peu confondu. Pour accéder à la config du modem, je devais me connecter sur le réseau du modem. Le modem me donnait les adresses 192.168.2.11 (routeur) et 192.168.2.13 (serveur). J’ai cru que c’était la bonne façon de bien configurer le tout. En plus de penser que je devais changer l’adresse ip du routeur pour qu’il puisse, avec le serveur, communiquer ensemble.
De là l’erreur que j’ai commise de vous donner des adresses ip erronées. 192.168.2.11 et 192.68.2.13 etc., avec des redirections toutes aussi fausses. Je m’excuse !:pensive:

Ce matin, avant de partir pour le travail, à lire les commentaires de @mattotop, je me suis senti un peu con de ne pas comprendre. Alors, j’ai réfléchi et j’ai possiblement compris ce qui n’allait pas.

Je m’excuse @mattotop, je vais certainement reprendre ton schéma :

serveur ----> routeur ----> modem ----> internet

Mon serveur a cet ip : 192.168.1.135 attribué par le routeur.

Côté Lan, le routeur a cet ip : 192.168.1.1 Ok !

Côté Wan, le routeur a cet ip : 192.168.2.11 attribué par le modem. Toujours Ok ?

Le modem, lui, côté Lan a cet ip : 192.168.2.1 et côté Wan, cet ip dymanique 142.116.229.209 attribué par Virgin Mobile.

Enfin, Namecheap résout cet adresse dynamiquement grâce à ddns.

Je crois que c’est plus clair maintenant. Le routeur a attribué cet ip au serveur.
Si aujourd’hui, je tape cet ip (192.168.1.135) dans firefox, j’arrive sur ma page web et 192.168.1.135:8080 j’arrive sur la gui de Openmadiavault.

Donc, ce que dit @jibe-74 :

Peut-être exprimé par ce que j’ai écris plus haut, non ! :woozy_face:

Windows (192.168.1.132), OSEF, je me branche par smb configuré avec Openmediavault, parce que :

Pour la 40 001e fois:laughing:, je désactice DMZ sur le routeur pour ne pas exposer le serveur 192.168.1.135.

Sur le modem, je vais corriger la redirection comme suit :
Applications —Protocol --Source net-----Port from—Ip address-----Port to
Web --------------les deux —toutes—80-------------192.168.2.11—80
https-------------les deux— toutes—443-------------192.168.2.11—443

et j’enlève :
ssh----------------les deux— toutes—22-------------192.168.2.13—22
parce que :

Merci pour vos multiples explication et j’espère avoir compris quelque chose cette fois-ci.
Sinon, j’abdique :cry::cry::cry:

Bonne journée,

Camaalot

#31

@jibe-74, il y a beaucoup de sources qui sont très fiables mais alternatives.
Et, puisqu’elles ne sont pas reconnues officiellement, elles sont bafouées par les médias.

On a jamais entendu parler de la pharmaceutique Pfizer qui a testé un médicament sur le peuple nigérien causant des dizaines de milliers de morts. Le gouvernement nigérien a intenté en vain une poursuite judiciaire contre la compagnie.
Bayer’s et l’acide Acétylsalicylique ou Aspirine est un réel poison, etc., etc…
Ma fille qui est secrétaire médicale à Strasbourg pourrait nous en parler beaucoup.

Bonne journée,

Camaalot

#32

Oh tu sais, malgré des pics d’agacement parfois, je me calme vite, tkt. :wink:

OK, mais pourquoi me le demander ?
Où n’aurais je pas été poli ?
Rude, je veux bien, énervé si tu veux, mais pas poli, c’est pas mon genre.
Aprés, j’avais quand même des raisons de m’énerver sur des points que je t’avais répèté plusieurs fois sans que tu les notes, et ça, peu importe que tu sois rookie, ce n’est pas une raison, je me trouve légitime à raler dans ce cas.
Bref.

Je ne peux pas vérifier tout ça, mais ça me semble cohérent, et a priori, on a tout ce qu’il faut comme info sur les ips.
Mais faudrait pas que tu ressortes un routeur de plus ! :smiley:

Je laisse Jibe en juger.

C’est ça.
Sauf que ça ne géne pas de laisser la règle pour ssh, mais simplement elle ne va pas fonctionner.
Mais c’est un détail.
Et sur le routeur, tu vérifies bien aussi que tu as le meme type de redirection du port 80 à destination cette fois de 192.168.1.135, mais avec “toutes” comme adresse source (les dernières fois que tu as parlé de la config du routeur, tu avais encore laissé 192.168.1.135 comme source, tu ne semblais pas avoir corrigé).

J’ai une petite question secondaire qui me vient soudain:
ton adresse 192.168.1.135, elle est attribuée en dhcp par le routeur ou bien tu l’as configurée en dur sur le serveur ?
Si c’est le dhcp du routeur, tu l’as bien rendue invariable au niveau du routeur (pour forcer le routeur à attribuer toujours cette adresse à ton serveur) ?
Parce que sinon, même si c’est peu probable, le dhcp peut tout à fait décider de changer cette adresse là, et notre petite configuration pourrait sauter.

#33

Salut @mattotop,

Ici au Québec, la culture est très différente de la France. On ne réagit pas de la même façon. Je te souhaite un jour, de venir visiter notre belle ville américano-européenne. Tu verras pas toi-même. Aussi, j’ai beaucoup de racines en France, ma femme est française. mes filles aussi et j’ai plus de famille là-bas qu’ici. Donc, pas de souci.

Bon,

Je suis d’accord, on va dans la bonne direction.
J’essayais de trop penser, de voir trop loin ce que j’avais sous mes yeux.

Oui c’est cohérent.

Ah ! j’en ai un autre, un Lynksys wrt1900ac dans un placard. Si tu veux, je le sort !!:smiley:

De toute façon, j’ai configuré /etc/group et -group sur debian pour me connecter en ssh avec putty et shellinabox (Plugin Openmediavault). Je laisse tomber cette règle comme tu le conseille.

Oui, c’est corrigé. C’est cool !

Elle est attribuée en dhcp. Je trouverai la façon de la rendre invariable. J’ai une véritable tête dure. Quand je décide de comprendre quelque chose. Rien ne peut m’arrêter jusqu’à ce que j’y arrive. Crois-moi !:crazy_face:

Moi aussi j’ai une question pour toi.
Devrais-je garder la config ddns sur le routeur ou utiliser seulement ddclient ?
Je sais que je t’ai déjà posé la question, mais j’ai l’impression que ça peut créer des conflits.

Bonne journée,

Camaalot

#34

C’est possible que ça crée des conflits et que ça soit la raison des soucis de mise à jour qu’on a vu au départ.
Logiquement, vu que c’est ton serveur que tu veux viser avec ton ndd, c’est sur ton serveur que tu dois mettre le ddclient, histoire de ne pas avoir à le remettre sur un autre routeur si jamais tu emmène ton serveur ailleurs.
Mais bon:
un seul ? oui
lequel ?c’est celui que tu souhaites.

Sinon, j’ai testé et ça marche avec www.
Pour sans www, ça ne marche pas, mais ça doit être le soucis de mise à jour du ddns qu’on a vu au début.
Aprés, je remarque que j’arrive sur une page d’un apache par défaut , pas un nginx et ce n’est sans doute pas le même site que tu voies sur 192.168.1.135 quand tu te connectes sur le LAN.
Tu confirmes ?

Si c’est bien ça, il faut que tu modifies juste un peu ta configuration de site qui marche sur 192.168.1.135 pour en faire une config de “name virtual host” qui fonctionnera sur ton nom de domaine. Donne nous ta config de virtual host, et on te donnera les modifs.

#35

Rebonjour @mattotop et @jibe-74,

J’ai pris du temps à répondre car le travail oblige et j’ai dû reconfigurer mon routeur. Il a planté ! Pourquoi, je ne sais pas. Ça ma pris un sacré temps à tout refaire mais, ça fonctionne.

Oui, je suis d’accord avec toi. Je crois que c’est la solution la plus logique.

Ça ne marche toujours pas avec et sans www.

Je vous passe le config de nginx/sites-available.

server {
	listen 80;
	listen [::]:80;
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;

 	server_name kaufranitz.net www.kaufranitz.net;
	
	root /var/www/kaufranitz.net;

# SSL
#	ssl_certificate /etc/letsencrypt/live/kaufranitz.net/fullchain.pem;
#	ssl_certificate_key /etc/letsencrypt/live/kaufranitz.net/privkey.pem;
#	ssl_trusted_certificate /etc/letsencrypt/live/kaufranitz.net/chain.pem;

# security
	include nginxconfig.io/security.conf;

# index
	index index.html index.htm;

# index.php
#	index index.php;

# index.php fallback
#	location / {
#		try_files $uri $uri/ /index.php?$query_string;
#	}

# handle .php
#	location ~ \.php$ {
#		include nginxconfig.io/php_fastcgi.conf;
#	}

# additional config
	include nginxconfig.io/general.conf;
#}

# subdomains redirect
#	server {
#	listen 443 ssl http2;
#	listen [::]:443 ssl http2;

#	server_name *.kaufranitz.net;

# SSL
#	ssl_certificate /etc/letsencrypt/live/kaufranitz.net/fullchain.pem;
#	ssl_certificate_key /etc/letsencrypt/live/kaufranitz.net/privkey.pem;
#	ssl_trusted_certificate /etc/letsencrypt/live/kaufranitz.net/chain.pem;
#	return 301 https://kaufranitz.net$request_uri;
#}

# HTTP redirect

#server {
#	listen 80;
#	listen [::]:80;
#	server_name .kaufranitz.net;
#	include nginxconfig.io/letsencrypt.conf;
#	location / {
		return 301 https://kaufranitz.net$request_uri;
#	}
}

Merci et bonne journée,

Camaalot

#36

Ah si si.
Quand j’ai essayé l’autre jour, c’était le www qui fonctionnait, et là c’est sans www, et j’ai ça:
image

Par contre, coté config de dyndns avec ton registrar, c’est toujours tout pourri:

mj@mercure:~$ host kaufranitz.net
kaufranitz.net has address 142.116.231.95
kaufranitz.net mail is handled by 10 eforward2.registrar-servers.com.
kaufranitz.net mail is handled by 15 eforward4.registrar-servers.com.
kaufranitz.net mail is handled by 20 eforward5.registrar-servers.com.
kaufranitz.net mail is handled by 10 eforward1.registrar-servers.com.
kaufranitz.net mail is handled by 10 eforward3.registrar-servers.com.
mj@mercure:~$ host www.kaufranitz.net
www.kaufranitz.net has address 127.0.0.1

il faut absolument règler ça. Tu peux indiquer le fichier de config de ton ddclient, histoire qu’on regarde (en masquant bien sur les identifiants/passwords), mais je crois qu’il faut que tu voies ça surtout avec ton registrar.

Sauf que comme l’indique la capture précédente, c’est apache qui tourne/répond sur le port 80, pas nginx.
Tu es certain que tu accèdes à un nginx sur ton lan ?
Avec l’url http://192.168.1.135 ?

Sinon je ne connais pas bien la configuration nginx (quelqu’un va devoir prendre le relais sur cette partie là), mais vu que ton apache, lui, tourne, tu peux faire un test:

  • crées un fichier /etc/apache2/sites-available/kaufranitz.net.conf, avec dedans:
<VirtualHost *:80>
    ServerName kaufranitz.net
    ServerAlias www.kaufranitz.net
    DocumentRoot /var/www/kaufranitz.net

    <Directory /var/www/kaufranitz.net>
        Options Indexes FollowSymLinks Includes
        AllowOverride All
        Order allow,deny
        Allow from all
    </Directory>
</VirtualHost>

Ensuite tu l’actives a2enmod kaufranitz.net (ou bien kaufranitz.net.conf, je ne sais plus).
Peut être redémarrer apache:
sudo systemctl restart apache2
Et là, ton site devrait être dispo par le nom de domaine quand les adresses sont bonnes sur le dyndns (note: je ne dis pas qu’il va marcher, mais tu pourras - enfin - y accéder)

#37

Bonjour encore @mattotop, @jibe-74,

Là, je suis bouche bée. Apache n’est pas installé ni activé sur mon système.
Et, au passage, je ne connais absolument rien de apache !!!
La seule chose qu’il y a est :
±–/etc/apache2/
|-------- +/conf-available
|----javascript-common.conf
|----php7.0-cgi.conf
|----php7.0-fpm.conf
|--------/mods-available
|-------/sites-available (que je viens de créer avec ton virtualHost)
|—kaufranitz.net.conf

Impossible d’activer quoi que ce soit. ni avec a2enmod, niavec a2ensite ???

Effectivement, je me demande pourquoi www ne se met pas à jour.
Je te file une image du registrar :
namecheap

J’ai déjà écris au registrar mais, je pense bien le refaire et je vous reviens. C’est très étrange.

Je passe une autre image, celle-ci de la config proposée par Namecheap :
ddclient
et enfin ma config perso :
ddclient2

Pour terminer,
J’ai été obligé de me connecter directement sur le modem. Le routeur fait encore des siennes.
Maintenant, la config est encore plus simple :
serveur Debian (192.168.2.13) Openmediavault (192.168.2.13:8080) - NGINX (192.168.2.13:80) ------> modem (192.168.2.1)--------> Wan (142.116.231.95) ----->Namecheap-----> Internet

La redirection est faite sur le modem :
Applications Protocol Source net Port from—Ip address Port to
Web les deux toutes 80 192.168.2.13 80
https les deux toutes 443 192.168.2.13 443
OMV le deux toutes 8080 192.168.2.13 8080

Pour les machines Windows (192.168.2.12 et .14), on s’en fout. Elle sont branchée via smb.

Après, il va rester à regarder les iptables.

Merci beaucoup,

Camaalot

#38

Ca serait étonnant qu’en allant vers une ip configurée chez ton registrar dans ton domaine, je tombe par hasard sur une ip domestique (=de particulier) ou se trouve une machine debian qui assure un service web.
Donc je suis à peu prés sur que c’est >TON< serveur apache qui répond sans que tu le saches.
Mais ça se vérifie facilement:
en root ou avec sudo:

netstat -nlp | grep ":80"
#39

Alors déjà dans ce que je lis de ce que dit namecheap, tu dois dupliquer ce que tu as déjà mis en remplaçant dans cette deuxiéme config le @ par un www
Ca va déclencher une deuxième mise à jour chez eux, mais pour définir aussi l’adresse ip de ton sous domaine www point kaufranitz point net (qui est distinct de kaufranitz point net ).
Et là, les deux, avec www et sans www se resoudront avec la même ip, ça, tu pourras le constater, ça devrait se faire tout seul , et ça voudra dire que cette adresse qui remonte correctement chez namecheap déboule bien sur ton apache, et donc que c’est bien un apache et pas un nginx. :smiley:

#40

Il y a une autre possibilité.
C’est que ton nginx serve par défaut la page qui dit que c’est un apache.
Mais ça serait quand même un fier bordel, cette histoire, si elle était vraie.