Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Problème de routage MacOSX -> Linux

43 réponses
Avatar
Hugues
Bonjour à tous,

Fu2 fr.comp.os.mac-os.x

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 !?


ma config ibook:
réseau wifi configuré avec ip manuelle, ethernet désactivé.
$ ifconfig en1
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet6 fe80::211:24ff:fea8:54e8%en1 prefixlen 64 scopeid 0x5
inet 192.168.1.27 netmask 0xffffff00 broadcast 192.168.1.255
inet6 2a01:e35:2f56:5590:211:24ff:fea8:54e8 prefixlen 64
autoconf
ether 00:11:24:a8:54:e8
media: autoselect status: active
supported media: autoselect
$ cat /etc/resolv.conf
nameserver 192.168.1.1
search sweethome

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

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (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...

--
Hugues

3 réponses

1 2 3 4 5
Avatar
Hugues
Ce cher Pascal Hambourg a dit :

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.



Ah oui, là, tu m'as carrément convaincu.

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*



C'est ce que j'avais lu :-)

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.



Ok j'ai compris. Sur ma debian : bind != bind9 .

--
Hugues
Avatar
Pascal Hambourg
Hugues a écrit :
Ce cher Pascal Hambourg a dit :

Hugues a écrit :

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.





Au temps pour moi, je n'avais pas vu que tu parlais du man.

je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.


Pas besoin normalement, BIND 9 supporte les vues depuis longtemps.



Ok j'ai compris. Sur ma debian : bind != bind9 .



Effectivement, dans Debian le paquet bind installe BIND 8, obsolète
depuis longtemps et non corrigeable contre la faille de "DNS poisoning"
qui a fait grand bruit il y a quelque temps, cf.
<http://www.fr.debian.org/security/2008/dsa-1604>. Il est d'autant plus
important d'interdire la récursion depuis l'extérieur.

Mais n'avais-tu pas répondu à Xavier dans l'article
du 17 à 16h12 que tu avais BIND 9 ?
Avatar
Hugues
Ce cher Pascal Hambourg a dit :

Hugues a écrit :
Ce cher Pascal Hambourg a dit :

Hugues a écrit :

je jetterai un oeil plus attentif ! Et si besoin, mettre à jour mon bind.


Pas besoin normalement, BIND 9 supporte les vues depuis longtemps.



Ok j'ai compris. Sur ma debian : bind != bind9 .



Effectivement, dans Debian le paquet bind installe BIND 8, obsolète
depuis longtemps et non corrigeable contre la faille de "DNS
poisoning" qui a fait grand bruit il y a quelque temps,



Ah ok, voilà qui est une bonne chose :)

Mais n'avais-tu pas répondu à Xavier dans l'article
du 17 à 16h12 que tu avais BIND 9
?



Je le croyais.

Bon ben c'est bon, j'ai tout reconfiguré mon bind9 :-)

Encore merci pour tes interventions de qualité ! :-)


Juste un petit détail qui me lourde, mais vraiment un détail. Et ça
aura plus sa place sur fr.comp.réseaux.ip si j'ai bien compris. ;)
Bref, peut être un thread à venir là-bas, d'ici qques jours...

--
Hugues
1 2 3 4 5