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

Support Debian
#8

Oui et non, ça sent surtout la mauvaise nouvelle.

Je me suis trompé en disant Bell, c’est un détail, mais ce sont toutes les deux des adresses appartenant à “virgin home quebec”, Bell n’est que l’opérateur technique derrière, mais l’important, c’est que ça semblent être toutes les deux des adresses domestiques de FAI sortie d’un pool d’adresse appartenant à virgin et fournies temporairement à ton routeur pour sa connexion.

Autrement dit, l’adresse de ton routeur doit changer de temps en temps, la configuration de ton fournisseur d’accès ne te fournit pas une adresse stable et définitive sur ton routeur (une adresse statique).

Plus précisément, ça veut dire que la config qu’on est en train de faire avec 142.116.229.209, si on la fait fonctionner, sera à refaire chaque fois que ton fournisseur d’accès décidera d’attribuer une nouvelle adresse à ton routeur.

Il y a moyen de contourner ce probléme avec une plateforme genre noip, nodns ou dyndns, mais ça veut dire qu’au final, tu ne pourras pas utiliser ton nom de domaine, il faudra en utiliser un autre pris (gratuitement) sur une de ces plateformes.

Mais réglons d’abord le probléme avec ton domaine actuel, tu basculeras sur un domaine dynamique de ce type quand on aura fait marcher.

Ca ne me parle pas trop comme configuration.
Peux tu me dire qui est cet hébergeur, que je voies dans ses documentations à quoi correspond ce type de config ?

La mention de “dynamic dns” peut signifier que ton hébergeur de domaine sait peut être faire du domaine dynamique (comme noip etc), mais ça serait étonnant, je pense plutot que ça signifie que la propagation des modifs sur le domaine est accélérée.

L’adresse 127.0.0.1, qui comme je t’ai expliqué plus haut est une adresse technique interne à chaque machine ne devrait apparaître nulle part dans une config dns de nom de domaine, elle n’y a pas sa place. C’est bizarre, il faudrait peut être l’enlever à un moment, mais a priori, elle ne doit pas gêner pour ce que tu veux faire donc on y touche pas pour l’instant.

Les deux autres enregistrements:

La ligne qui parle de www indique l’ip associée à www.kaufranitz.net AVEC WWW:

mj@mercure:~$ host `www.kaufranitz.net`
www.kaufranitz.net has address 142.116.229.209

Ca c’est correct, elle pointe bien vers l’adresse de ton routeur que tu as relevée avec whatsmyip:
il faut vérifier encore une fois avec whatsmyip si l’adresse de ton routeur est toujours 142.116.229.209, ça a peut être changé dans la nuit, mais c’est bien cette adresse trouvée avec whatsmyip qui doit se trouver là.

La ligne avec le symbole @ indique l’ip associée à kaufranitz.net SANS WWW:

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

Mais ce coup ci, ce n’est pas bon, ça devrait être aligné sur la même adresse ip que celle que tu configures pour le domaine SANS www, de manière à ce que ça soit indifférent de s’adresser à kaufranitz.net ou www.kaufranitz.net.

Déjà, ça peut expliquer pourquoi tes tests d’hier n’ont pas marché, si tu as essayé de te connecter sur kaufranitz.net c’était encore la mauvaise adresse configurée, c’était sur www.kaufranitz.net que ça pouvait fonctionner.
Mais je viens de tester ce qui existe comme service sur la machine qui est à l’ip 142.116.229.209, celle que tu as vue avec whatsmyip hier soir, et il n’y a que ssh d’accessible dessus, pas de http ou autre.
Donc soit l’adresse a changé dans la nuit, et ce n’est pas ton routeur que je teste, soit la suite de la configuration (les redirections) n’est pas faite correctement.

PREMIERE ACTION A REFAIRE:
Tu retournes sur whatsmyip pour vérifier si ton routeur est toujours sur 142.116.229.209
Chez ton registrar de ndd, tu changes les lignes @ et www pour y mettre l’adresse indiquée par whatsmyip
Sur ton serveur en ligne de commande, tu peux pourras vérifier si ça s’est bien propagé jusqu’à toi en vérifiant que les adresses ip que tu as configurées sont à jour en utilisant les commandes host kaufranitz.net et host www.kaufranitz.net

