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...
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage fonctionne avec des adresses, pas des domaines. Accessoirement, quand on manipule des routes il vaut mieux éviter les résolutions de noms, je trouve que ça embrouille. D'où le '-n' avec netstat.
Oui, en fait par "domaine" je voulais dire "réseau".
Bon, je comprends pas comment cette route est arrivée là. Probablement une fausse manip...
Je remarque que la route a le flag DYNAMIC, ce qui signifie que cette route a été créée automatiquement en réaction a un certain événement. Cet événement pourrait être la réception d'un message ICMP Redirect envoyé par le serveur pour signaler qu'il y a une route plus directe pour joindre cette destination. Cela a pu se produire si pour une raison ou pour une autre la règle DNAT n'a pas fonctionné pour un paquet envoyé à cette destination, par exemple parce que le paquet a été classé dans l'état INVALID par le suivi de connexion de Netfilter.
Aha intéressant, ok, merci. Pour le DNAT, j'ai bidouillé un peu mes règles iptables sur le serveur, et j'ai dû vouloir accéder à cette adresse depuis mon iBook à un moment où le DNAT n'était plus en cours. C'est la cause la plus probable qui me vient à l'esprit.
-- Hugues
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route
pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage
fonctionne avec des adresses, pas des domaines. Accessoirement, quand
on manipule des routes il vaut mieux éviter les résolutions de noms,
je trouve que ça embrouille. D'où le '-n' avec netstat.
Oui, en fait par "domaine" je voulais dire "réseau".
Bon, je comprends pas comment cette route est arrivée là. Probablement
une fausse manip...
Je remarque que la route a le flag DYNAMIC, ce qui signifie que cette
route a été créée automatiquement en réaction a un certain
événement. Cet événement pourrait être la réception d'un message ICMP
Redirect envoyé par le serveur pour signaler qu'il y a une route plus
directe pour joindre cette destination. Cela a pu se produire si pour
une raison ou pour une autre la règle DNAT n'a pas fonctionné pour un
paquet envoyé à cette destination, par exemple parce que le paquet a
été classé dans l'état INVALID par le suivi de connexion de Netfilter.
Aha intéressant, ok, merci.
Pour le DNAT, j'ai bidouillé un peu mes règles iptables sur le
serveur, et j'ai dû vouloir accéder à cette adresse depuis mon iBook à
un moment où le DNAT n'était plus en cours. C'est la cause la plus
probable qui me vient à l'esprit.
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage fonctionne avec des adresses, pas des domaines. Accessoirement, quand on manipule des routes il vaut mieux éviter les résolutions de noms, je trouve que ça embrouille. D'où le '-n' avec netstat.
Oui, en fait par "domaine" je voulais dire "réseau".
Bon, je comprends pas comment cette route est arrivée là. Probablement une fausse manip...
Je remarque que la route a le flag DYNAMIC, ce qui signifie que cette route a été créée automatiquement en réaction a un certain événement. Cet événement pourrait être la réception d'un message ICMP Redirect envoyé par le serveur pour signaler qu'il y a une route plus directe pour joindre cette destination. Cela a pu se produire si pour une raison ou pour une autre la règle DNAT n'a pas fonctionné pour un paquet envoyé à cette destination, par exemple parce que le paquet a été classé dans l'état INVALID par le suivi de connexion de Netfilter.
Aha intéressant, ok, merci. Pour le DNAT, j'ai bidouillé un peu mes règles iptables sur le serveur, et j'ai dû vouloir accéder à cette adresse depuis mon iBook à un moment où le DNAT n'était plus en cours. C'est la cause la plus probable qui me vient à l'esprit.
-- Hugues
Hugues
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
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....
Je n'avais pas lu cette partie du fil avant de répondre. Ça appuie mon hypothèse de l'ICMP Redirect. Pour chaque paquet que le serveur doit rerouter vers la Freebox, il envoie ce type ICMP pour signaler à l'expéditeur qu'il aurait pu envoyer le paquet pour directement à la Freebox. Si l'expéditeur prend en compte cet ICMP, il crée dynamiquement une route d'hôte pour l'adresse de destination du paquet, qui est prioritaire sur la route par défaut. Les paquets suivants destinés à cette adresse sont donc envoyés directement à la Freebox.
Ok super !
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse ! C'est juste que pour hiegel.fr ça n'aurait jamais dû le faire, et ça n'arrivera plus maintenant que tout est entré dans l'ordre et figé.
Avec un routage bancal comme celui que tu as mis en place, il ne faut
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre. Plutôt que mettre par défaut la freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues dans BIND.
Finalement, je suis en train d'y travailler. Histoire d'apprendre un peu plus de trucs ;)
En fait je reste persuadé que ma solution est *une* solution propre, et que celle des vues BIND en est une autre, tout aussi propre. Pas forcément mieux que la mienne ; tout dépend des objectifs d'administration...
Et visiblement c'était persistant après un reboot...
Ça, par contre, ça me surprend.
Si j'ai l'occasion, j'essaierai d'y jeter un oeil. Mais pour le moment ça me saoûle de m'amuser à rebooter mon ibook juste pour ça ;)
-- Hugues
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
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....
Je n'avais pas lu cette partie du fil avant de répondre. Ça appuie mon
hypothèse de l'ICMP Redirect. Pour chaque paquet que le serveur doit
rerouter vers la Freebox, il envoie ce type ICMP pour signaler à
l'expéditeur qu'il aurait pu envoyer le paquet pour directement à la
Freebox. Si l'expéditeur prend en compte cet ICMP, il crée
dynamiquement une route d'hôte pour l'adresse de destination du
paquet, qui est prioritaire sur la route par défaut. Les paquets
suivants destinés à cette adresse sont donc envoyés directement à la
Freebox.
Ok super !
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il
peut accéder à certains hôtes/réseaux directement en passant par la
freebox, qu'il le fasse !
C'est juste que pour hiegel.fr ça n'aurait jamais dû le faire, et ça
n'arrivera plus maintenant que tout est entré dans l'ordre et figé.
Avec un routage bancal comme celui que tu as mis en place, il ne faut
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon
routage. Je le trouve très propre. Plutôt que mettre par défaut la
freebox comme routeur et rajouter une exception *sur chaque machine du
réseau* pour le domaine hiegel.fr ..
pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues
dans BIND.
Finalement, je suis en train d'y travailler.
Histoire d'apprendre un peu plus de trucs ;)
En fait je reste persuadé que ma solution est *une* solution propre,
et que celle des vues BIND en est une autre, tout aussi propre. Pas
forcément mieux que la mienne ; tout dépend des objectifs
d'administration...
Et visiblement c'était persistant après un reboot...
Ça, par contre, ça me surprend.
Si j'ai l'occasion, j'essaierai d'y jeter un oeil. Mais pour le moment
ça me saoûle de m'amuser à rebooter mon ibook juste pour ça ;)
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....
Je n'avais pas lu cette partie du fil avant de répondre. Ça appuie mon hypothèse de l'ICMP Redirect. Pour chaque paquet que le serveur doit rerouter vers la Freebox, il envoie ce type ICMP pour signaler à l'expéditeur qu'il aurait pu envoyer le paquet pour directement à la Freebox. Si l'expéditeur prend en compte cet ICMP, il crée dynamiquement une route d'hôte pour l'adresse de destination du paquet, qui est prioritaire sur la route par défaut. Les paquets suivants destinés à cette adresse sont donc envoyés directement à la Freebox.
Ok super !
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse ! C'est juste que pour hiegel.fr ça n'aurait jamais dû le faire, et ça n'arrivera plus maintenant que tout est entré dans l'ordre et figé.
Avec un routage bancal comme celui que tu as mis en place, il ne faut
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre. Plutôt que mettre par défaut la freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues dans BIND.
Finalement, je suis en train d'y travailler. Histoire d'apprendre un peu plus de trucs ;)
En fait je reste persuadé que ma solution est *une* solution propre, et que celle des vues BIND en est une autre, tout aussi propre. Pas forcément mieux que la mienne ; tout dépend des objectifs d'administration...
Et visiblement c'était persistant après un reboot...
Ça, par contre, ça me surprend.
Si j'ai l'occasion, j'essaierai d'y jeter un oeil. Mais pour le moment ça me saoûle de m'amuser à rebooter mon ibook juste pour ça ;)
-- Hugues
Hugues
X-post et Fu2 f.c.o.u
Ce cher (Xavier) a dit :
Pascal Hambourg wrote:
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse privée dans la vue interne.
Euh oui, affreux type !
:)
Je n'aurais pas mis d'adresses privées dans la partie commune, donc la vue externe. Ça n'a aucun intérêt puisqu'elles ne sont pas accessible de l'extérieur, et en plus c'est mal, cf. RFC 1918.
C'est MAL, certes, mais ça permet de garder uniquement 3 lignes dnas chaque fichier principal, puisque Hugues trouvait ça trop complexe...
Pour moi "complexe" = informations redondantes. À ne pas confondre avec "me donne mal à la tête" ! :)
En pratique, pour mez zones, je sépare tout dans des répertoires différents.
Et je n'utilise les INCLUDES que pour fixer l'ORIGIN des différents domaines, et inclure un fichier de zone complet commun à tous mes domaines :
Ah ok, avec ton exemple je saisis mieux le principe ! C'est très propre en effet. Je vais probablement appliquer ça.
Mais moi je bloque sur la configuration dans named.conf(.local, mais c'est un détail) pour la zone "hiegel.fr" ?
J'ai pensé à deux zones "hiegel.fr", avec chacune une directive allow-query (l'une en !sweethome, l'autre en sweethome), et chacune une directive "file" différente, mais non, ça ne va pas. La seconde zone n'est jamais "servie"... Càd que si on a un deny sur la première zone, apparemment ça ne va pas tenter de trouver une autre zone en allow ?
J'ai épluché le man named.conf de bind ce matin, et plusieurs exemples sur le net, mais je ne trouve nulle part comment faire...
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse
privée dans la vue interne.
Euh oui, affreux type !
:)
Je n'aurais pas mis d'adresses privées dans la partie commune, donc la
vue externe. Ça n'a aucun intérêt puisqu'elles ne sont pas accessible de
l'extérieur, et en plus c'est mal, cf. RFC 1918.
C'est MAL, certes, mais ça permet de garder uniquement 3 lignes dnas
chaque fichier principal, puisque Hugues trouvait ça trop complexe...
Pour moi "complexe" = informations redondantes.
À ne pas confondre avec "me donne mal à la tête" ! :)
En pratique, pour mez zones, je sépare tout dans des répertoires
différents.
Et je n'utilise les INCLUDES que pour fixer l'ORIGIN des différents
domaines, et inclure un fichier de zone complet commun à tous mes
domaines :
Ah ok, avec ton exemple je saisis mieux le principe !
C'est très propre en effet. Je vais probablement appliquer ça.
Mais moi je bloque sur la configuration dans named.conf(.local, mais
c'est un détail) pour la zone "hiegel.fr" ?
J'ai pensé à deux zones "hiegel.fr", avec chacune une directive
allow-query (l'une en !sweethome, l'autre en sweethome), et chacune une
directive "file" différente, mais non, ça ne va pas. La seconde zone
n'est jamais "servie"... Càd que si on a un deny sur la première zone,
apparemment ça ne va pas tenter de trouver une autre zone en allow ?
J'ai épluché le man named.conf de bind ce matin, et plusieurs exemples
sur le net, mais je ne trouve nulle part comment faire...
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse privée dans la vue interne.
Euh oui, affreux type !
:)
Je n'aurais pas mis d'adresses privées dans la partie commune, donc la vue externe. Ça n'a aucun intérêt puisqu'elles ne sont pas accessible de l'extérieur, et en plus c'est mal, cf. RFC 1918.
C'est MAL, certes, mais ça permet de garder uniquement 3 lignes dnas chaque fichier principal, puisque Hugues trouvait ça trop complexe...
Pour moi "complexe" = informations redondantes. À ne pas confondre avec "me donne mal à la tête" ! :)
En pratique, pour mez zones, je sépare tout dans des répertoires différents.
Et je n'utilise les INCLUDES que pour fixer l'ORIGIN des différents domaines, et inclure un fichier de zone complet commun à tous mes domaines :
Ah ok, avec ton exemple je saisis mieux le principe ! C'est très propre en effet. Je vais probablement appliquer ça.
Mais moi je bloque sur la configuration dans named.conf(.local, mais c'est un détail) pour la zone "hiegel.fr" ?
J'ai pensé à deux zones "hiegel.fr", avec chacune une directive allow-query (l'une en !sweethome, l'autre en sweethome), et chacune une directive "file" différente, mais non, ça ne va pas. La seconde zone n'est jamais "servie"... Càd que si on a un deny sur la première zone, apparemment ça ne va pas tenter de trouver une autre zone en allow ?
J'ai épluché le man named.conf de bind ce matin, et plusieurs exemples sur le net, mais je ne trouve nulle part comment faire...
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage fonctionne avec des adresses, pas des domaines.
Oui, en fait par "domaine" je voulais dire "réseau".
Même pas. Là il s'agit d'une route d'hôte vers l'adresse IP dont le reverse DNS est "mail.hiegel.fr", et non d'une route de réseau.
Pascal Hambourg
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Plutôt que mettre par défaut la
freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En routage, il n'y a que des adresses. C'est un peu plus compliqué mais c'est beaucoup plus propre. Il me semble que DHCP a une option permettant de pousser une route sur les clients, mais tu n'utilises pas DHCP.
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il
peut accéder à certains hôtes/réseaux directement en passant par la
freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes
d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils
communiquent.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon
routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est
forcément une solution bancale, sans jeu de mots.
Plutôt que mettre par défaut la
freebox comme routeur et rajouter une exception *sur chaque machine du
réseau* pour le domaine hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En
routage, il n'y a que des adresses.
C'est un peu plus compliqué mais c'est beaucoup plus propre. Il me
semble que DHCP a une option permettant de pousser une route sur les
clients, mais tu n'utilises pas DHCP.
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Plutôt que mettre par défaut la
freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En routage, il n'y a que des adresses. C'est un peu plus compliqué mais c'est beaucoup plus propre. Il me semble que DHCP a une option permettant de pousser une route sur les clients, mais tu n'utilises pas DHCP.
Hugues
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage fonctionne avec des adresses, pas des domaines.
Oui, en fait par "domaine" je voulais dire "réseau".
Même pas. Là il s'agit d'une route d'hôte vers l'adresse IP dont le reverse DNS est "mail.hiegel.fr", et non d'une route de réseau.
Ah oui en effet, je n'avais pas pris le temps de vérifier précisément l'adresse IP.
-- Hugues
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route
pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage
fonctionne avec des adresses, pas des domaines.
Oui, en fait par "domaine" je voulais dire "réseau".
Même pas. Là il s'agit d'une route d'hôte vers l'adresse IP dont le
reverse DNS est "mail.hiegel.fr", et non d'une route de réseau.
Ah oui en effet, je n'avais pas pris le temps de vérifier précisément
l'adresse IP.
AHaaaaa... intéressant. comme ça, il utilise ma freebox comme route pour le domaine hiegel.fr !
Non. Une "route pour un domaine", ça ne veut rien dire. Le routage fonctionne avec des adresses, pas des domaines.
Oui, en fait par "domaine" je voulais dire "réseau".
Même pas. Là il s'agit d'une route d'hôte vers l'adresse IP dont le reverse DNS est "mail.hiegel.fr", et non d'une route de réseau.
Ah oui en effet, je n'avais pas pris le temps de vérifier précisément l'adresse IP.
-- Hugues
Hugues
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce qui n'a l'air d'être le cas que pour l'iBook.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Plutôt que mettre par défaut la freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En routage, il n'y a que des adresses.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
C'est un peu plus compliqué mais c'est beaucoup plus propre.
C'est vrai que.. Mais bon, comme dit, c'est effectivement plus compliqué et surtout beaucoup plus lourd à mettre en place sur chaque client. Donc je n'aime pas cette idée.
Il me semble que DHCP a une option permettant de pousser une route sur les clients, mais tu n'utilises pas DHCP.
Oui, il y a cette possibilité, ce qui serait pas mal.
En fait moi ce dont j'ai surtout envie, c'est d'avoir accès à mes machines du réseau par le biais de leur nom d'hôte sur mon domaine local ".sweethome". J'ai vu qu'il est possible de faire du DHCP dynamique, mais je n'aime pas trop. Sinon il y a la possibilité de faire des baux DHCP permanents sur l'adresse MAC, mais ça me lourde d'avoir à gérer ça. C'est pour cette raison que j'ai opté pour ma solution.
Les serveurs DNS fournis par la freebox en DHCP sont ceux de free.fr. Ça ne me convient pas, et ça m'oblige à me configurer mon propre serveur DHCP pour passer outre. C'est un peu lourd. J'ai laissé le DHCP sur ma freebox pour "dépanner", c'est tout.
-- Hugues
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au
serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il
peut accéder à certains hôtes/réseaux directement en passant par la
freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes
d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils
communiquent.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce
qui n'a l'air d'être le cas que pour l'iBook.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon
routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est
forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Plutôt que mettre par défaut la freebox comme routeur et rajouter
une exception *sur chaque machine du réseau* pour le domaine
hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En
routage, il n'y a que des adresses.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP
d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner
"l'ensemble des IP qui me seront fournies par mon serveur DNS sur
l'ensemble du domaine .hiegel.fr".
C'est un peu plus compliqué mais c'est beaucoup plus propre.
C'est vrai que..
Mais bon, comme dit, c'est effectivement plus compliqué et surtout
beaucoup plus lourd à mettre en place sur chaque client. Donc je
n'aime pas cette idée.
Il me semble que DHCP a une option permettant de pousser une route
sur les clients, mais tu n'utilises pas DHCP.
Oui, il y a cette possibilité, ce qui serait pas mal.
En fait moi ce dont j'ai surtout envie, c'est d'avoir accès à mes
machines du réseau par le biais de leur nom d'hôte sur mon domaine
local ".sweethome". J'ai vu qu'il est possible de faire du DHCP
dynamique, mais je n'aime pas trop. Sinon il y a la possibilité de
faire des baux DHCP permanents sur l'adresse MAC, mais ça me lourde
d'avoir à gérer ça. C'est pour cette raison que j'ai opté pour ma
solution.
Les serveurs DNS fournis par la freebox en DHCP sont ceux de
free.fr. Ça ne me convient pas, et ça m'oblige à me configurer mon
propre serveur DHCP pour passer outre. C'est un peu lourd. J'ai laissé
le DHCP sur ma freebox pour "dépanner", c'est tout.
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce qui n'a l'air d'être le cas que pour l'iBook.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Plutôt que mettre par défaut la freebox comme routeur et rajouter une exception *sur chaque machine du réseau* pour le domaine hiegel.fr ..
Pour l'adresse publique de la Freebox, pas pour le domaine machin. En routage, il n'y a que des adresses.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
C'est un peu plus compliqué mais c'est beaucoup plus propre.
C'est vrai que.. Mais bon, comme dit, c'est effectivement plus compliqué et surtout beaucoup plus lourd à mettre en place sur chaque client. Donc je n'aime pas cette idée.
Il me semble que DHCP a une option permettant de pousser une route sur les clients, mais tu n'utilises pas DHCP.
Oui, il y a cette possibilité, ce qui serait pas mal.
En fait moi ce dont j'ai surtout envie, c'est d'avoir accès à mes machines du réseau par le biais de leur nom d'hôte sur mon domaine local ".sweethome". J'ai vu qu'il est possible de faire du DHCP dynamique, mais je n'aime pas trop. Sinon il y a la possibilité de faire des baux DHCP permanents sur l'adresse MAC, mais ça me lourde d'avoir à gérer ça. C'est pour cette raison que j'ai opté pour ma solution.
Les serveurs DNS fournis par la freebox en DHCP sont ceux de free.fr. Ça ne me convient pas, et ça m'oblige à me configurer mon propre serveur DHCP pour passer outre. C'est un peu lourd. J'ai laissé le DHCP sur ma freebox pour "dépanner", c'est tout.
-- Hugues
Pascal Hambourg
Hugues a écrit :
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Autre inconvénient de taille que j'ai déjà évoqué : si le suivi de connexion sur le serveur classe un paquet entrant destiné à l'adresse publique dans l'état INVALID, alors la règle DNAT sera sans effet et le paquet sera routé vers la Freebox, avec envoi d'un ICMP redirect provoquant la création d'une route d'hôte sur la machine source. Et rebelote, c'est reparti pour un tour. Le suivi de connexion TCP des noyaux 2.6 "récents" (2.6.9 et plus) pouvant être assez susceptible, ce risque n'est pas négligeable.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce qui n'a l'air d'être le cas que pour l'iBook.
Alors l'avantage d'alléger la charge de routage du serveur ne s'applique qu'à l'iBook. Si les autres machines ignorent l'ICMP redirect, elles envoient tout leur trafic sortant au serveur.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
Exemple (en gros) :
=== named.conf == acl lan-v4 { 192.168.1.0/24; }; // reseau local IPv4 acl lan-v6 { 2a01:e35:2f56:5590::/64; ::1; }; // reseau local IPv6 acl lan { lan-v4; lan-v6; }; // reseau local IPv4+IPv6
hiegel.fr. A 82.245.101.89 [+autres enregistrements spécifiques à la vue externe]
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et DNS sont plutôt en charte dans fr.comp.reseaux.ip.]
Hugues a écrit :
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
L'avantage, c'est que ça donne moins de travail de routage au
serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il
peut accéder à certains hôtes/réseaux directement en passant par la
freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes
d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils
communiquent.
Autre inconvénient de taille que j'ai déjà évoqué : si le suivi de
connexion sur le serveur classe un paquet entrant destiné à l'adresse
publique dans l'état INVALID, alors la règle DNAT sera sans effet et le
paquet sera routé vers la Freebox, avec envoi d'un ICMP redirect
provoquant la création d'une route d'hôte sur la machine source. Et
rebelote, c'est reparti pour un tour. Le suivi de connexion TCP des
noyaux 2.6 "récents" (2.6.9 et plus) pouvant être assez susceptible, ce
risque n'est pas négligeable.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce
qui n'a l'air d'être le cas que pour l'iBook.
Alors l'avantage d'alléger la charge de routage du serveur ne s'applique
qu'à l'iBook. Si les autres machines ignorent l'ICMP redirect, elles
envoient tout leur trafic sortant au serveur.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon
routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est
forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic
routé. D'un point de vue topologique c'est un non-sens.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP
d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner
"l'ensemble des IP qui me seront fournies par mon serveur DNS sur
l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
PS : Pour ta question concernant BIND, dans le named.conf il faut créer
deux vues (views), une internet et une externe en fonction de l'adresse
source de la requête, définissant chacune une version différente de la
zone. Accessoirement tu peux en profiter pour désactiver la récursion
pour la vue externe, parce que là ton serveur répond à des requêtes
extérieures pour des domaines autres que ceux pour lesquels il fait
autorité. Et mettre la zone interne uniquement dans la zone interne.
Exemple (en gros) :
=== named.conf == acl lan-v4 { 192.168.1.0/24; }; // reseau local IPv4
acl lan-v6 { 2a01:e35:2f56:5590::/64; ::1; }; // reseau local IPv6
acl lan { lan-v4; lan-v6; }; // reseau local IPv4+IPv6
hiegel.fr. A 82.245.101.89
[+autres enregistrements spécifiques à la vue externe]
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis
pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil
parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et DNS
sont plutôt en charte dans fr.comp.reseaux.ip.]
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Ça me va complètement. si mon iBook est capable de comprendre qu'il peut accéder à certains hôtes/réseaux directement en passant par la freebox, qu'il le fasse !
L'inconvénient, c'est que ça crée sur tes postes des tas de routes d'hôtes dynamiques pour les adresses extérieures avec lesquelles ils communiquent.
Autre inconvénient de taille que j'ai déjà évoqué : si le suivi de connexion sur le serveur classe un paquet entrant destiné à l'adresse publique dans l'état INVALID, alors la règle DNAT sera sans effet et le paquet sera routé vers la Freebox, avec envoi d'un ICMP redirect provoquant la création d'une route d'hôte sur la machine source. Et rebelote, c'est reparti pour un tour. Le suivi de connexion TCP des noyaux 2.6 "récents" (2.6.9 et plus) pouvant être assez susceptible, ce risque n'est pas négligeable.
Là, oui, c'est vrai que ça fait un peu bazar, du coup.
Enfin, seulement pour ceux qui gèrent les paquets ICMP en question, ce qui n'a l'air d'être le cas que pour l'iBook.
Alors l'avantage d'alléger la charge de routage du serveur ne s'applique qu'à l'iBook. Si les autres machines ignorent l'ICMP redirect, elles envoient tout leur trafic sortant au serveur.
Avec un routage bancal comme celui que tu as mis en place
Bancal.. Rhô, j'irais pas jusque là. Il est très bien, mon routage. Je le trouve très propre.
Au contraire, il est dégueulasse. Un routeur à une patte, c'est forcément une solution bancale, sans jeu de mots.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
Exemple (en gros) :
=== named.conf == acl lan-v4 { 192.168.1.0/24; }; // reseau local IPv4 acl lan-v6 { 2a01:e35:2f56:5590::/64; ::1; }; // reseau local IPv6 acl lan { lan-v4; lan-v6; }; // reseau local IPv4+IPv6
hiegel.fr. A 82.245.101.89 [+autres enregistrements spécifiques à la vue externe]
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et DNS sont plutôt en charte dans fr.comp.reseaux.ip.]
Hugues
Plop,
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
D'autant que je suis le premier à reprendre d'autres sur les abus de langage..
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
Exemple (en gros) : [TRES INTERESSANT]
Merci beaucoup, je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf, je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et DNS sont plutôt en charte dans fr.comp.reseaux.ip.]
Ah, peut être. Je ne suis pas abonné à tous les NG et je ne pense pas toujours à parcourir la hiérarchie quand il s'agit d'une déviation d'une question de base.. mea culpa.
Bref, merci infiniment pour tes éclaircissements, je vais pouvoir me débrouiller avec tout ça ! -- Hugues
Plop,
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le
trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP
d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner
"l'ensemble des IP qui me seront fournies par mon serveur DNS sur
l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
D'autant que je suis le premier à reprendre d'autres sur les abus de langage..
PS : Pour ta question concernant BIND, dans le named.conf il faut
créer deux vues (views), une internet et une externe en fonction de
l'adresse source de la requête, définissant chacune une version
différente de la zone. Accessoirement tu peux en profiter pour
désactiver la récursion pour la vue externe, parce que là ton serveur
répond à des requêtes extérieures pour des domaines autres que ceux
pour lesquels il fait autorité. Et mettre la zone interne uniquement
dans la zone interne.
Exemple (en gros) :
[TRES INTERESSANT]
Merci beaucoup,
je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf,
je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis
pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil
parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et
DNS sont plutôt en charte dans fr.comp.reseaux.ip.]
Ah, peut être. Je ne suis pas abonné à tous les NG et je ne pense pas
toujours à parcourir la hiérarchie quand il s'agit d'une déviation
d'une question de base.. mea culpa.
Bref, merci infiniment pour tes éclaircissements, je vais pouvoir me
débrouiller avec tout ça !
--
Hugues
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Façon de parler. D'autant plus que hiegel.fr n'est qu'une adresse IP d'hôte, et pas de réseau. Mais c'est une façon de parler pour désigner "l'ensemble des IP qui me seront fournies par mon serveur DNS sur l'ensemble du domaine .hiegel.fr".
Façon de parler impropre, c'est bien ce que je reproche.
D'autant que je suis le premier à reprendre d'autres sur les abus de langage..
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
Exemple (en gros) : [TRES INTERESSANT]
Merci beaucoup, je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf, je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
[Je ne réponds pas dans fco.unix car je ne lis pas ce forum (je ne lis pas fco.mac-os.x non plus, mais j'ai fait une exception pour ce fil parce qu'il y a du Linux) et je ne vois pas trop le rapport, BIND et DNS sont plutôt en charte dans fr.comp.reseaux.ip.]
Ah, peut être. Je ne suis pas abonné à tous les NG et je ne pense pas toujours à parcourir la hiérarchie quand il s'agit d'une déviation d'une question de base.. mea culpa.
Bref, merci infiniment pour tes éclaircissements, je vais pouvoir me débrouiller avec tout ça ! -- Hugues
Pascal Hambourg
Hugues a écrit :
Ce cher Pascal Hambourg a dit :
Hugues a écrit :
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Tiens, je vais enfoncer le clou encore un peu plus. Cette topologie crée un routage asymétrique : - chemin sortant : poste -> serveur -> freebox -> extérieur - chemin entrant : extérieur -> freebox -> poste
Contrairement au trafic sortant, le trafic entrant ne passe pas par le serveur. Or le suivi de connexion ne fait pas du tout bon ménage avec le routage asymétrique car il a besoin de voir passer tous les paquets, dans les deux sens. Le risque qu'un paquet soit classé à tort dans l'état INVALID, parce qu'il répond à un paquet qui n'a pas été vu, est donc grand.
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de
^^^^^^^^ Correction : une [vue] *interne*
l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
^^^^ Correction : la *vue* interne
je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf,
Je ne crois pas qu'il y a de vue définie dans le named.conf par défaut.
je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
Pas besoin normalement, BIND 9 supporte les vues depuis longtemps.
Hugues a écrit :
Ce cher Pascal Hambourg <boite-a-spam@plouf.fr.eu.org> a dit :
Hugues a écrit :
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le
trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Tiens, je vais enfoncer le clou encore un peu plus.
Cette topologie crée un routage asymétrique :
- chemin sortant : poste -> serveur -> freebox -> extérieur
- chemin entrant : extérieur -> freebox -> poste
Contrairement au trafic sortant, le trafic entrant ne passe pas par le
serveur. Or le suivi de connexion ne fait pas du tout bon ménage avec le
routage asymétrique car il a besoin de voir passer tous les paquets,
dans les deux sens. Le risque qu'un paquet soit classé à tort dans
l'état INVALID, parce qu'il répond à un paquet qui n'a pas été vu, est
donc grand.
PS : Pour ta question concernant BIND, dans le named.conf il faut
créer deux vues (views), une internet et une externe en fonction de
^^^^^^^^
Correction : une [vue] *interne*
l'adresse source de la requête, définissant chacune une version
différente de la zone. Accessoirement tu peux en profiter pour
désactiver la récursion pour la vue externe, parce que là ton serveur
répond à des requêtes extérieures pour des domaines autres que ceux
pour lesquels il fait autorité. Et mettre la zone interne uniquement
dans la zone interne.
^^^^
Correction : la *vue* interne
je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf,
Je ne crois pas qu'il y a de vue définie dans le named.conf par défaut.
je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
Pas besoin normalement, BIND 9 supporte les vues depuis longtemps.
Et comment ça qu'il a qu'une patte, mon routeur ? :)
Ton serveur n'a qu'une interface par laquelle entre et ressort le trafic routé. D'un point de vue topologique c'est un non-sens.
Vu comme ça, c'est complètement vrai.
Tiens, je vais enfoncer le clou encore un peu plus. Cette topologie crée un routage asymétrique : - chemin sortant : poste -> serveur -> freebox -> extérieur - chemin entrant : extérieur -> freebox -> poste
Contrairement au trafic sortant, le trafic entrant ne passe pas par le serveur. Or le suivi de connexion ne fait pas du tout bon ménage avec le routage asymétrique car il a besoin de voir passer tous les paquets, dans les deux sens. Le risque qu'un paquet soit classé à tort dans l'état INVALID, parce qu'il répond à un paquet qui n'a pas été vu, est donc grand.
PS : Pour ta question concernant BIND, dans le named.conf il faut créer deux vues (views), une internet et une externe en fonction de
^^^^^^^^ Correction : une [vue] *interne*
l'adresse source de la requête, définissant chacune une version différente de la zone. Accessoirement tu peux en profiter pour désactiver la récursion pour la vue externe, parce que là ton serveur répond à des requêtes extérieures pour des domaines autres que ceux pour lesquels il fait autorité. Et mettre la zone interne uniquement dans la zone interne.
^^^^ Correction : la *vue* interne
je n'avais pas capté, ni remarqué ce "view" dans mon man named.conf,
Je ne crois pas qu'il y a de vue définie dans le named.conf par défaut.
je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.
Pas besoin normalement, BIND 9 supporte les vues depuis longtemps.
