Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Reflection de NAT vers un serveur NTP

    Français
    2
    9
    5.9k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • N
      Nic0
      last edited by

      Bonsoir !

      Je vous rejoins avec une énigme…
      Je n'arrive pas à joindre mon serveur NTP à partir de ma zone LAN, le serveur étant dans la zone LAN.
      J'éclaircis : (normal, vu ce que je viens de mettre au-dessus !)

      J'utilise la version 2.0-BETA4 (i386) built on Sat Aug 21 03:43:51 EDT 2010
      J'ai une box en modem donc sur l'interface WAN, j'ai mon IP publique. J'ai mis un dydns sur mon IP (xxxxxx.dyndns.org). J'ai une interface LAN dans laquelle j'ai mon serveur de temps (Win2003R2) et plusieurs clients (WinXP et Win7). Parmis ces clients, j'ai un fixe, un portable et un autre portable avec lequel je me connecte depuis mon téléphone une clef 3G.

      Mon idée, c'est de fournir un serveur de temps à ma zone LAN et quelques personnes de mon entourage via xxxxxx.dyndns.org.

      Je mets en place un port forward vers le serveur avec comme paramétrage :

      ce qui ne fonctionne pas, c'est la synchro d'un client de la zone LAN vers xxxxxx.dyndns.org.
      J'ai testé d'autres situations qui ont toutes correctement fonctionné :

      • synchro vers xxxxxx.dyndns.org depuis l'extérieur
      • synchro vers mon IP publique depuis l'extérieur
      • synchro vers 192.168.0.11 depuis le lan

      J'ai aussi noté que la synchro vers mon IP Publique d'une machine dans la zone LAN ne fonctionne pas non plus.

      Dans tout ça, j'ai créé un port forward basé sur celui qu'on peut voir en screenshot mais vers le port TCP/3389 sur ce même serveur 192.168.0.11
      Grâce à cette redirection, je peux accéder à un bureau distant sur mon serveur de temps en passant par xxxxxx.dyndns.org quelque soit mon emplacement.
      En désactivant la réflection sur ce port forward vers TCP/3389, je perds l'accès à mon serveur RDP quand je m'y connecte depuis la zone LAN via xxxxxx.dyndns.org

      J'ai activé la réflection NAT sur le port forward de mon serveur de temps, je l'ai aussi désactivé et le résultat est toujours le même.

      Quelqu'un a-t'il une idée ?
      Y a-t'il un problème avec l'UDP ?

      Notes :

      • j'ai ressayé avec une autre redirection : HTTP vers un serveur web monté pour l'occasion => même comportement que pour RDP (OK partout si j'active la réflection)
      • pour RDP et HTTP, j'ai 2 ports externes choisis entre TCP/10000 et TCP/65000
      • J'ai testé HTTP en redirection simple xxxxxx.dyndns.org:80 -> 192.168.0.11:80 => même comportement qu'avec un port externe différent.
      1 Reply Last reply Reply Quote 0
      • J
        jdh
        last edited by

        Je ne vois AUCUN intérêt à faire un port forward vers une machine interne (sauf si cette machine est une source de temps connecté à une horloge atomique !)

        Le principe du NTP est de relier UNE SEULE machine du réseau interne vers un ou plusieurs serveurs NTP public.

        Il se trouve que pfSense comporte lui-même un pgm/daemon NTP.

        La logique (que je pratique) est de s'assurer que pfSense a bien activé ntpd, est bien à jour, avec les bons serveurs (fr.pool.ntp.org pour la France).
        Puis on coche la case qui permet aux machines internes de se mettre à jour par rapport à pfSense.
        (Et, bien sur, la règle d'accès 123/udp+tcp vers pfSense).

        Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

        1 Reply Last reply Reply Quote 0
        • J
          jdh
          last edited by

          Mon idée, c'est de fournir un serveur de temps à ma zone LAN et quelques personnes de mon entourage via xxxxxx.dyndns.org.

          Non !

          • les personnes de l'entourage peuvent se synchroniser elle-même avec un serveur fr.ntp.pool.org
          • les PC internes peuvent se synchroniser avec le pfSense lui-même synchronisé avec un serveur fr.pool.ntp.org

          Il est notable qu'il faut économiser les requêtes NTP.
          Il est à recommander qu'une seule machine se synchronise avec NTP, puis les machines internes se synchronisent avec cette machine.

          Par exemple, sur un domaine Windows, il est essentiel que TOUS les serveurs soit synchronisés (et ce doit être le cas pour les DC).
          Il est ensuite possible de synchroniser les PC "ordinaires" de synchroniser avec le DC (au choix par "net time \DC /yes" ou par gpo).

          Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

          1 Reply Last reply Reply Quote 0
          • N
            Nic0
            last edited by

            @jdh:

            Il est notable qu'il faut économiser les requêtes NTP.
            Il est à recommander qu'une seule machine se synchronise avec NTP, puis les machines internes se synchronisent avec cette machine.

            Du coup, c'est pour ça que j'ai monté un serveur NTP qui synchro sur un strat 2 qui est disponible pour quelques personnes qui n'iront pas surcharger (!) un serveur sur le pool fr.pool.ntp.org ou autre.

            J'ai décidé de ne pas utiliser le pfsense comme serveur de temps car le matériel n'est pas "stable" dans le temps (perte ou gain d'une minute par semaine il me semble), ce qui n'est pas le cas de la machine serveur de temps.

            Dans le principe, ce que je souhaite faire est p't'etre pas l'une des meilleures idées, mais sur le plan de la technique, je vois pas pourquoi la réflection NAT que j'ai mise en place ne fonctionne pas. C'est surtout ça qui m'intéresse  ;)

            1 Reply Last reply Reply Quote 0
            • J
              jdh
              last edited by

              Cela n'a que peu de sens ! (D'ailleurs le moins que l'on puisse, c'est que les explications ne sont pas claires : que vient faire TSE dans le post 1 !)

              ntp(d) est justement conçu pour économiser les requêtes ntp quelque soit le matériel sur lequel il tourne (par des ajustements savants, et le mot est faible !).
              Ce qu'il faut éviter c'est les 30 serveurs d'une même entreprise fasse des requêtes, et ceci pour des milliers d'entreprises.
              Par ailleurs, si pool.ntp.org existe c'est justement pour répartir (merci round-robin) la charge, et éviter les enregistrements normalement nécessaires avec un serveur ntp.

              Quand à un NAT, si la règle est logiquement écrite, il faut passer à un stable "basic" : vérifier si les paquets arrivent et sont traités (raisonnement valable quel que soit le service).
              Cela veut dire tcpdump + vérif de la config de NTPD + (vérif du firewall du serveur lui-même).

              Je serais curieux de voir dans le fichier de conf si le serveur autorise bien une requête de l'extérieur … (jamais le cas dans une conf standard !)

              Perso : je fonctionne comme décrit : pfsense en serveur de temps interne : mes firewalls sont correctement dimensionnés pour être interrogé en interne sans difficulté par les seuls DC et quelques serveurs linux, (et non la masse des PC windows de base ... qui se synchronise au logon script au pire ou via W32time au mieux).

              Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

              1 Reply Last reply Reply Quote 0
              • J
                jdh
                last edited by

                Il y a un détail (dans le titre même) auquel je n'ai pas fait attention !

                NAT reflection. kesako ?

                NAT Reflection - in some configurations, NAT reflection is possible so services can be accessed by public IP from internal networks.

                L'idée est de pouvoir utiliser, à partir de l'interne, l'adresse ip publique puis rentrer via un port forward vers une autre machine interne.

                Je n'ai jamais utilisé ce genre de chose, et je me garderai bien d'activer cela.
                Qui plus est, ici cela n'a aucune utilité eu égard à la motivation (inutile) !

                Il est probable qu'à force de clicker sur à peu près n'importe quelle option, cela puisse fonctionner.
                Mais j'ai observé que, personnellement, j'ai eu beau appuyer sur n'importe quelle série parmi les 88 touches d'un piano, le résultat n'a jamais ressemblé ni à Mozart ni Bach.
                Depuis, j'essaie de ne toucher qu'à ce qui semble utile …

                Il n'empêche, je suggère une démarche qui s'applique à tout service, et elle a l'avantage de vite renseigner sur le fonctionnement ...

                Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                1 Reply Last reply Reply Quote 0
                • N
                  Nic0
                  last edited by

                  J'ai lancé un packetcapture sur l'interface LAN.
                  PFSense reçoit bien la demande, la reroute correctement vers mon serveur de temps interne selon la règle NAT en place.
                  Le serveur répond bien et renvoit la demande au routeur mais après, plus rien.
                  Sachant que vers un client NTP dans la zone WAN, tout se passe bien.
                  J'ai mis à jour hier soir et toujours pas d'amélioration.

                  Je continue de chercher !

                  1 Reply Last reply Reply Quote 0
                  • N
                    Nic0
                    last edited by

                    la reflection fonctionne pour tcp/3389, tcp/80 mais pas pour udp/123 et udp/27015 (Serveur Half-Life 2 Death Match)

                    En faisant rapidement le tour des faits, je concluerai sur "Pourquoi la reflection ne fonctionne-t-elle pas avec le protocole UDP ?"
                    Y a-t-il un bug dans pfSense ou entre la chaise et le clavier ?

                    1 Reply Last reply Reply Quote 0
                    • J
                      jdh
                      last edited by

                      Je note que

                      • il y a démonstration que les paquets arrivent (et ne sont alors pas servis),
                      • quand on ouvre un service, on doit impérativement regarder ce qui est servi et à qui (pour apache, p.e., Alias et allow from),
                      • on ne trouve aucune trace de recherche sur cette question,
                      • il n'y a nul besoin de "NAT reflexion" mais juste d'un banal "port forward" tout à fait ordinaire.

                      Je rappelle, qu'en matière de NTP, quand on est, au mieux en strate 2, il est incompréhensible d'offrir ce service. (pour utiliser un adjectif neutre). (Sauf à être fai pourquoi pas …)

                      Pourquoi la reflection ne fonctionne-t-elle pas avec le protocole UDP ?

                      Ce peut être un problème peut-être.

                      Y aurait-il quelqu'un qui pourrait me donner UN cas (légitime) d'utilisation de NAT reflexion ?
                      (J'ai bien compris ce que c'est censé faire, mais je ne comprends pas pourquoi il faudrait procéder comme cela et dans quel cas)

                      Albert EINSTEIN : Si vous ne pouvez pas l'exprimer simplement, c'est que vous ne le comprenez pas assez bien. (If you can’t explain it simply, you don’t understand it well enough.)

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.