Ensuite, tu dis:

Puis:

Alors non.
C’est soit l’un (fonctionnement en DMZ) soit l’autre (redirection de port), mais pas les deux.
Et pour la configuration de la redirection de port, c’est presque bon, mais il y a une erreur dans l’adresse ip source:
Web both 192.168.1.135/24 80 192.168.1.135 80
Là tu dis a ton routeur de rediriger ce qui vient de 192.168.1.135 port 80 vers 192.168.1.135 port 80, mais non, c’est tout ce qui vient de n’importe où vers le port 80 qu’il faut rediriger vers ton serveur 192.168.1.135 port 80.
Je ne connais pas la syntaxe pour dire que tu veux rediriger quelle que soit la source dans l’interface web du routeur, peut être qu’il faut laisser le champs “source” vide ou un truc comme ça quand tu configures la redirection, ça dépend de l’interface.

DEUXIEME ACTION A REFAIRE:

  • quand les bonnes adresses seront propagées (vérification avec host que l’ip correspond bien à ce que dit whatsmyip, cf plus haut), tu actives la fonctionnalité DMZ qui redirige tout vers ton serveur.
    Normalement, là ça doit marcher.
    Si ça ne marche pas, tu me le dis ici et je regarderais de chez moi pourquoi.
  • si ça marche en DMZ, c’est déjà bien, mais tu la désactive parceque le port forwarding, c’est plus sécurisé, et donc tu vas corriger tes deux règles de port forwarding en changeant la source pour voir si cette fois ça fonctionne.

Si à un moment ça marche, c’est bien, mais on sait que c’est une configuration qui sautera chaque fois que ton fournisseur d’accés aura envie de changer ton adresse ip, donc on passera à la configuration d’un dns dynamique pour éviter que la config saute.

1 J'aime
#9

Stooop.
Je viens de voiir ce post que tu as fait pendant que je rédigeais ma tartine, et ce que j’y ai dit n’est plus correct.

Attends, bouge pas je prépare un complément.

#10

OK, donc ça ça veut dire que contrairement à ce que je pensais, ton registrar sait gèrer les adresses dynamiques et fournit son propre service ddns.
La config de ddns sur ton routeur a du marcher partiellement puisque le www est bien réglé sur ton ip de routeur.
Par contre, je ne comprends pas pourquoi ça n’a pas marché avec le @ qui reste mal configuré: ça aurait dû, il faudra comprendre pourquoi.
Mais normalement, ça veut dire qu’au moins, tu peux faire tes tests sur www.kaufranitz.net qui a la bonne adresse, et passer à l’étape 2, la config des redirections.

#11

Bonjour mattotop,

J’espère qu’elle était bonne ta tartine peut-être avec de la confiture à la fraise… et surtout un bon café. mmm!!:wink:

Pour continuer notre discussion :

C’est justement pourquoi j’ai installé ddclient sur debian qui est supporté par mon hébergeur Namecheap et aussi configuré mon routeur qui gère le ddns . tu peux aller voir sur leur site qui est assez bien documenté.

Ahh peuchère !Tu as raison ! Mon ip est maintenant : 82.102.18.238.

Sur mon registraire, ça fonctionnerait de cette manière si je mettais exemple : A records WWW mon adresse ip. Mais là, j’ai configuré mon domaine avec un DNS dynamique.
Chose assez étrange, mon adresse ip a changé mais pas chez namecheap ??? les A+ records sont les mêmes qu’hier. Normalement, ils auraient du changer puisqu’il sont configurés pour se renouveler à toutes les minutes.

Je suis certain que tu penseras comme moi qu’il y a là un bug.

Je viens d’appeler chez Virgin Mobile qui affirme qu’ils ne bloquent pas le changement d’ip.
C’est une bonne chose.

Maintenant, j’ai une question pour toi. Nous avons configuré le routeur hier. Mais l’adresse ip de mon modem est évidemment différente : 192.168.2.1. Ne devrait-on pas passer par cette adresse aussi ?

