Bonjour,
je suis en train de galérer sur mon réseau local pour faire fonctionner en
harmonie ma passerelle connectée par adsl avec mes postes clients. Ça ne
fonctionne jamais dans son entier :(
Je vous ai fait un petit schéma:
+------------+ eth0 +------------+ eth1 +--------+
internet --| modem adsl |---------| passerelle |--------| switch |
| (eth) | | SS20 | +---+----+
+------------+ | (falbala) | |
+------------+ | +--------+
+--+ obelix |
| +--------+
Les postes : |
- falbala : 2.4.26-sparc32-smp Debian | +--------+
sur eth0 : 192.168.1.5 / 255.255.255.0 +--+ asterix|
sur eth1 : 192.168.0.1 / 255.255.255.0 | +--------+
- obelix : pécé 2.4.22-xfs (ou winXP mais pas encore testé) |
Debian
192.168.0.10 |
- idefix : pécé win98
192.168.0.20
eth0 sur falbala a une adresse pour pouvoir "attaquer" l'outil de
diagnostic interne du modem en 192.168.1.1
[....]
Bonjour,
je suis en train de galérer sur mon réseau local pour faire fonctionner en
harmonie ma passerelle connectée par adsl avec mes postes clients. Ça ne
fonctionne jamais dans son entier :(
Je vous ai fait un petit schéma:
+------------+ eth0 +------------+ eth1 +--------+
internet --| modem adsl |---------| passerelle |--------| switch |
| (eth) | | SS20 | +---+----+
+------------+ | (falbala) | |
+------------+ | +--------+
+--+ obelix |
| +--------+
Les postes : |
- falbala : 2.4.26-sparc32-smp Debian | +--------+
sur eth0 : 192.168.1.5 / 255.255.255.0 +--+ asterix|
sur eth1 : 192.168.0.1 / 255.255.255.0 | +--------+
- obelix : pécé 2.4.22-xfs (ou winXP mais pas encore testé) |
Debian
192.168.0.10 |
- idefix : pécé win98
192.168.0.20
eth0 sur falbala a une adresse pour pouvoir "attaquer" l'outil de
diagnostic interne du modem en 192.168.1.1
[....]
Bonjour,
je suis en train de galérer sur mon réseau local pour faire fonctionner en
harmonie ma passerelle connectée par adsl avec mes postes clients. Ça ne
fonctionne jamais dans son entier :(
Je vous ai fait un petit schéma:
+------------+ eth0 +------------+ eth1 +--------+
internet --| modem adsl |---------| passerelle |--------| switch |
| (eth) | | SS20 | +---+----+
+------------+ | (falbala) | |
+------------+ | +--------+
+--+ obelix |
| +--------+
Les postes : |
- falbala : 2.4.26-sparc32-smp Debian | +--------+
sur eth0 : 192.168.1.5 / 255.255.255.0 +--+ asterix|
sur eth1 : 192.168.0.1 / 255.255.255.0 | +--------+
- obelix : pécé 2.4.22-xfs (ou winXP mais pas encore testé) |
Debian
192.168.0.10 |
- idefix : pécé win98
192.168.0.20
eth0 sur falbala a une adresse pour pouvoir "attaquer" l'outil de
diagnostic interne du modem en 192.168.1.1
[....]
j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
attention ce n'est pas une attaque :-)
j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
attention ce n'est pas une attaque :-)
j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
attention ce n'est pas une attaque :-)
On 7 mai 2004, wrote:j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
Ben pourtant... :(
J'ai essayé d'expliquer :
- ce que je veux
- ce que j'ai essayé
- ce que j'ai obtenu
Bon trop détaillé peut-être ? Quoiqu'il manque le fichier de paramétrage
dnsmasq et celui d'iptables, mais ça risquait de faire plus long ;)attention ce n'est pas une attaque :-)
No problémo. Je préfère savoir que je me suis peut-être mal exprimé plutôt
que ne pas avoir de réponse.
Mais alors comment dire ?
- J'utilise dnsmasq et resolvconf sur une connexion adsl via modem ethernet
(pppoe)
- la machine connecté est la passerelle+firewall d'un réseau local(cf
message original pour les détails) et est serveur dns/dhcp/wins pour ce
réseau - les postes clients fonctionnent correctement
- mais la passerelle ne résout pas correctement les adresses des postes
clients
Et donc je cherche à paramétrer correctement tout ça sur une Debian.
Comme ça c'est plus concis ?
Sébastien Kirche
On 7 mai 2004, francois.dimo@hotmail.coml wrote:
j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
Ben pourtant... :(
J'ai essayé d'expliquer :
- ce que je veux
- ce que j'ai essayé
- ce que j'ai obtenu
Bon trop détaillé peut-être ? Quoiqu'il manque le fichier de paramétrage
dnsmasq et celui d'iptables, mais ça risquait de faire plus long ;)
attention ce n'est pas une attaque :-)
No problémo. Je préfère savoir que je me suis peut-être mal exprimé plutôt
que ne pas avoir de réponse.
Mais alors comment dire ?
- J'utilise dnsmasq et resolvconf sur une connexion adsl via modem ethernet
(pppoe)
- la machine connecté est la passerelle+firewall d'un réseau local(cf
message original pour les détails) et est serveur dns/dhcp/wins pour ce
réseau - les postes clients fonctionnent correctement
- mais la passerelle ne résout pas correctement les adresses des postes
clients
Et donc je cherche à paramétrer correctement tout ça sur une Debian.
Comme ça c'est plus concis ?
Sébastien Kirche
On 7 mai 2004, wrote:j'aurais pris plaisir à t'aider , mais la on dirai vraiment un exercice
(ça fait un bout de temps que je n'en ai pas vu .... ) , essai d'être
un peu plus précis et conscis , franchement j'ai eu du mal à lire
jusqu'au bout .
Ben pourtant... :(
J'ai essayé d'expliquer :
- ce que je veux
- ce que j'ai essayé
- ce que j'ai obtenu
Bon trop détaillé peut-être ? Quoiqu'il manque le fichier de paramétrage
dnsmasq et celui d'iptables, mais ça risquait de faire plus long ;)attention ce n'est pas une attaque :-)
No problémo. Je préfère savoir que je me suis peut-être mal exprimé plutôt
que ne pas avoir de réponse.
Mais alors comment dire ?
- J'utilise dnsmasq et resolvconf sur une connexion adsl via modem ethernet
(pppoe)
- la machine connecté est la passerelle+firewall d'un réseau local(cf
message original pour les détails) et est serveur dns/dhcp/wins pour ce
réseau - les postes clients fonctionnent correctement
- mais la passerelle ne résout pas correctement les adresses des postes
clients
Et donc je cherche à paramétrer correctement tout ça sur une Debian.
Comme ça c'est plus concis ?
Sébastien Kirche
Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient de là ?
Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient de là ?
Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient de là ?
françois wrote:>Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient
de là ?
En faite , je viens de lire le fil que tu as initié sur lduf
,intéressant ,mais pour ma part je ne vois pas ce que je peut faire de
plus .... :-( .
bon courage et @+ .
ps : ça serai cool de poster le résultat en cas de solution (je n'en
doute pas une seconde)
françois wrote:>
Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient
de là ?
En faite , je viens de lire le fil que tu as initié sur lduf
,intéressant ,mais pour ma part je ne vois pas ce que je peut faire de
plus .... :-( .
bon courage et @+ .
ps : ça serai cool de poster le résultat en cas de solution (je n'en
doute pas une seconde)
françois wrote:>Bonjour,
As tu essayer de désactiver iptable pour voir si le problème vient
de là ?
En faite , je viens de lire le fil que tu as initié sur lduf
,intéressant ,mais pour ma part je ne vois pas ce que je peut faire de
plus .... :-( .
bon courage et @+ .
ps : ça serai cool de poster le résultat en cas de solution (je n'en
doute pas une seconde)
Bonjour,
Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Suivant les essais, elle arrive à résoudre les noms de clients locaux
mais alors les clients n'ont plus de dns externe.
Jusqu'à ce que je commence à gérer des postes clients, la connexion
adsl pppoe s'effectuait automatiquement au démarrage ou via pon/poff.
La config a été faite très simplement avec pppoeconf : login/password,
recherche dur fournisseur et ajout automatique des dns dans
/etc/resolv.conf
Le fichier /etc/network/interfaces était simpliste
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que
la passerelle ne parvenait pas à résoudre les noms locaux et après
essais en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf
le problème semblé réglé.
MAIS : avec la directive usepeerdns du paramétrage pppoe, à
chaque reconnexion, le fichier est recréé pour contenir les dns
tele2 et mon nameserver local est perdu...
Je pourrais certes "patcher" le script
/etc/ppp/ip-up.d/0000userpeerdns pour ajouter le nameserver manquant mais
ça ne me paraît pas très «propre».
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Voilà (ouf) c'est un peu long, mais j'espère avoir été clair.
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script standard.
Merci !
Bonjour,
Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Suivant les essais, elle arrive à résoudre les noms de clients locaux
mais alors les clients n'ont plus de dns externe.
Jusqu'à ce que je commence à gérer des postes clients, la connexion
adsl pppoe s'effectuait automatiquement au démarrage ou via pon/poff.
La config a été faite très simplement avec pppoeconf : login/password,
recherche dur fournisseur et ajout automatique des dns dans
/etc/resolv.conf
Le fichier /etc/network/interfaces était simpliste
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que
la passerelle ne parvenait pas à résoudre les noms locaux et après
essais en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf
le problème semblé réglé.
MAIS : avec la directive usepeerdns du paramétrage pppoe, à
chaque reconnexion, le fichier est recréé pour contenir les dns
tele2 et mon nameserver local est perdu...
Je pourrais certes "patcher" le script
/etc/ppp/ip-up.d/0000userpeerdns pour ajouter le nameserver manquant mais
ça ne me paraît pas très «propre».
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Voilà (ouf) c'est un peu long, mais j'espère avoir été clair.
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script standard.
Merci !
Bonjour,
Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Suivant les essais, elle arrive à résoudre les noms de clients locaux
mais alors les clients n'ont plus de dns externe.
Jusqu'à ce que je commence à gérer des postes clients, la connexion
adsl pppoe s'effectuait automatiquement au démarrage ou via pon/poff.
La config a été faite très simplement avec pppoeconf : login/password,
recherche dur fournisseur et ajout automatique des dns dans
/etc/resolv.conf
Le fichier /etc/network/interfaces était simpliste
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que
la passerelle ne parvenait pas à résoudre les noms locaux et après
essais en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf
le problème semblé réglé.
MAIS : avec la directive usepeerdns du paramétrage pppoe, à
chaque reconnexion, le fichier est recréé pour contenir les dns
tele2 et mon nameserver local est perdu...
Je pourrais certes "patcher" le script
/etc/ppp/ip-up.d/0000userpeerdns pour ajouter le nameserver manquant mais
ça ne me paraît pas très «propre».
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Voilà (ouf) c'est un peu long, mais j'espère avoir été clair.
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script standard.
Merci !
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script
standard.
Supprimer l'option usepeerdns de la configuration pppd.
Créer le fichier /etc/resolv.conf suivant :
domain votredomain.tld
nameserver 127.0.0.1
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script
standard.
Supprimer l'option usepeerdns de la configuration pppd.
Créer le fichier /etc/resolv.conf suivant :
domain votredomain.tld
nameserver 127.0.0.1
Maintenant si quelqu'un a un tuyau à me filer pour régler correctement
ma résolution dns avec le *bon* paramètre qu'il me manque...
Solution que je préférerai à la modification barbare d'un script
standard.
Supprimer l'option usepeerdns de la configuration pppd.
Créer le fichier /etc/resolv.conf suivant :
domain votredomain.tld
nameserver 127.0.0.1
Dans le message <news:,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :Bonjour,
Re bonsoir,
[...]Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
Tu veux dire que la résolution des noms d'hôtes obelix, asterix, etc,
donne l'adresse IP publique ?
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre le
trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement ?
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que la
passerelle ne parvenait pas à résoudre les noms locaux et après essais
en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf le
problème semblé réglé. MAIS : avec la directive usepeerdns du
paramétrage pppoe, à chaque reconnexion, le fichier est recréé pour
contenir les dns tele2 et mon nameserver local est perdu... Je pourrais
certes "patcher" le script /etc/ppp/ip-up.d/0000userpeerdns pour ajouter
le nameserver manquant mais ça ne me paraît pas très «propre».
La solution à ton problème se situe à mon avis au niveau de l'option
usepeerdns. C'est-à-dire qu'il faut utiliser ton serveur DNS pour la
résolution DNS sur ta passerelle aulieu des serveurs DNS de ton FAI. Mais
il ne faut pas patcher le script 0000userpeerdns. Il faut soit supprimer
l'option usepeerdns dans ta configuration pppd (fichier /etc/ppp/options
ou fichier /etc/ppp/peers/adsl) ou soit rendre le fichier 0000userpeerdns
non executable.
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Je ne connaissais pas resolvconf. Après avoir regardé de près ce qu'il
faisait, je trouve que ça ressemble beaucoup à du bricolage. S'il s'agit
de bricoler (dans le bon sens du terme), autant le faire sois-même via un
script maison qu'on placera dans /etc/ppp/ip-up.d. Je te conseille de
désinstaller ce package.
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Dans le message <news:m2wu3o2xle.fsf@free.fr>,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :
Bonjour,
Re bonsoir,
[...]
Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
Tu veux dire que la résolution des noms d'hôtes obelix, asterix, etc,
donne l'adresse IP publique ?
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre le
trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement ?
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que la
passerelle ne parvenait pas à résoudre les noms locaux et après essais
en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf le
problème semblé réglé. MAIS : avec la directive usepeerdns du
paramétrage pppoe, à chaque reconnexion, le fichier est recréé pour
contenir les dns tele2 et mon nameserver local est perdu... Je pourrais
certes "patcher" le script /etc/ppp/ip-up.d/0000userpeerdns pour ajouter
le nameserver manquant mais ça ne me paraît pas très «propre».
La solution à ton problème se situe à mon avis au niveau de l'option
usepeerdns. C'est-à-dire qu'il faut utiliser ton serveur DNS pour la
résolution DNS sur ta passerelle aulieu des serveurs DNS de ton FAI. Mais
il ne faut pas patcher le script 0000userpeerdns. Il faut soit supprimer
l'option usepeerdns dans ta configuration pppd (fichier /etc/ppp/options
ou fichier /etc/ppp/peers/adsl) ou soit rendre le fichier 0000userpeerdns
non executable.
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Je ne connaissais pas resolvconf. Après avoir regardé de près ce qu'il
faisait, je trouve que ça ressemble beaucoup à du bricolage. S'il s'agit
de bricoler (dans le bon sens du terme), autant le faire sois-même via un
script maison qu'on placera dans /etc/ppp/ip-up.d. Je te conseille de
désinstaller ce package.
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Dans le message <news:,
*Sebastien Kirche* tapota sur f.c.o.l.configuration :Bonjour,
Re bonsoir,
[...]Le dns fonctionne partiellement. En l'état :
- la passerelle résoud les adresses extérieures
- les clients arrivent à résoudres les adresses extérieures et les
adressesinternes (p.ex obelix résoud google.fr, falbala et idefix)
- MAIS : la passerelle n'arrive pas à résoudre les noms des clients (!)
qui sont vus comme des alias (?) à l'adresse publique de ppp0,
Tu veux dire que la résolution des noms d'hôtes obelix, asterix, etc,
donne l'adresse IP publique ?
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre le
trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement ?
Lorsque j'ai paramétré dnsmasq pour les postes clients, j'ai vu que la
passerelle ne parvenait pas à résoudre les noms locaux et après essais
en rajoutant «nameserver 127.0.0.1» au début de /etc/resolv.conf le
problème semblé réglé. MAIS : avec la directive usepeerdns du
paramétrage pppoe, à chaque reconnexion, le fichier est recréé pour
contenir les dns tele2 et mon nameserver local est perdu... Je pourrais
certes "patcher" le script /etc/ppp/ip-up.d/0000userpeerdns pour ajouter
le nameserver manquant mais ça ne me paraît pas très «propre».
La solution à ton problème se situe à mon avis au niveau de l'option
usepeerdns. C'est-à-dire qu'il faut utiliser ton serveur DNS pour la
résolution DNS sur ta passerelle aulieu des serveurs DNS de ton FAI. Mais
il ne faut pas patcher le script 0000userpeerdns. Il faut soit supprimer
l'option usepeerdns dans ta configuration pppd (fichier /etc/ppp/options
ou fichier /etc/ppp/peers/adsl) ou soit rendre le fichier 0000userpeerdns
non executable.
Sur ce un correspondant de la liste Debian-french-user me
conseille resolvconf pour gérer les modifications dynamiques de
/etc/resolv.conf
Je ne connaissais pas resolvconf. Après avoir regardé de près ce qu'il
faisait, je trouve que ça ressemble beaucoup à du bricolage. S'il s'agit
de bricoler (dans le bon sens du terme), autant le faire sois-même via un
script maison qu'on placera dans /etc/ppp/ip-up.d. Je te conseille de
désinstaller ce package.
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre
le trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement
?
Bon, maintenant ping falbala résoud l'adresse locale (avec son fqdn)
vers l'adresse attribuée à eth1 (192.168.0.1 -> réseau local). Bizarre ?
Par contre un ping de l'adresse publique échoue sur l'erreur de sendto.
À priori tout le traffic sur lo est autorisé. Mais je peux me tromper
route indique ceci :
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Pour la configuration netfilter, je vais ajouter la sortie d'iptable-
save à l afin de ce fichier, ce n'est pas si gros.
??? et comment dnsmasq est informé des dns du fai ?
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Bon pour info, voici mon réglage netfilter :
Comme toujours :critiques et commentaires bienvenus :)
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre
le trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement
?
Bon, maintenant ping falbala résoud l'adresse locale (avec son fqdn)
vers l'adresse attribuée à eth1 (192.168.0.1 -> réseau local). Bizarre ?
Par contre un ping de l'adresse publique échoue sur l'erreur de sendto.
À priori tout le traffic sur lo est autorisé. Mais je peux me tromper
route indique ceci :
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Pour la configuration netfilter, je vais ajouter la sortie d'iptable-
save à l afin de ce fichier, ce n'est pas si gros.
??? et comment dnsmasq est informé des dns du fai ?
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Bon pour info, voici mon réglage netfilter :
Comme toujours :critiques et commentaires bienvenus :)
ensuite ça cafouille sur un «sendto opération non permise» qui
sent le problème iptables (?)
Pour le problème d'iptables, il s'agit sûrement d'une règle qui filtre
le trafic sur l'interface loopback en fonction de l'adresse source.
Un extrait de tes règles iptables pour régler ce problème éventuellement
?
Bon, maintenant ping falbala résoud l'adresse locale (avec son fqdn)
vers l'adresse attribuée à eth1 (192.168.0.1 -> réseau local). Bizarre ?
Par contre un ping de l'adresse publique échoue sur l'erreur de sendto.
À priori tout le traffic sur lo est autorisé. Mais je peux me tromper
route indique ceci :
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Pour la configuration netfilter, je vais ajouter la sortie d'iptable-
save à l afin de ce fichier, ce n'est pas si gros.
??? et comment dnsmasq est informé des dns du fai ?
- On laisse finallement l'option usepeerdns dans la configuration de
pppd.
- On empêche que les scripts de la Debian modifient le fichier
/etc/resolv.conf :
$ chmod -x /etc/ppp/ip-up.d/{*dns*,*resolv*}
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
- On renseigne le fichier /etc/resolv.conf comme précédement :
domain votredomain.tld # optionnel
nameserver 127.0.0.1
- On utilise l'option 'resolv-file=/etc/ppp/resolv.conf' dans la
configuration de dnsmasq.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Bon pour info, voici mon réglage netfilter :
Comme toujours :critiques et commentaires bienvenus :)
route indique ceci :
[...]
Il ne s'agit pas d'un problème de route.
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Non.
??? et comment dnsmasq est informé des dns du fai ?
Suffit de lui indiquer les serveurs DNS du FAI dans sa configuration.
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
Dans ma première réponse il fallait effectivement configurer à la main les
serveurs DNS, en sachant que c'est très rare qu'un FAI change les adresses
de ses serveurs DNS. Mais dans ma deuxième réponse il n'y a rien à faire
de particulier, il suffit juste de mettre l'option
'resolv-file=/etc/ppp/resolv.conf' dans la configuration de dnsmasq et ce
dernier ira lire automatiquement le fichier /etc/ppp/resolv.conf qui est
créé par pppd lors de la négociation ppp. Quant au script 0000usepeerdns,
il ne fait que copier le contenu du fichier /etc/ppp/resolv.conf dans le
fichier /etc/resolv.conf.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Elle est légère parce qu'il n'y a rien de plus à faire ou à
comprendre. C'est là toute la puissance de dnsmasq. Il offre un tas de
possibilités que d'ailleurs d'autres ne proposent même pas, il est léger
(28ko compressé avec upx alors qu'il faut compter 800ko pour le couple
bind+dhcpd) et sa configuration est simple.
|> -A PREROUTING -s 195.25.216.129 -p tcp -m tcp --dport 443 -j REDIRECT
hehe ;-)
|> -A INPUT -i lo -j ACCEPT
Ici on permet à tout trafic d'entrer sur l'interface lo, sans filtrage sur
les adresses IP et sur le protocole.
|> -A OUTPUT -s 127.0.0.1 -j ACCEPT
|> -A OUTPUT -s 192.168.0.1 -j ACCEPT
|> -A OUTPUT -o ppp0 -j ACCEPT
Mais ici on n'accepte en sortie que le trafic local ayant pour IP source
127.0.0.1 ou 192.168.0.1. Donc un ping en local sur l'IP publique sera
accepté en entrée par la précédente règle mais la réponse à ce ping sera
bloquée en sortie. Il faudrait filtrer le trafic non pas (seulement) en
fonction des adresses IP sources mais en fonction des interfaces. Mais
ensuite c'est une question de point de vue. Doit-on accepter sur
l'interface lo que du trafic initié par la plage d'IP 127.0.0.0/8 ou
accepte-t-on quand même le trafic local initié sur les autres adresses IP
du système ?
Bref, si tuu veux accepter tout le trafic sur l'interface lo :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Ainsi, un ping sur les adresses IP publique et privée sera possible.
Comme toujours :critiques et commentaires bienvenus :)
Sur le reste des règles, il me semble que c'est cohérent.
route indique ceci :
[...]
Il ne s'agit pas d'un problème de route.
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Non.
??? et comment dnsmasq est informé des dns du fai ?
Suffit de lui indiquer les serveurs DNS du FAI dans sa configuration.
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
Dans ma première réponse il fallait effectivement configurer à la main les
serveurs DNS, en sachant que c'est très rare qu'un FAI change les adresses
de ses serveurs DNS. Mais dans ma deuxième réponse il n'y a rien à faire
de particulier, il suffit juste de mettre l'option
'resolv-file=/etc/ppp/resolv.conf' dans la configuration de dnsmasq et ce
dernier ira lire automatiquement le fichier /etc/ppp/resolv.conf qui est
créé par pppd lors de la négociation ppp. Quant au script 0000usepeerdns,
il ne fait que copier le contenu du fichier /etc/ppp/resolv.conf dans le
fichier /etc/resolv.conf.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Elle est légère parce qu'il n'y a rien de plus à faire ou à
comprendre. C'est là toute la puissance de dnsmasq. Il offre un tas de
possibilités que d'ailleurs d'autres ne proposent même pas, il est léger
(28ko compressé avec upx alors qu'il faut compter 800ko pour le couple
bind+dhcpd) et sa configuration est simple.
|> -A PREROUTING -s 195.25.216.129 -p tcp -m tcp --dport 443 -j REDIRECT
hehe ;-)
|> -A INPUT -i lo -j ACCEPT
Ici on permet à tout trafic d'entrer sur l'interface lo, sans filtrage sur
les adresses IP et sur le protocole.
|> -A OUTPUT -s 127.0.0.1 -j ACCEPT
|> -A OUTPUT -s 192.168.0.1 -j ACCEPT
|> -A OUTPUT -o ppp0 -j ACCEPT
Mais ici on n'accepte en sortie que le trafic local ayant pour IP source
127.0.0.1 ou 192.168.0.1. Donc un ping en local sur l'IP publique sera
accepté en entrée par la précédente règle mais la réponse à ce ping sera
bloquée en sortie. Il faudrait filtrer le trafic non pas (seulement) en
fonction des adresses IP sources mais en fonction des interfaces. Mais
ensuite c'est une question de point de vue. Doit-on accepter sur
l'interface lo que du trafic initié par la plage d'IP 127.0.0.0/8 ou
accepte-t-on quand même le trafic local initié sur les autres adresses IP
du système ?
Bref, si tuu veux accepter tout le trafic sur l'interface lo :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Ainsi, un ping sur les adresses IP publique et privée sera possible.
Comme toujours :critiques et commentaires bienvenus :)
Sur le reste des règles, il me semble que c'est cohérent.
route indique ceci :
[...]
Il ne s'agit pas d'un problème de route.
Puis en déduire que l'interface défectueuse pour iptables est ppp0 et
non lo ?
Non.
??? et comment dnsmasq est informé des dns du fai ?
Suffit de lui indiquer les serveurs DNS du FAI dans sa configuration.
Mais alors, comment les "nameserver xx.xx.xx.xx" du fai vont-il
s'ajouter à la config réseau ? C'est justement le script 0000usepeerdns
qui s'en charge ? Ou si je comprends, je les ajoute à la main mais
dans ce cas le réglage n'est plus dynamique à la négociation ppp...
Dans ma première réponse il fallait effectivement configurer à la main les
serveurs DNS, en sachant que c'est très rare qu'un FAI change les adresses
de ses serveurs DNS. Mais dans ma deuxième réponse il n'y a rien à faire
de particulier, il suffit juste de mettre l'option
'resolv-file=/etc/ppp/resolv.conf' dans la configuration de dnsmasq et ce
dernier ira lire automatiquement le fichier /etc/ppp/resolv.conf qui est
créé par pppd lors de la négociation ppp. Quant au script 0000usepeerdns,
il ne fait que copier le contenu du fichier /etc/ppp/resolv.conf dans le
fichier /etc/resolv.conf.
C'est d'ailleurs à très peu de chose près la procédure indiquée par la
documentation de dnsmasq.
Que j'ai trouvée assez légère en dehors du dnsmasq.conf fourni (et c'est
un euphémisme).
Elle est légère parce qu'il n'y a rien de plus à faire ou à
comprendre. C'est là toute la puissance de dnsmasq. Il offre un tas de
possibilités que d'ailleurs d'autres ne proposent même pas, il est léger
(28ko compressé avec upx alors qu'il faut compter 800ko pour le couple
bind+dhcpd) et sa configuration est simple.
|> -A PREROUTING -s 195.25.216.129 -p tcp -m tcp --dport 443 -j REDIRECT
hehe ;-)
|> -A INPUT -i lo -j ACCEPT
Ici on permet à tout trafic d'entrer sur l'interface lo, sans filtrage sur
les adresses IP et sur le protocole.
|> -A OUTPUT -s 127.0.0.1 -j ACCEPT
|> -A OUTPUT -s 192.168.0.1 -j ACCEPT
|> -A OUTPUT -o ppp0 -j ACCEPT
Mais ici on n'accepte en sortie que le trafic local ayant pour IP source
127.0.0.1 ou 192.168.0.1. Donc un ping en local sur l'IP publique sera
accepté en entrée par la précédente règle mais la réponse à ce ping sera
bloquée en sortie. Il faudrait filtrer le trafic non pas (seulement) en
fonction des adresses IP sources mais en fonction des interfaces. Mais
ensuite c'est une question de point de vue. Doit-on accepter sur
l'interface lo que du trafic initié par la plage d'IP 127.0.0.0/8 ou
accepte-t-on quand même le trafic local initié sur les autres adresses IP
du système ?
Bref, si tuu veux accepter tout le trafic sur l'interface lo :
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
Ainsi, un ping sur les adresses IP publique et privée sera possible.
Comme toujours :critiques et commentaires bienvenus :)
Sur le reste des règles, il me semble que c'est cohérent.