le X-post sur un newsgroup MacOSX et un newsgroup Linux est lié au
fait que je ne sais pas exactement d'où vient mon problème.
J'ai un réseau local, avec Free dégroupé, le modem étant en mode
routeur, avec comme configuration :
- wifi activé
- routeur activé, redirection de tous les paquets vers mon serveur en
local (abusivement dénoté "DMZ" dans la conf Free), DHCP activé sur
une plage de .100 à .200.
sur mon serveur en local, j'ai une debian avec :
- un serveur DNS, a priori bien configuré avec les zones suivantes :
- hiegel.fr , accessible de l'extérieur, en DNS principal (SOA)
toutes les IP rendues donnent mon adresse IP publique, donc sur le
routeur free vu depuis réseau local.
- sweethome, mon réseau local, à savoir 192.168.1.0
- un serveur web, également, configuré sur la base de hiegel.fr
et j'ai diverses machines sur mon réseau : du windows, du linux, et
mon ibook avec macosx.
au départ, en configurant mon serveur local comme serveur dns, avec
sweethome comme domaine de recherche par défaut, et ma freebox comme
routeur : tout fonctionne, sauf l'accès à www.hiegel.fr depuis le
réseau local : c'est la freebox qui tentait de répondre à la
requête. En effet, elle redirige les flux de l'extérieur vers mon
serveur, mais pas ceux du réseau local..
donc
j'ai mis mon serveur local en tant que routeur pour toutes mes
machines du réseau, lui-même utilisant ma freebox comme routeur par
défaut.
j'y ai également rajouté une règle iptables en DNAT pour rediriger les
paquets à destination de mon IP publique depuis mon réseau local sur
l'IP locale correspondant à mon serveur, çàd 192.168.1.1.
ça marche pour toutes les machines... sauf pour mon ibook depuis hier soir.
çàd qu'avant hier soir, depuis mon ibook quand j'accédais à
www.hiegel.fr, je tombais sur mon site assez rapidement. depuis hier
soir, rien à faire, l'accès à www.hiegel.fr est ... très ... lent...
Genre, il me faut plusieurs minutes pour obtenir la page html, puis
les images, puis les fichiers .css ...
depuis mon portable Linux, ça passe très bien.
depuis mon desktop windows, ça passe très bien aussi.
donc j'incrimine macOsx. mais j'avoue que je ne comprends pas du tout
pourquoi il est si lent !? Un ping ou un traceroute depuis mon ibook
est très très lent.
la seule chose que j'ai fait avant que çe ne fonctionne plus aussi
bien sur mon ibook, c'est de reconfigurer un peu mon serveur DNS.. Et
a priori je n'ai aucune erreur dessus.
J'ai retenté un coup ce soir, cette fois-ci c'est la freebox qui se
prend mes requêtes http depuis l'iBook !?
pour les routes.. j'ai mis comme gateway dans les préférences réseau
pour la carte wifi "192.168.1.1", je n'arrive pas à trouver comment
afficher cette information dans le Terminal..
Quant à mon serveur en local, sa config est la suivante :
% ifconfig
eth1 Link encap:Ethernet HWaddr 00:08:54:3e:c3:20
inet adr:192.168.1.1 Bcast:192.168.1.255
Masque:255.255.255.0
adr inet6: 2a01:e35:2f56:5590:208:54ff:fe3e:c320/64
Scope:Global
adr inet6: fe80::208:54ff:fe3e:c320/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1605567 errors:0 dropped:0 overruns:0 frame:0
TX packets:1758666 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
RX bytes:212335780 (202.4 MiB) TX bytes:1077347475 (1.0 GiB)
Interruption:17 Adresse de base:0xa000
(j'ai viré la conf de lo)
% iptables -t nat -L
hugues has to give password to become root:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT all -- sweethome/24 mail.hiegel.fr to:192.168.1.1
la règle DNAT pourrait ne figurer que dans OUTPUT, au départ je
l'avais mise dans PREROUTING avant de me rendre compte que ça ne
fonctionnait pas si je voulais me connecter en local. C'est tout.
pour FILTER, il n'y a rien et la policy par défaut est ACCEPT.
Voilà, si vous voulez plus d'infos, n'hésitez pas...
À (at) Fri, 17 Oct 2008 11:26:43 +0200, Hugues écrivait (wrote):
Sauf que dans le cas de mon ibook, ma freebox reçoit ces paquets.. ça ne devrait pas être.
Je soupçonne un problème dans la table de routage de mon ibook. Je ne sais pas comment vérifier ça proprement avec le terminal.. (la commande "route" n'a rien à voir avec la version GNU).
Ah oui, j'avais oublié de répondre à ça.
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Et ben je me rends compte que MacOSX rajoute automatiquement des routes vers les réseaux auxquels j'accède ? Genre, le réseau d'un copain, sur lequel j'ai fait un ssh.. Et du coup je comprends mieux : à un moment, j'ai viré les règles DNAT, donc mon IP publique a été reroutée vers ma freebox. Depuis, la route a été mise à jour et jamais modifiée.... Et visiblement c'était persistant après un reboot... Donc question : comment peut-on configurer l'automatisme du routage à ce niveau ?
J'ai même flushé la table ARP sans succès.
Le routage, c'est du niveau 3. ARP c'est du niveau 2 1/2... ;-)
Je me disais qu'il avait gardé une entrée de mon IP publique sur l'adresse MAC de ma freebox, mais non, c'est limité aux adresses locales, évidemment.
-- Hugues
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (at) Fri, 17 Oct 2008 11:26:43 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
Sauf que dans le cas de mon ibook, ma freebox reçoit ces paquets.. ça
ne devrait pas être.
Je soupçonne un problème dans la table de routage de mon ibook. Je ne
sais pas comment vérifier ça proprement avec le terminal.. (la
commande "route" n'a rien à voir avec la version GNU).
Ah oui, j'avais oublié de répondre à ça.
La bonne commande Unix pour vérifier le routage, c'est 'netstat'
('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!!
(j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les
noms des réseaux indiqués dans le premier résultat).
Et ben je me rends compte que MacOSX rajoute automatiquement des
routes vers les réseaux auxquels j'accède ? Genre, le réseau d'un
copain, sur lequel j'ai fait un ssh..
Et du coup je comprends mieux : à un moment, j'ai viré les règles
DNAT, donc mon IP publique a été reroutée vers ma freebox. Depuis, la
route a été mise à jour et jamais modifiée....
Et visiblement c'était persistant après un reboot... Donc question :
comment peut-on configurer l'automatisme du routage à ce niveau ?
J'ai même flushé la table ARP sans succès.
Le routage, c'est du niveau 3. ARP c'est du niveau 2 1/2... ;-)
Je me disais qu'il avait gardé une entrée de mon IP publique sur
l'adresse MAC de ma freebox, mais non, c'est limité aux adresses
locales, évidemment.
À (at) Fri, 17 Oct 2008 11:26:43 +0200, Hugues écrivait (wrote):
Sauf que dans le cas de mon ibook, ma freebox reçoit ces paquets.. ça ne devrait pas être.
Je soupçonne un problème dans la table de routage de mon ibook. Je ne sais pas comment vérifier ça proprement avec le terminal.. (la commande "route" n'a rien à voir avec la version GNU).
Ah oui, j'avais oublié de répondre à ça.
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Et ben je me rends compte que MacOSX rajoute automatiquement des routes vers les réseaux auxquels j'accède ? Genre, le réseau d'un copain, sur lequel j'ai fait un ssh.. Et du coup je comprends mieux : à un moment, j'ai viré les règles DNAT, donc mon IP publique a été reroutée vers ma freebox. Depuis, la route a été mise à jour et jamais modifiée.... Et visiblement c'était persistant après un reboot... Donc question : comment peut-on configurer l'automatisme du routage à ce niveau ?
J'ai même flushé la table ARP sans succès.
Le routage, c'est du niveau 3. ARP c'est du niveau 2 1/2... ;-)
Je me disais qu'il avait gardé une entrée de mon IP publique sur l'adresse MAC de ma freebox, mais non, c'est limité aux adresses locales, évidemment.
-- Hugues
Paul Gaborit
À (at) Fri, 17 Oct 2008 13:38:49 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux régner) : d'abord le routage (donc niveau adresse IP et uniquement ça) puis le niveau DNS (association correcte IP <-> nom)
Sans le '-r' vous mélangez les deux niveaux...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 13:38:49 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat'
('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!!
(j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les
noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux
régner) : d'abord le routage (donc niveau adresse IP et uniquement ça)
puis le niveau DNS (association correcte IP <-> nom)
Sans le '-r' vous mélangez les deux niveaux...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 13:38:49 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux régner) : d'abord le routage (donc niveau adresse IP et uniquement ça) puis le niveau DNS (association correcte IP <-> nom)
Sans le '-r' vous mélangez les deux niveaux...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Paul Gaborit
À (at) Fri, 17 Oct 2008 13:56:24 +0200, Paul Gaborit écrivait (wrote):
Sans le '-r' vous mélangez les deux niveaux...
Il fallait évidemment lire «... sans le '-n'... »
Désolé.
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 13:56:24 +0200,
Paul Gaborit <Paul.Gaborit@invalid.invalid> écrivait (wrote):
Sans le '-r' vous mélangez les deux niveaux...
Il fallait évidemment lire «... sans le '-n'... »
Désolé.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Tu devrais mettre un BIND 9 sur ton Linux, avec deux "vues", une interne, une externe. C'est très simple à faire.
C'est ce que j'avais fait quand j'étais encore chez moi.
-- Xav The cracked brass bells will ring, To summon back the fire witch
Hugues
Ce cher Paul Gaborit a dit :
À (at) Fri, 17 Oct 2008 13:38:49 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux régner) : d'abord le routage (donc niveau adresse IP et uniquement ça) puis le niveau DNS (association correcte IP <-> nom)
Sans le '-n' vous mélangez les deux niveaux...
Oui en effet, mais vu que le DNS fonctionnait à coup sûr.. Enfin bref :)
-- Hugues
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (at) Fri, 17 Oct 2008 13:38:49 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat'
('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!!
(j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les
noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux
régner) : d'abord le routage (donc niveau adresse IP et uniquement ça)
puis le niveau DNS (association correcte IP <-> nom)
Sans le '-n' vous mélangez les deux niveaux...
Oui en effet, mais vu que le DNS fonctionnait à coup sûr..
Enfin bref :)
À (at) Fri, 17 Oct 2008 13:38:49 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
La bonne commande Unix pour vérifier le routage, c'est 'netstat' ('route' c'est uniquement pour le modifier) :
netstat -rn
Aaaah, super, merci !!! (j'ai eu le réflexe de tester netstat -r, sans le -n afin d'avoir les noms des réseaux indiqués dans le premier résultat).
Il vaut mieux résoudre les problèmes séparément (diviser pour mieux régner) : d'abord le routage (donc niveau adresse IP et uniquement ça) puis le niveau DNS (association correcte IP <-> nom)
Sans le '-n' vous mélangez les deux niveaux...
Oui en effet, mais vu que le DNS fonctionnait à coup sûr.. Enfin bref :)
-- Hugues
Hugues
Ce cher (Xavier) a dit :
Hugues wrote:
[...snip les détails...]
Tu devrais mettre un BIND 9 sur ton Linux,
c'est déjà le cas,
avec deux "vues", une interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
simple choix personnel.
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
-- Hugues
Ce cher xavier@groumpf.org (Xavier) a dit :
Hugues <hiegel@hugues.fr> wrote:
[...snip les détails...]
Tu devrais mettre un BIND 9 sur ton Linux,
c'est déjà le cas,
avec deux "vues", une
interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même
comportement DNS sur le domaine hiegel.fr en interne et en externe.
simple choix personnel.
techniquement c'est parfaitement faisable (mon installation le prouve)
et ça marche. donc pourquoi m'en priverais-je ? :)
avec deux "vues", une interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
simple choix personnel.
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
-- Hugues
Paul Gaborit
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
Ce cher (Xavier) a dit :
Hugues wrote:
[...snip les détails...]
Tu devrais mettre un BIND 9 sur ton Linux,
c'est déjà le cas,
avec deux "vues", une interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
simple choix personnel.
Je soupçonne, derrière cet insistance à garder la même adresse IP (apparente) en interne qu'en externe, un autre problème technique que vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un certificat SSL pour un serveur qui a plusieurs adresses IP (une publique et une privée).
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas dépendant de lui. En terme de performances réseau (débit et ping) et de celles du serveur (qui pourrait faire autre chose), vous y gagneriez beaucoup...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 16:12:17 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
Ce cher xavier@groumpf.org (Xavier) a dit :
Hugues <hiegel@hugues.fr> wrote:
[...snip les détails...]
Tu devrais mettre un BIND 9 sur ton Linux,
c'est déjà le cas,
avec deux "vues", une
interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même
comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
simple choix personnel.
Je soupçonne, derrière cet insistance à garder la même adresse IP
(apparente) en interne qu'en externe, un autre problème technique que
vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un
certificat SSL pour un serveur qui a plusieurs adresses IP (une
publique et une privée).
techniquement c'est parfaitement faisable (mon installation le prouve)
et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de
routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur
ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas
dépendant de lui. En terme de performances réseau (débit et ping) et
de celles du serveur (qui pourrait faire autre chose), vous y
gagneriez beaucoup...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
Ce cher (Xavier) a dit :
Hugues wrote:
[...snip les détails...]
Tu devrais mettre un BIND 9 sur ton Linux,
c'est déjà le cas,
avec deux "vues", une interne, une externe. C'est très simple à faire.
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
simple choix personnel.
Je soupçonne, derrière cet insistance à garder la même adresse IP (apparente) en interne qu'en externe, un autre problème technique que vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un certificat SSL pour un serveur qui a plusieurs adresses IP (une publique et une privée).
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas dépendant de lui. En terme de performances réseau (débit et ping) et de celles du serveur (qui pourrait faire autre chose), vous y gagneriez beaucoup...
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Hugues
Ce cher Paul Gaborit a dit :
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple, et ça me permet d'avoir une même base en interne et externe.
Je soupçonne, derrière cet insistance à garder la même adresse IP (apparente) en interne qu'en externe, un autre problème technique que vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un certificat SSL pour un serveur qui a plusieurs adresses IP (une publique et une privée).
Bof, mon certificat SSL est déjà auto-signé, donc..
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas dépendant de lui. En terme de performances réseau (débit et ping) et de celles du serveur (qui pourrait faire autre chose), vous y gagneriez beaucoup...
Ah, là, oui, vous avez un peu raison :-) Le jour où mon serveur vendra des hot-dogs à la chaîne, pourquoi pas, mais là il n'est pas tellement sollicité, j'oserais dire.. :-)
Mais en effet, c'est pas totalement idiot comme vision. Je la garde donc sous le coude :)
Merci ;) -- Hugues
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (at) Fri, 17 Oct 2008 16:12:17 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même
comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple,
et ça me permet d'avoir une même base en interne et externe.
Je soupçonne, derrière cet insistance à garder la même adresse IP
(apparente) en interne qu'en externe, un autre problème technique que
vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un
certificat SSL pour un serveur qui a plusieurs adresses IP (une
publique et une privée).
Bof, mon certificat SSL est déjà auto-signé, donc..
techniquement c'est parfaitement faisable (mon installation le prouve)
et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de
routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur
ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas
dépendant de lui. En terme de performances réseau (débit et ping) et
de celles du serveur (qui pourrait faire autre chose), vous y
gagneriez beaucoup...
Ah, là, oui, vous avez un peu raison :-)
Le jour où mon serveur vendra des hot-dogs à la chaîne, pourquoi pas,
mais là il n'est pas tellement sollicité, j'oserais dire.. :-)
Mais en effet, c'est pas totalement idiot comme vision. Je la garde
donc sous le coude :)
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple, et ça me permet d'avoir une même base en interne et externe.
Je soupçonne, derrière cet insistance à garder la même adresse IP (apparente) en interne qu'en externe, un autre problème technique que vous n'avez pas su résoudre. Par exemple (au pif), la validation d'un certificat SSL pour un serveur qui a plusieurs adresses IP (une publique et une privée).
Bof, mon certificat SSL est déjà auto-signé, donc..
techniquement c'est parfaitement faisable (mon installation le prouve) et ça marche. donc pourquoi m'en priverais-je ? :)
Parce que tout votre réseau dépend de votre serveur qui fait office de routeur/DNAT/DNS, etc. Alors qu'avec notre proposition, votre serveur ne fait que HTTP et éventuellement DNS mais votre réseau n'est pas dépendant de lui. En terme de performances réseau (débit et ping) et de celles du serveur (qui pourrait faire autre chose), vous y gagneriez beaucoup...
Ah, là, oui, vous avez un peu raison :-) Le jour où mon serveur vendra des hot-dogs à la chaîne, pourquoi pas, mais là il n'est pas tellement sollicité, j'oserais dire.. :-)
Mais en effet, c'est pas totalement idiot comme vision. Je la garde donc sous le coude :)
Merci ;) -- Hugues
Paul Gaborit
À (at) Fri, 17 Oct 2008 17:26:24 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple,
De notre côté : - un serveur DNS avec deux vues De votre côté : - un serveur DNS avec une seule vue - un routage/DNAT à configurer - toutes les machines du réseaux local à configurer (avec des bugs si ça change...) - une dépendance au serveur central - des performances réseaux moins bonnes
Je me demande si on a vraiment la même conception de la simplicité. ;-)
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 17:26:24 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (at) Fri, 17 Oct 2008 16:12:17 +0200,
Hugues <hiegel@hugues.fr> écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même
comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple,
De notre côté :
- un serveur DNS avec deux vues
De votre côté :
- un serveur DNS avec une seule vue
- un routage/DNAT à configurer
- toutes les machines du réseaux local à configurer
(avec des bugs si ça change...)
- une dépendance au serveur central
- des performances réseaux moins bonnes
Je me demande si on a vraiment la même conception de la
simplicité. ;-)
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
À (at) Fri, 17 Oct 2008 17:26:24 +0200, Hugues écrivait (wrote):
Ce cher Paul Gaborit a dit :
À (at) Fri, 17 Oct 2008 16:12:17 +0200, Hugues écrivait (wrote):
j'avais envisagé ça, mais finalement non, je veux avoir le même comportement DNS sur le domaine hiegel.fr en interne et en externe.
On se demande bien pourquoi ?
Je trouve ça plus simple,
De notre côté : - un serveur DNS avec deux vues De votre côté : - un serveur DNS avec une seule vue - un routage/DNAT à configurer - toutes les machines du réseaux local à configurer (avec des bugs si ça change...) - une dépendance au serveur central - des performances réseaux moins bonnes
Je me demande si on a vraiment la même conception de la simplicité. ;-)
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
xavier
Hugues wrote:
Je trouve ça plus simple, et ça me permet d'avoir une même base en interne et externe.
Avec les directives $INCLUDE tu peux avoir un fichier commun pour les deux vues :
------ Vue interne --------- $ORIGIN hiegel.fr $INCLUDE SOA-ET-MX www IN A adresse.IP.de.ta.freebox ----------- eof-------------
------ Vue externe --------- $ORIGIN hiegel.fr $INCLUDE SOA-ET-MX www IN A 192.168.1.1 ----------- eof-------------
-------- SOA-ET-MX --------- $TTL 86400 @ SOA (tout ce qu'il faut ) NS www.hiegel.fr. MX www.hiegel.fr.
mail CNAME www
macbook IN A 192.168.1.2 windowsdelacopine IN A 192.168.1.3 ----------- eof-------------
-- XAv In your pomp and all your glory you're a poorer man than me, as you lick the boots of death born out of fear.
Hugues <hiegel@hugues.fr> wrote:
Je trouve ça plus simple,
et ça me permet d'avoir une même base en interne et externe.
Avec les directives $INCLUDE tu peux avoir un fichier commun pour les
deux vues :
------ Vue interne ---------
$ORIGIN hiegel.fr
$INCLUDE SOA-ET-MX
www IN A adresse.IP.de.ta.freebox
----------- eof-------------
------ Vue externe ---------
$ORIGIN hiegel.fr
$INCLUDE SOA-ET-MX
www IN A 192.168.1.1
----------- eof-------------
-------- SOA-ET-MX ---------
$TTL 86400
@ SOA (tout
ce qu'il faut
)
NS www.hiegel.fr.
MX www.hiegel.fr.
mail CNAME www
macbook IN A 192.168.1.2
windowsdelacopine IN A 192.168.1.3
----------- eof-------------
--
XAv
In your pomp and all your glory you're a poorer man than me,
as you lick the boots of death born out of fear.