Autre remarque : Si je fais ddclient --query et -force, ddclient retourne toujours 142.116.229.209 au lieu de 82.102.18.238.

Je pense qu’il y a un sérieux foutoir ici. :sob:

Qu’en pense-tu ?

Merci pour tous tes efforts et bonne soirée,

Camaalot

#12

Ah ben… C’est possible, mais il va falloir comprendre ton modem, ce coup ci.

Je résume:
Tu as un client ddns qui va mettre a jour l’ip externe, celle que tu vois avec whatsmyip.
Ca fonctionne a moitié, ça devrait indiquer la même adresse sur www et @.
Sur un des deux ou ça marche, ça permet aux machines qui cherchent à atteindre ton nom de domaine d’envoyer les paquets jusqu’à l’entrée de ton réseau, c’est à dire, je le découvre maintenant, ton modem.
La config qu’on a faite sur ton routeur prend les paquet-s qu’elle reçoit, et les redirige vers ton serveur à l’interieur du réseau, soit avec DMZ, soit en redirigeant un à un les services.
Mais maintenant que tu me dis que tu as un modem, puis un routeur, je m’aperçois qu’on n’a pas dit à ton modem, qui reçoit les paquets, de les transmettre à ton routeur, qui lui même les retransmettra jusqu’à ton serveur.
Il faut donc refaire une config, cette fois sur ton modem, pour lui dire où il doit envoyer les paquets exterieurs qu’il reçoit, car pour l’instant il bloque tout.

Déjà, sur ton routeur (pas le modem), il faudrait que tu trouves dans l’interface d’admin quelle adresse ip il a du coté du modem. Du coté du LAN, il doit avoir comme je l’ai dit avant une adresse du type 192.168.135.XXX pour causer avec les machines du LAN, et coté modem, ça devrait être une autre adresse du genre 192.168.2.XXX, (pour qu’elle puisse causer avec la 192.168.2.1 du MODEM).
Une fois que tu as cette adresse, sur le modem, tu vas faire le même type de configuration que sur ton routeur, c’est à dire soit une DMZ, soit des redirections, qui renvoient tout vers ton routeur.

Et là tu auras une cascade qui prend les paquets arrivant sur ton modem, les transfere sur ton routeur, qui les transfere ensuite vers ton serveur.

Ca va, tu vois ce qu’il faut faire ?

#13

Salut,

Ce serait peut-être bien que @Camaalot nous fasse un petit schéma de son réseau, histoire qu’on ne découvre pas un nouvel appareil à chaque fois !

Ça peut se faire avec Dia ou n’importe quel logiciel de création d’image, ou même simplement en ASCII art :

Serveur ------------------------- (DMZ) routeur -------- Modem ------- WAN
Postes --------- Switch -------(LAN) -----^

1 J'aime
#14

Vous êtes génials les gars.

Ce soir et demain, dimanche, je suis au travail de longues, très longues heures.
Alors, si je ne réponds pas… ne vous en faites pas… je reviendrai dès lundi.

Camaalot

#15

Bonjour @mattotop et @jibe-74

Je suis revenu.

J’ai fait un diagramme de mon serveur comme le demande @jibe-74.

Concernant le modem qui se rajoute. J’ai été aussi surpris que vous qu’il ait son propre ip. En vérité, je dois dire que j,ai changé de FAI il y a seulement quelque semaine pour Virgin Mobile. L’ancien FAI fournissait un modem tout simple qui ne faisait que permettre la connexion internet.
Celui-ci, vous verrez, est plus complet. C’est un petit routeur en soi mais beaucoup moins puissant que me linksys wrt3200ca avec dd-wrt qui est branché au modem.
Alors, là je suis :confounded:.

Voici le diagramme :
serveur

Dites-moi.

Bonne journée,
Camaalot

#16

Salut,

Tu as essayé de faire un joli truc, malheureusement il manque quelques éléments capitaux. Et ton architecture réseau me semble curieuse, mais c’est peut-être que j’interprète mal ton diagramme…

