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 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
Une seule règle, un '/etc/init.d/iptables save active' à faire et hop. Je ne vois pas la difficulté.
- toutes les machines du réseaux local à configurer (avec des bugs si ça change...)
Heu. je ne vois pas le rapport, j'ai justement configuré mon réseau suite à l'installation dans mon nouvel appart avec ma freebox.
et changer une route sur une machine, ce n'est pas très compliqué à faire..
- une dépendance au serveur central
de toutes façons pour le DNS il y a une dépendance. donc que ce serveur fasse routeur ou pas le problème est le même !! alors autant profiter de la souplesse et de la puissance de configuration de mon serveur en tant que routeur...
et la simlification de la configuration réseau : une seule @IP pour les services routeur et DNS, c'est y pas beau ?
- des performances réseaux moins bonnes
Mouais, je n'ai vraiment pas observé de perf "pas terribles". :) et pour une utilisation en perso.... comment dire.. :)
Je me demande si on a vraiment la même conception de la simplicité. ;-)
ça dépend de comment on utilise le réseau :-) En fait pour moi la différence entre les deux c'est :
dans votre cas : - une freebox routeur - un pc DNS (donc dépendance au réseau local) sinon c'est un DNS externe, avec les adresses qui changent, impossibles à retenir et qu'il faut aller chercher à chaque fois qu'on configure une nouvelle machine... Pas terrible.
dans mon cas : - une freebox routeur configurée au minimum - un pc DNS et officiellement routeur, qui se charge également de DNAT-er les paquets qui vont bien.
du côté des clients, on a toujours la dépendance au serveur, mais au moins la configuration y est beaucoup plus simple.
Je suis comme ça : je préfère regrouper les configurations compliquées et configurer le reste simplement. C'est exactement ce que j'ai fait.
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
Ah bah voilà, enfin un point d'accord ;)
-- Hugues
Ce cher Paul Gaborit <Paul.Gaborit@invalid.invalid> a dit :
À (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
Une seule règle, un '/etc/init.d/iptables save active' à faire et hop.
Je ne vois pas la difficulté.
- toutes les machines du réseaux local à configurer
(avec des bugs si ça change...)
Heu. je ne vois pas le rapport, j'ai justement configuré mon réseau
suite à l'installation dans mon nouvel appart avec ma freebox.
et changer une route sur une machine, ce n'est pas très compliqué à faire..
- une dépendance au serveur central
de toutes façons pour le DNS il y a une dépendance. donc que ce
serveur fasse routeur ou pas le problème est le même !! alors autant
profiter de la souplesse et de la puissance de configuration de mon
serveur en tant que routeur...
et la simlification de la configuration réseau : une seule @IP pour
les services routeur et DNS, c'est y pas beau ?
- des performances réseaux moins bonnes
Mouais, je n'ai vraiment pas observé de perf "pas terribles". :)
et pour une utilisation en perso.... comment dire.. :)
Je me demande si on a vraiment la même conception de la
simplicité. ;-)
ça dépend de comment on utilise le réseau :-)
En fait pour moi la différence entre les deux c'est :
dans votre cas :
- une freebox routeur
- un pc DNS (donc dépendance au réseau local)
sinon c'est un DNS externe, avec les adresses qui changent,
impossibles à retenir et qu'il faut aller chercher à chaque fois qu'on
configure une nouvelle machine... Pas terrible.
dans mon cas :
- une freebox routeur configurée au minimum
- un pc DNS et officiellement routeur, qui se charge également de
DNAT-er les paquets qui vont bien.
du côté des clients, on a toujours la dépendance au serveur, mais au
moins la configuration y est beaucoup plus simple.
Je suis comme ça : je préfère regrouper les configurations compliquées
et configurer le reste simplement. C'est exactement ce que j'ai fait.
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
À (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
Une seule règle, un '/etc/init.d/iptables save active' à faire et hop. Je ne vois pas la difficulté.
- toutes les machines du réseaux local à configurer (avec des bugs si ça change...)
Heu. je ne vois pas le rapport, j'ai justement configuré mon réseau suite à l'installation dans mon nouvel appart avec ma freebox.
et changer une route sur une machine, ce n'est pas très compliqué à faire..
- une dépendance au serveur central
de toutes façons pour le DNS il y a une dépendance. donc que ce serveur fasse routeur ou pas le problème est le même !! alors autant profiter de la souplesse et de la puissance de configuration de mon serveur en tant que routeur...
et la simlification de la configuration réseau : une seule @IP pour les services routeur et DNS, c'est y pas beau ?
- des performances réseaux moins bonnes
Mouais, je n'ai vraiment pas observé de perf "pas terribles". :) et pour une utilisation en perso.... comment dire.. :)
Je me demande si on a vraiment la même conception de la simplicité. ;-)
ça dépend de comment on utilise le réseau :-) En fait pour moi la différence entre les deux c'est :
dans votre cas : - une freebox routeur - un pc DNS (donc dépendance au réseau local) sinon c'est un DNS externe, avec les adresses qui changent, impossibles à retenir et qu'il faut aller chercher à chaque fois qu'on configure une nouvelle machine... Pas terrible.
dans mon cas : - une freebox routeur configurée au minimum - un pc DNS et officiellement routeur, qui se charge également de DNAT-er les paquets qui vont bien.
du côté des clients, on a toujours la dépendance au serveur, mais au moins la configuration y est beaucoup plus simple.
Je suis comme ça : je préfère regrouper les configurations compliquées et configurer le reste simplement. C'est exactement ce que j'ai fait.
et ça me permet d'avoir une même base en interne et externe.
Oui, vous avez raison, le serveur DNS est plus simple. ;-)
Ah bah voilà, enfin un point d'accord ;)
-- Hugues
SAM
Le 10/17/08 11:26 AM, Hugues a écrit :
Hoï,
Tchack,
zap de l'imbroglio (je réponds à une question en pensant à autre chose)
qui en plus mênent à des "distribs" de 20 CD ...
pas obligé de les prendre. tu as des versions DVD,
Pas mieux, ça fait un poids énorme à charger.
reste tout simplement la "netinstall" :
Non, non, je ne veux rien installer (j'ai déjà assez pourri mon DD avec des trucs "pour voir" dont je ne sais plus me défaire)
Tu peux très bien essayer une Ubuntu, ils font des Live-CD.
Ha! Voilà.
j'ai fini par revenir à une Debian, question de goût.
comme c'est juste pour "voir" et que
(et actuellement je n'ai gardé que MacOSX,
Bon! Pour revenir à tes moutons,
Je ne suis quand même pas aussi newb que ça :-)
Bof! une fôte d'inattention ça arrive.
Je le répète : toutes les IP sont configurées à la main. et j'ai bien vérifier en éteignant le Dell et les autres machines, ça ne marche toujours pas. J'ai bien comparé les IP, ça ne marche pas.
Ce serveur il fonctionne en DHCP ? Moi j'essaierais en mettant tout en automatique sur l'iBook. Préférences Système / Reseau / Airport / - onglet Airport : connection Automatique - onglet TCP/IP : - IPv4 : via DHCP - IPv6 : Automatique - PPPoE, AppleTalk, Proxys : tous vides et cliquoter tout ce qui ressemble à "par défaut"
avant de forcer des IP manuellement et d'aller bidouiller du Terminal.
Depuis mon Dell ou depuis mon serveur, si je fais un ssh sur mon ibook, ça marche. Inversement aussi. Depuis mon ibook, le réseau web marche, la seule chose qui ne fonctionne pas, c'est le DNAT vers mon serveur web.... et il n'y a que mon ibook qui soit concerné.
Vérifier que l'IP de l'iBook ne soit pas une de celles gérées par la FB.
Le 10/17/08 11:26 AM, Hugues a écrit :
Hoï,
Tchack,
zap de l'imbroglio (je réponds à une question en pensant à autre chose)
qui en plus mênent à des "distribs" de 20 CD ...
pas obligé de les prendre. tu as des versions DVD,
Pas mieux, ça fait un poids énorme à charger.
reste tout simplement la "netinstall" :
Non, non, je ne veux rien installer (j'ai déjà assez pourri mon DD avec
des trucs "pour voir" dont je ne sais plus me défaire)
Tu peux très bien essayer une Ubuntu, ils font des Live-CD.
Ha! Voilà.
j'ai fini par revenir à une Debian, question de goût.
comme c'est juste pour "voir" et que
(et actuellement je n'ai gardé que MacOSX,
Bon! Pour revenir à tes moutons,
Je ne suis quand même pas aussi newb que ça :-)
Bof! une fôte d'inattention ça arrive.
Je le répète : toutes les IP sont configurées à la main. et j'ai bien
vérifier en éteignant le Dell et les autres machines, ça ne marche
toujours pas. J'ai bien comparé les IP, ça ne marche pas.
Ce serveur il fonctionne en DHCP ?
Moi j'essaierais en mettant tout en automatique sur l'iBook.
Préférences Système / Reseau / Airport /
- onglet Airport : connection Automatique
- onglet TCP/IP :
- IPv4 : via DHCP
- IPv6 : Automatique
- PPPoE, AppleTalk, Proxys : tous vides
et cliquoter tout ce qui ressemble à "par défaut"
avant de forcer des IP manuellement et d'aller bidouiller du Terminal.
Depuis mon Dell ou depuis mon serveur, si je fais un ssh sur mon
ibook, ça marche. Inversement aussi. Depuis mon ibook, le réseau web
marche, la seule chose qui ne fonctionne pas, c'est le DNAT vers mon
serveur web.... et il n'y a que mon ibook qui soit concerné.
Vérifier que l'IP de l'iBook ne soit pas une de celles gérées par la FB.
zap de l'imbroglio (je réponds à une question en pensant à autre chose)
qui en plus mênent à des "distribs" de 20 CD ...
pas obligé de les prendre. tu as des versions DVD,
Pas mieux, ça fait un poids énorme à charger.
reste tout simplement la "netinstall" :
Non, non, je ne veux rien installer (j'ai déjà assez pourri mon DD avec des trucs "pour voir" dont je ne sais plus me défaire)
Tu peux très bien essayer une Ubuntu, ils font des Live-CD.
Ha! Voilà.
j'ai fini par revenir à une Debian, question de goût.
comme c'est juste pour "voir" et que
(et actuellement je n'ai gardé que MacOSX,
Bon! Pour revenir à tes moutons,
Je ne suis quand même pas aussi newb que ça :-)
Bof! une fôte d'inattention ça arrive.
Je le répète : toutes les IP sont configurées à la main. et j'ai bien vérifier en éteignant le Dell et les autres machines, ça ne marche toujours pas. J'ai bien comparé les IP, ça ne marche pas.
Ce serveur il fonctionne en DHCP ? Moi j'essaierais en mettant tout en automatique sur l'iBook. Préférences Système / Reseau / Airport / - onglet Airport : connection Automatique - onglet TCP/IP : - IPv4 : via DHCP - IPv6 : Automatique - PPPoE, AppleTalk, Proxys : tous vides et cliquoter tout ce qui ressemble à "par défaut"
avant de forcer des IP manuellement et d'aller bidouiller du Terminal.
Depuis mon Dell ou depuis mon serveur, si je fais un ssh sur mon ibook, ça marche. Inversement aussi. Depuis mon ibook, le réseau web marche, la seule chose qui ne fonctionne pas, c'est le DNAT vers mon serveur web.... et il n'y a que mon ibook qui soit concerné.
Vérifier que l'IP de l'iBook ne soit pas une de celles gérées par la FB.
SAM
Le 10/17/08 11:58 AM, Hugues a écrit :
Ce cher Hugues a dit :
Mais voici ce que j'ai fait :
Boudiou ! Ces Linuxiens tant qu'ils n'ont pas tapoté tout un tas de charabias dans une console y sont pas satisfaits !
:-)
Question subsidiaire : comment fait-on pour afficher l'ensemble de la table de routage sur MacOSX avec le Terminal ??
et l'Utilitaire (Pomme+Maj+U): "Utilitaire de Réseau" ?
-- sm
Le 10/17/08 11:58 AM, Hugues a écrit :
Ce cher Hugues <hiegel@hugues.fr> a dit :
Mais voici ce que j'ai fait :
Boudiou !
Ces Linuxiens tant qu'ils n'ont pas tapoté tout un tas de charabias dans
une console y sont pas satisfaits !
:-)
Question subsidiaire : comment fait-on pour afficher l'ensemble de la
table de routage sur MacOSX avec le Terminal ??
et l'Utilitaire (Pomme+Maj+U): "Utilitaire de Réseau" ?
Boudiou ! Ces Linuxiens tant qu'ils n'ont pas tapoté tout un tas de charabias dans une console y sont pas satisfaits !
:-)
Question subsidiaire : comment fait-on pour afficher l'ensemble de la table de routage sur MacOSX avec le Terminal ??
et l'Utilitaire (Pomme+Maj+U): "Utilitaire de Réseau" ?
-- sm
Pascal Hambourg
Salut,
Xavier a écrit :
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-------------
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse privée dans la vue interne.
-------- 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-------------
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.
Salut,
Xavier a écrit :
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-------------
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse
privée dans la vue interne.
-------- 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-------------
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.
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-------------
C'est l'inverse ! L'adresse publique dans la vue externe et l'adresse privée dans la vue interne.
-------- 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-------------
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.
Pascal Hambourg
Hugues a écrit :
j'ai regardé de plus près cette commande "route" sur macosx, c'est une vraie merde, car je n'ai pas trouvé moyen d'afficher toutes les routes.
Je ne connais pas MacOS X, mais il m'est arrivé de tomber sur des Unix dont la commande 'route' ne permettait pas d'afficher la table de routage. Dans ce cas j'utilise "netstat -rn".
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.
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.
Hugues a écrit :
j'ai regardé de plus près cette commande "route" sur macosx,
c'est une vraie merde, car je n'ai pas trouvé moyen d'afficher toutes
les routes.
Je ne connais pas MacOS X, mais il m'est arrivé de tomber sur des Unix
dont la commande 'route' ne permettait pas d'afficher la table de
routage. Dans ce cas j'utilise "netstat -rn".
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.
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.
j'ai regardé de plus près cette commande "route" sur macosx, c'est une vraie merde, car je n'ai pas trouvé moyen d'afficher toutes les routes.
Je ne connais pas MacOS X, mais il m'est arrivé de tomber sur des Unix dont la commande 'route' ne permettait pas d'afficher la table de routage. Dans ce cas j'utilise "netstat -rn".
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.
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.
Pascal Hambourg
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.
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Avec un routage bancal comme celui que tu as mis en place, il ne faut pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues dans BIND. Pour l'éviter, un solution consiste à bloquer l'envoi des ICMP Redirect par le serveur avec une règle iptables. Mais on perd l'avantage mentionné ci-dessus.
iptables -A OUTPUT -p icmp --icmp-type redirect -j DROP
Et visiblement c'était persistant après un reboot...
Ça, par contre, ça me surprend.
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.
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Avec un routage bancal comme celui que tu as mis en place, il ne faut
pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues
dans BIND. Pour l'éviter, un solution consiste à bloquer l'envoi des
ICMP Redirect par le serveur avec une règle iptables. Mais on perd
l'avantage mentionné ci-dessus.
iptables -A OUTPUT -p icmp --icmp-type redirect -j DROP
Et visiblement c'était persistant après un reboot...
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.
L'avantage, c'est que ça donne moins de travail de routage au serveur.
Avec un routage bancal comme celui que tu as mis en place, il ne faut pas s'étonner de ce genre de désagréments. Moi j'aurais fait des vues dans BIND. Pour l'éviter, un solution consiste à bloquer l'envoi des ICMP Redirect par le serveur avec une règle iptables. Mais on perd l'avantage mentionné ci-dessus.
iptables -A OUTPUT -p icmp --icmp-type redirect -j DROP
Et visiblement c'était persistant après un reboot...
Ça, par contre, ça me surprend.
Pascal Hambourg
Pascal Hambourg a écrit :
Pour l'éviter, un solution consiste à bloquer l'envoi des ICMP Redirect par le serveur avec une règle iptables.
Edit: une alternative plus propre consiste à purement désactiver l'envoi de ce type ICMP sur l'interface LAN :
Il faut les deux à 0 pour désactiver, c'est un OU logique. A mettre dans /etc/sysctl.conf pour l'automatiser au démarrage.
PS: dans ton cas une alternative à DNAT est la cible REDIRECT, qui redirige implicitement vers l'adresse de l'interface d'entrée et qu'on utilise donc pour rediriger vers soi-même, notamment pour faire un proxy transparent. On utilise plutôt DNAT pour rediriger vers une autre machine.
Pascal Hambourg a écrit :
Pour l'éviter, un solution consiste à bloquer l'envoi des
ICMP Redirect par le serveur avec une règle iptables.
Edit: une alternative plus propre consiste à purement désactiver l'envoi
de ce type ICMP sur l'interface LAN :
Il faut les deux à 0 pour désactiver, c'est un OU logique.
A mettre dans /etc/sysctl.conf pour l'automatiser au démarrage.
PS: dans ton cas une alternative à DNAT est la cible REDIRECT, qui
redirige implicitement vers l'adresse de l'interface d'entrée et qu'on
utilise donc pour rediriger vers soi-même, notamment pour faire un proxy
transparent. On utilise plutôt DNAT pour rediriger vers une autre machine.
Il faut les deux à 0 pour désactiver, c'est un OU logique. A mettre dans /etc/sysctl.conf pour l'automatiser au démarrage.
PS: dans ton cas une alternative à DNAT est la cible REDIRECT, qui redirige implicitement vers l'adresse de l'interface d'entrée et qu'on utilise donc pour rediriger vers soi-même, notamment pour faire un proxy transparent. On utilise plutôt DNAT pour rediriger vers une autre machine.
xavier
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...
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 :
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...
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 :
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...
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 :
-- 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
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 autre chose :
je veux que www.hiegel.fr donne "192.168.1.1" vu de l'intérieur, mais "88.xx.yy.zz" si c'est demandé depuis l'extérieur. Et je ne comprends pas trop comment configurer mon named.conf(.local, mais c'est un détail) dans mon 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 autre chose :
je veux que www.hiegel.fr donne "192.168.1.1" vu de l'intérieur, mais
"88.xx.yy.zz" si c'est demandé depuis l'extérieur. Et je ne comprends
pas trop comment configurer mon named.conf(.local, mais c'est un
détail) dans mon 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 autre chose :
je veux que www.hiegel.fr donne "192.168.1.1" vu de l'intérieur, mais "88.xx.yy.zz" si c'est demandé depuis l'extérieur. Et je ne comprends pas trop comment configurer mon named.conf(.local, mais c'est un détail) dans mon 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...
-- Hugues
Hugues
Ce cher SAM a dit :
Le 10/17/08 11:58 AM, Hugues a écrit :
Ce cher Hugues a dit :
Mais voici ce que j'ai fait :
Boudiou ! Ces Linuxiens tant qu'ils n'ont pas tapoté tout un tas de charabias dans une console y sont pas satisfaits !
:-)
Nous n'avons pas la même conception de l'informatique ;)
En fait, le fait de taper les commandes en console permet de faire beaucoup plus de choses... Bref ;)
Question subsidiaire : comment fait-on pour afficher l'ensemble de la table de routage sur MacOSX avec le Terminal ??
et l'Utilitaire (Pomme+Maj+U): "Utilitaire de Réseau" ?
J'y accède comment ? Je suis en SSH depuis mon boulot.. :)
Mais j'ai eu ma réponse : netstat -rn
-- Hugues
Ce cher SAM <stephanemoriaux.NoAdmin@wanadoo.fr.invalid> a dit :
Le 10/17/08 11:58 AM, Hugues a écrit :
Ce cher Hugues <hiegel@hugues.fr> a dit :
Mais voici ce que j'ai fait :
Boudiou !
Ces Linuxiens tant qu'ils n'ont pas tapoté tout un tas de charabias
dans une console y sont pas satisfaits !
:-)
Nous n'avons pas la même conception de l'informatique ;)
En fait, le fait de taper les commandes en console permet
de faire beaucoup plus de choses... Bref ;)
Question subsidiaire : comment fait-on pour afficher l'ensemble de la
table de routage sur MacOSX avec le Terminal ??
et l'Utilitaire (Pomme+Maj+U): "Utilitaire de Réseau" ?
J'y accède comment ? Je suis en SSH depuis mon boulot.. :)