Déjà, comment sont interconnectées tes machines ? On ne voit pas de switch… Si je comprends bien, tu sembles avoir :

  • Ton modem, qui a côté WAN ton adresse publique gérée par ddns, et côté LAN une adresse attribuée par dhcp ? M’étonnerait… Elle doit être fixe, sinon qui serait le serveur dhcp ?
  • Ton routeur, dont tu donnes une seule adresse. Or, tu devrais avoir :
    ** l’adresse de l’arrivée modem (à mettre fixe de préférence et dans le bon réseau : 192.168.2.x, par exemple 192.168.2.2. Tu peux la laisser en DHCP, mais perso je préfère les adresses fixes qui permettent de mieux s’y retrouver)
    ** l’adresse de sortie vers ta Debian. Soit en DMZ, soit en LAN, je vais y revenir
    ** l’adresse de sortie vers ton Windows10 (pas clair où il est branché…), adresse sur réseau LAN (j’explique ci-après)
    ** Eventuellement la sortie vers ton (tes ?) NAS (sont-ce bien des NAS ou de simples disques durs), DMZ ou LAN

Pour ce qui est DMZ et LAN, je crois que ça t’a déjà été expliqué : avoir une DMZ te permet d’avoir un réseau séparé du réseau LAN, avec règles de pare-feu différentes. C’est plus sécurisé, mais un peu plus compliqué pour le FW. On attribue généralement des plages d’adresses différentes pour DMZ et LAN (par exemple, 192.168.3.x pour DMZ, 192.168.1.x pour LAN). Il faut avoir des adresses fixes pour les serveurs (ou alors, gérer les noms), pour les postes de travail tu peux faire soit du dhcp, soit de l’adressage fixe.

Les différents réseaux ne doivent pas s’entrecroiser comme c’est le cas sur ton diagramme. Et un switch devient quasi indispensable dès que tu as plus de deux machines (une en plus de ton routeur…) dans un réseau.

Bon, pour ne pas tout embrouiller, surtout avec des explications qui pourraient ne pas correspondre à ton cas, j’arrête là : réfléchis à ton architecture réseau, et indique-la nous clairement, avec les adresses choisies. Si tu as du mal, je peux te proposer une architecture, mais là j’ai encore trop d’inconnues sur ce que tu veux faire exactement.

#17

Salut @jibe-74.

Merci pour ta réponse.

En fait dans ce diagramme, les réseaux ne s’entrecroisent pas.
Je veux dire que sur un ordinateur est installé debian 9 et openmediavault 4.
Dans OMV 4, on installe des dockers (NGINX, Letsenscrypt…) et des plugins (RSync, SMb/CIFS…)
Aussi, 5 disques durs sont connectés à serveur. 2 que l’on nomme NAS1 et NAS2 (Disques dur de donnés), 2 autres qui sont des backups des deux premiers. Le 5e est seulement un backup de Windows 10 que j’utilise avec un autre ordinateur. Tous ces disques durs sont gérés par le NAS openmediavault.

Nextcloud permettent de se connecter aux disques durs Nas1 et 2 sur internet avec le mon de domaine.

Donc, tout ce matos est connecté au routeur qui est les branché via un cable ethernet au modem.

Maintenant, la question est que puisque le modem ayant son propre ip, ne peut pas communiquer avec le routeur qui a un ip différent, ne serait-il pas mieux d’activer DHCP sur le modem et le déactiver sur le routeur. Ainsi, le modem passe un ip au routeur et à l’ordinateur ? Et boum, de cette façon, tout est réglé ?

Alors, je te laisse là-dessus et on s’en reparle si tu veux.

C’est vraiment gentil de m’aider à trouver une solution :smiley:

Bonne journée,

Camaalot

#18

Salut,

Ok, donc j’ai mal compris ton diagramme. On en reviendrait donc à un schéma simple :

Serveur Debian --------------------- routeur ------------------- modem ---------- Internet

Reste à savoir, là dedans, où tu situes ton poste Windows. Le plus logique serait de le mettre derrière le routeur, soit dans le même réseau que le serveur (donc, un seul réseau LAN), soit de mettre le serveur en DMZ et le poste Windows en LAN (deux réseaux séparés).

Avec du Windows, j’aurais tendance à séparer, pour une meilleure protection. Mais ça oblige à avoir des règles de routage plus compliquées, puisqu’il faut définir les communications entre tous ces réseaux. Là, je dirais que le choix dépend d’abord de ta connaissance de la mise en place de règles de routage.

Pour ce qui est des adresses, tu as donc une IP publique côté WAN, puis un premier réseau entre ton modem et ton routeur, ensuite un ou deux réseaux derrière ton routeur (soit LAN seul, soit DMZ + LAN). Il faut bien comprendre que ces réseaux sont bien séparés physiquement (y compris DMZ et LAN qui se trouvent nécessairement sur deux cartes réseau différentes sur le routeur - sauf config compliquée que je déconseille dans ton cas.). Donc, chacun de ses réseaux doit avoir sa plage d’adresses, et ils communiquent via les règles de routage, sachant que celles de la communication entre le réseau intermédiaire (routeur <=> modem) seront gérées par le modem.

J’ai tendance à plutôt conseiller un adressage fixe qu’utiliser dhcp quand on a peu de machines et peu de changements. Ce n’est pas obligatoire, mais perso je trouve qu’on s’y retrouve mieux. Donc :

  • Pour le réseau intermédiaire, le modem est en 192.168.2.1, il faut donc mettre 192.168.1.x pour le routeur. x étant soit fixé à la valeur que tu veux, soit fourni par le serveur dhcp du modem.
  • Pour les autres réseaux (LAN et DMZ), il faudra deux plages séparées (bon, une seule si tu ne fais pas de DMZ). Celle(s) du routeur sera(ont) fixe(s), et les autres soit fixées par dhcp, soit fixes. Je te conseille vivement de garder fixe celle du serveur, sinon ça va être galère pour t’y retrouver.

Cela nous donnerait le plan d’adressage suivant (je réserve par habitude x.x.x.1 pour la passerelle, c’est à dire l’appareil qui permet la communication entre différents réseaux, x.x.x.2-10 pour les serveurs, et le reste pour les postes, avec une plage DHCP plus ou moins grande dans les adresses hautes : x.x.x.200-254 par ex) :

  • 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.2.x : réseau intermédiaire (modem : 192.168.2.1, routeur 192.168.2.2)
  • 192.168.3.x : réseau DMZ (routeur : 192.168.3.1, serveur en DMZ : 192.168.3.2)

Bon, ce n’est qu’une proposition, tu fais bien comme tu veux, entre autres utiliser du DHCP, l’important est surtout de bien respecter les plages différentes pour les réseaux différents… et de t’y retrouver le plus facilement possible !

Attention aussi que DHCP ne “saute” pas d’un réseau à l’autre : ton modem ne peut pas donner une adresse DHCP à ton serveur Debian, seulement à ce qui se trouve dans le réseau “intermédiaire”, donc seulement à ton routeur. Quant à avoir DHCP à la fois pour la DMZ et pour le LAN, je n’ai jamais fait ça et j’ignore même si c’est possible : il faudrait que je cherche un peu. La DMZ ne contenant normalement que des serveurs, on préfère généralement leur donner des adresses fixes.

Cette doc pourra t’intéresser : c’est très complet, mais expliqué de manière assez claire pour être accessible aux débutants. Tu peux te contenter de ne lire que les chapitres qui t’intéressent directement, et revenir sur les autres quand tu t’aperçois qu’une notion te manque. Elle existe depuis déjà très longtemps, mais est toujours d’actualité.

#19

En fait, ça n’apparait pas trés évident sur ton diagramme.
Faut dire que tu as du te casser les pieds à le faire, mais comme dit @jibe-74 il est illisible pour nous. :smiley:

Tu redis ce qu’on peut à peu prés voir sur ton schema , mais ces informations là n’ont aucune importance pour comprendre ton réseau, ça, c’est juste la répartition de tes applications et comment elles s’articulent entre elles, mais ce qui est utile, c’est le schema des cables qui relient tes machines, switch/routeurs et autres dispositifs, et surtout l’adresse ip qu’il y a au bout de chaque cable pour complèter et trouver celle(s) qui manque(nt) pour finaliser.

OK, c’est donc lui qui sert de switch pour le LAN, son adresse interne de ce coté est 192.168.1.YYY (tu ne l’as jamais indiquée cette adresse, ça pourrait être utile) pour causer avec les autres machines internes, qui doivent avoir donc des adresses 192.168.1.XXX pour causer entre elles et lui envoyer des paquets à router.
Donc déjà, sur le routeur, tu as mis une redirection pour renvoyer ce qui arrive dessus vers ton OMV (qui est à l’adresse 192.168.1.135).
Sauf que si j’en crois ton schema, tu n’as pas modifié l’adresse source de ta redirection de port (je t’ai dit de supprimer ce critère source=192.168.1.135 pour dire au routeur source=n’importelaquelle).

Là tu as un 2e réseau local, avec à un bout ton modem, dont tu nous dit qu’il a une adresse 192.168.2.1 par ce coté là, et de l’autre bout tu as ton routeur, dont tu ne nous a toujours pas dit l’adresse:
sur ce petit réseau à 2 machines, ton routeur a sa propre adresse en 192.168.2.ZZZ, afin de causer avec le modem en 192.168.2.1, et il faut la trouver, elle doit être visible aussi bien sur le modem dans la liste de ses clients dhcp que sur le routeur dans le rapport de configuration générale, tu dois pouvoir trouver cette information manquante.
Comme je t’ai déjà dit, là tu dois refaire sur le modem la même configuration de redirection que sur ton routeur, à la différence pret qu’au lieu de rediriger tout ce qui arrive sur ton routeur vers 192.168.1.135, tu vas rediriger tout ce qui arrive cette fois sur ton modem vers l’adresse de ton routeur en 192.168.2.ZZZ que tu auras trouvée.

Non, parce qu’avec ta configuration physique ou le routeur est intercalé entre le modem et le reste des machines, le dhcp, qui ne passera pas ton routeur (sauf configuration spéciale) ne pourra pas attribuer d’adresse aux autres machines que ton routeur.
Par contre, si tu supprimais ton routeur de l’équation pour brancher directement toutes tes machines sur ton modem, alors, là, oui, tu pourrais effectivement le faire jouer le role de routeur en plus de modem, et le laisser gèrer le service dhcp.
Mais ce n’est pas utile, là, il faut juste que tu trouves cette p#{[ain d’adresse du routeur sur le segment avec le modem, et que tu configures avec les redirections de ton modem vers ton routeur (qui lui même redirigera ensuite vers ton serveur OMV).

C’est tout, et c’est ce que je te disais déjà samedi.

Ca ne marchera peut être pas direct quand tu testeras, car il y a toujours cette histoire de ddns qui ne met pas bien à jour la zone il faudra vérifier qu’elle est bien alignée sur ce que tu whatsmyip, mais la mécanique pour accèder à ton serveur c’est:

  • je demande à la zone ou il faut envoyer les paquets pour kaufranitz,
  • le serveur dns m’indique l’adresse externe de ton modem,
  • j’envoie les paquets sur cette adresse,
  • le modem les prend, les fait passer d’une interface à l’autre coté routeur et les envoie a l’adresse externe du routeur,
  • le routeur fait le même type de routage de ce qui vient de l’exterieur vers l’adresse de ton serveur,
  • là les paquets arrivent bien sur ton serveur.
#20

Bonjour @jibe-74 et @mattotop,

Elle est excellente cette conversation car elle me force à être clair.
L’auteur de ce diagramme est plus celui qui travaille dans le milieu de la santé qu’un architecte de réseau, non !:wink:

Pour être plus précis, mon épouse et mon accédons au réseau par no postes windows via smb.

Selon ma compréhension, pas besoin car la machine Windows n’est qu’un client qui a évidemment des droits r-w. Je suis le seul a y accéder par smb.

Encore, selon ma compréhension, il n’y a qu’une machine debian qui sert des fichiers à machines à l’extérieur de celui-ci pas smb pour la maison. NGINX, letsencrypt, MYSQL, PHP et Nextcloud deviennent important pour se connecter par internet.

Je pars soigner mes patients et je reviens vers 14hh00.

:smiley:

Bonne journée,

Camaalot

#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.