J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
petits points de détail.
Entre autres choses, si je le reboote, les règles du firewall PF ne sont
pas chargée quand le système démarre.
J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
pf_enable="YES" # Set to YES to enable packet filter (pf)
pflog_enable="YES" # Set to YES to enable packet filter logging
Après reboot, j'ai ça :
# pfctl -s all
No ALTQ support in kernel
ALTQ related functions disabled
FILTER RULES:
INFO:
Status: Enabled for 3 days 01:46:57 Debug: Urgent
State Table Total Rate
current entries 0
searches 43387599 163.3/s
inserts 0 0.0/s
removals 0 0.0/s
Counters
match 43387599 163.3/s
bad-offset 0 0.0/s
fragment 0 0.0/s
...
OS FINGERPRINTS:
696 fingerprints loaded
Alors que bien sûr, j'ai un paquet de règles dans mon /etc/pf.conf.
Je n'ai rien trouvé dans le dmesg.boot, dans messages, ni ailleurs.
Une idée ?
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
À (at) Fri, 09 Dec 2011 00:05:42 +0100, patpro ~ patrick proniewski écrivait (wrote):
J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques petits points de détail. Entre autres choses, si je le reboote, les règles du firewall PF ne sont pas chargée quand le système démarre.
J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" # Set to YES to enable packet filter logging
[...]
Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 00:05:42 +0100,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
petits points de détail.
Entre autres choses, si je le reboote, les règles du firewall PF ne sont
pas chargée quand le système démarre.
J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
pf_enable="YES" # Set to YES to enable packet filter (pf)
pflog_enable="YES" # Set to YES to enable packet filter logging
[...]
Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 00:05:42 +0100, patpro ~ patrick proniewski écrivait (wrote):
J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques petits points de détail. Entre autres choses, si je le reboote, les règles du firewall PF ne sont pas chargée quand le système démarre.
J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
pf_enable="YES" # Set to YES to enable packet filter (pf) pflog_enable="YES" # Set to YES to enable packet filter logging
[...]
Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
patpro ~ patrick proniewski
In article , Paul Gaborit wrote:
À (at) Fri, 09 Dec 2011 00:05:42 +0100, patpro ~ patrick proniewski écrivait (wrote):
> J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques > petits points de détail. > Entre autres choses, si je le reboote, les règles du firewall PF ne sont > pas chargée quand le système démarre. > > J'ai pourtant bien ces lignes dans mon /etc/rc.conf : > > pf_enable="YES" # Set to YES to enable packet filter (pf) > pflog_enable="YES" # Set to YES to enable packet filter logging [...] > > Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Je l'ai ajouté, mais ça ne change rien. Au redémarrage, pf ne charge toujours pas les règles, mais il est par contre bien activé.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
si je lance manuellement /etc/rc.d/pf, les règles sont chargées correctement.
Est-il envisageable que l'ensemble des IP de la machine ne soit pas disponible au moment où pf tente de charger les règles pendant le boot ? C'est un serveur web qui dispose de 40 adresses IP. 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne ipv4_addrs_em1="..."
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <wt9liqmbju0.fsf@marceau.mines-albi.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Fri, 09 Dec 2011 00:05:42 +0100,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
> J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques
> petits points de détail.
> Entre autres choses, si je le reboote, les règles du firewall PF ne sont
> pas chargée quand le système démarre.
>
> J'ai pourtant bien ces lignes dans mon /etc/rc.conf :
>
> pf_enable="YES" # Set to YES to enable packet filter (pf)
> pflog_enable="YES" # Set to YES to enable packet filter logging
[...]
>
> Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Je l'ai ajouté, mais ça ne change rien. Au redémarrage, pf ne charge
toujours pas les règles, mais il est par contre bien activé.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
si je lance manuellement /etc/rc.d/pf, les règles sont chargées
correctement.
Est-il envisageable que l'ensemble des IP de la machine ne soit pas
disponible au moment où pf tente de charger les règles pendant le boot ?
C'est un serveur web qui dispose de 40 adresses IP.
39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
ipv4_addrs_em1="..."
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
À (at) Fri, 09 Dec 2011 00:05:42 +0100, patpro ~ patrick proniewski écrivait (wrote):
> J'ai un serveur FreeBSD 8.2 qui fonctionne correctement, à part quelques > petits points de détail. > Entre autres choses, si je le reboote, les règles du firewall PF ne sont > pas chargée quand le système démarre. > > J'ai pourtant bien ces lignes dans mon /etc/rc.conf : > > pf_enable="YES" # Set to YES to enable packet filter (pf) > pflog_enable="YES" # Set to YES to enable packet filter logging [...] > > Une idée ?
Ici, ça marche avec juste la ligne suivante en sus :
pf_rules="/etc/pf.conf" # rules definition file for pf
Mais, a priori, c'est le réglage par défaut.
Je l'ai ajouté, mais ça ne change rien. Au redémarrage, pf ne charge toujours pas les règles, mais il est par contre bien activé.
Que se passe-t-il après un restart de pf (via /etc/rc.d/pf) ?
si je lance manuellement /etc/rc.d/pf, les règles sont chargées correctement.
Est-il envisageable que l'ensemble des IP de la machine ne soit pas disponible au moment où pf tente de charger les règles pendant le boot ? C'est un serveur web qui dispose de 40 adresses IP. 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne ipv4_addrs_em1="..."
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Paul Gaborit
À (at) Fri, 09 Dec 2011 07:17:37 +0100, patpro ~ patrick proniewski écrivait (wrote):
Est-il envisageable que l'ensemble des IP de la machine ne soit pas disponible au moment où pf tente de charger les règles pendant le boot ?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à mon avis, sans aucune importance puisqu'on peut même utiliser des interfaces inexistantes dans les règles. PF charge quand même la règle et, si l'interface vient à exister, elle sera appliquée.
C'est un serveur web qui dispose de 40 adresses IP. 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela pourrait jouer.
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement plus causant au boot...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 07:17:37 +0100,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
Est-il envisageable que l'ensemble des IP de la machine ne soit pas
disponible au moment où pf tente de charger les règles pendant le boot
?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à
mon avis, sans aucune importance puisqu'on peut même utiliser des
interfaces inexistantes dans les règles. PF charge quand même la règle
et, si l'interface vient à exister, elle sera appliquée.
C'est un serveur web qui dispose de 40 adresses IP.
39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela
pourrait jouer.
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement
plus causant au boot...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 07:17:37 +0100, patpro ~ patrick proniewski écrivait (wrote):
Est-il envisageable que l'ensemble des IP de la machine ne soit pas disponible au moment où pf tente de charger les règles pendant le boot ?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à mon avis, sans aucune importance puisqu'on peut même utiliser des interfaces inexistantes dans les règles. PF charge quand même la règle et, si l'interface vient à exister, elle sera appliquée.
C'est un serveur web qui dispose de 40 adresses IP. 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela pourrait jouer.
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement plus causant au boot...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
patpro ~ Patrick Proniewski
In article , Paul Gaborit wrote:
À (at) Fri, 09 Dec 2011 07:17:37 +0100, patpro ~ patrick proniewski écrivait (wrote):
> Est-il envisageable que l'ensemble des IP de la machine ne soit pas > disponible au moment où pf tente de charger les règles pendant le boot > ?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à mon avis, sans aucune importance puisqu'on peut même utiliser des interfaces inexistantes dans les règles. PF charge quand même la règle et, si l'interface vient à exister, elle sera appliquée.
> C'est un serveur web qui dispose de 40 adresses IP. > 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne > ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela pourrait jouer.
moi non plus, mais c'est la seule machine que j'ai qui présente ce problème, et en prime c'est la seule qui utilise la syntaxe ipv4_addrs_em0="..." dans son rc.conf pour les interfaces réseau
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement plus causant au boot...
hmmm le problème c'est de pouvoir lire ces messages. En fait, le chargement de PF se fait après la fin de ce que je trouve dans le dmesg. Il y a un moyen de récupérer ce qui est affiché à la console dans un fichier de log ?
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
In article <wt9ty5am78j.fsf@marceau.mines-albi.fr>,
Paul Gaborit <Paul.Gaborit@invalid.invalid> wrote:
À (at) Fri, 09 Dec 2011 07:17:37 +0100,
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
> Est-il envisageable que l'ensemble des IP de la machine ne soit pas
> disponible au moment où pf tente de charger les règles pendant le boot
> ?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à
mon avis, sans aucune importance puisqu'on peut même utiliser des
interfaces inexistantes dans les règles. PF charge quand même la règle
et, si l'interface vient à exister, elle sera appliquée.
> C'est un serveur web qui dispose de 40 adresses IP.
> 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne
> ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela
pourrait jouer.
moi non plus, mais c'est la seule machine que j'ai qui présente ce
problème, et en prime c'est la seule qui utilise la syntaxe
ipv4_addrs_em0="..." dans son rc.conf pour les interfaces réseau
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement
plus causant au boot...
hmmm le problème c'est de pouvoir lire ces messages. En fait, le
chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
Il y a un moyen de récupérer ce qui est affiché à la console dans un
fichier de log ?
patpro
--
Je cherche à changer d'air -> http://www.patpro.net/cv
À (at) Fri, 09 Dec 2011 07:17:37 +0100, patpro ~ patrick proniewski écrivait (wrote):
> Est-il envisageable que l'ensemble des IP de la machine ne soit pas > disponible au moment où pf tente de charger les règles pendant le boot > ?
C'est possible (et même courant si on utilise DHCP par exemple) mais, à mon avis, sans aucune importance puisqu'on peut même utiliser des interfaces inexistantes dans les règles. PF charge quand même la règle et, si l'interface vient à exister, elle sera appliquée.
> C'est un serveur web qui dispose de 40 adresses IP. > 39 sont sur une ligne ipv4_addrs_em0="..." et 1 est sur une ligne > ipv4_addrs_em1="..."
Belle collection d'IP ! Mais franchement, je ne vois pas en quoi cela pourrait jouer.
moi non plus, mais c'est la seule machine que j'ai qui présente ce problème, et en prime c'est la seule qui utilise la syntaxe ipv4_addrs_em0="..." dans son rc.conf pour les interfaces réseau
En activant le debug au niveau loud (dans pf.conf), PF sera sûrement plus causant au boot...
hmmm le problème c'est de pouvoir lire ces messages. En fait, le chargement de PF se fait après la fin de ce que je trouve dans le dmesg. Il y a un moyen de récupérer ce qui est affiché à la console dans un fichier de log ?
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
Eric Masson
patpro ~ Patrick Proniewski writes:
'Lut,
hmmm le problème c'est de pouvoir lire ces messages. En fait, le chargement de PF se fait après la fin de ce que je trouve dans le dmesg. Il y a un moyen de récupérer ce qui est affiché à la console dans un fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
-- <<Article 6.2 : L'abonné s'engage à conserver secret les éléments constitutifs de son identification (nom d'utilisateur, mot de passe de connexion, adresse e-mail, mot de passe de messagerie). -+- FAI in : GNU - Mon adresse email est classée secret-défense -+-
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
hmmm le problème c'est de pouvoir lire ces messages. En fait, le
chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
Il y a un moyen de récupérer ce qui est affiché à la console dans un
fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
--
<<Article 6.2 : L'abonné s'engage à conserver secret les éléments
constitutifs de son identification (nom d'utilisateur, mot de passe de
connexion, adresse e-mail, mot de passe de messagerie).
-+- FAI in : GNU - Mon adresse email est classée secret-défense -+-
hmmm le problème c'est de pouvoir lire ces messages. En fait, le chargement de PF se fait après la fin de ce que je trouve dans le dmesg. Il y a un moyen de récupérer ce qui est affiché à la console dans un fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
-- <<Article 6.2 : L'abonné s'engage à conserver secret les éléments constitutifs de son identification (nom d'utilisateur, mot de passe de connexion, adresse e-mail, mot de passe de messagerie). -+- FAI in : GNU - Mon adresse email est classée secret-défense -+-
patpro ~ Patrick Proniewski
In article , Eric Masson wrote:
patpro ~ Patrick Proniewski writes:
'Lut,
> hmmm le problème c'est de pouvoir lire ces messages. En fait, le > chargement de PF se fait après la fin de ce que je trouve dans le dmesg. > Il y a un moyen de récupérer ce qui est affiché à la console dans un > fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
complètement. Ma blonditude m'a rattrapé, ça m'apprendra à pas lire le man.
Et donc, le mystère est levé :
--------------------------- Starting pflog. Enabling pf Dec 9 07:12:39 pflogd[486]: NSSWITCH(_nsdispatch): ldap, passwd, endpwent, not found, and no fallback provided No ALTQ support in kernel ALTQ related functions disabled Dec 9 07:12:39 pflogd[486]: [priv]: msg PRIV_OPEN_LOG received no IP address found for smtp.univ-lyon2.fr /etc/pf.conf:60: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
No ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled pf enabled ---------------------------
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user 80 keep state label " to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
In article <47e9r8-k7q.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
> hmmm le problème c'est de pouvoir lire ces messages. En fait, le
> chargement de PF se fait après la fin de ce que je trouve dans le dmesg.
> Il y a un moyen de récupérer ce qui est affiché à la console dans un
> fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
complètement. Ma blonditude m'a rattrapé, ça m'apprendra à pas lire le
man.
Et donc, le mystère est levé :
---------------------------
Starting pflog.
Enabling pf
Dec 9 07:12:39 pflogd[486]: NSSWITCH(_nsdispatch): ldap, passwd,
endpwent, not found, and no fallback provided
No ALTQ support in kernel
ALTQ related functions disabled
Dec 9 07:12:39 pflogd[486]: [priv]: msg PRIV_OPEN_LOG received
no IP address found for smtp.univ-lyon2.fr
/etc/pf.conf:60:
could not parse host specification
pfctl:
Syntax error in config file: pf rules not loaded
No ALTQ support in kernel
ALTQ related functions disabled
No ALTQ support in kernel
ALTQ related functions disabled
pf enabled
---------------------------
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user
80 keep state label "www@any to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.
patpro
--
Je cherche à changer d'air -> http://www.patpro.net/cv
> hmmm le problème c'est de pouvoir lire ces messages. En fait, le > chargement de PF se fait après la fin de ce que je trouve dans le dmesg. > Il y a un moyen de récupérer ce qui est affiché à la console dans un > fichier de log ?
dmesg -a ne résoudrait pas ton problème, des fois ?
complètement. Ma blonditude m'a rattrapé, ça m'apprendra à pas lire le man.
Et donc, le mystère est levé :
--------------------------- Starting pflog. Enabling pf Dec 9 07:12:39 pflogd[486]: NSSWITCH(_nsdispatch): ldap, passwd, endpwent, not found, and no fallback provided No ALTQ support in kernel ALTQ related functions disabled Dec 9 07:12:39 pflogd[486]: [priv]: msg PRIV_OPEN_LOG received no IP address found for smtp.univ-lyon2.fr /etc/pf.conf:60: could not parse host specification
pfctl: Syntax error in config file: pf rules not loaded
No ALTQ support in kernel ALTQ related functions disabled No ALTQ support in kernel ALTQ related functions disabled pf enabled ---------------------------
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user 80 keep state label " to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
Eric Masson
patpro ~ Patrick Proniewski writes:
'Lut,
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une fois que la résolution dns serait opérationnelle, ce serait plus propre.
-- svp un site pour mesurer mon debit de merde ? -+- G in GNU : Le retour de la pompe à merde -+-
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une
fois que la résolution dns serait opérationnelle, ce serait plus propre.
--
svp un site pour mesurer mon debit de merde ?
-+- G in GNU : Le retour de la pompe à merde -+-
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une fois que la résolution dns serait opérationnelle, ce serait plus propre.
-- svp un site pour mesurer mon debit de merde ? -+- G in GNU : Le retour de la pompe à merde -+-
Paul Gaborit
À (at) Fri, 09 Dec 2011 14:57:11 +0100, patpro ~ Patrick Proniewski écrivait (wrote):
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user 80 keep state label " to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
C'est peut-être "relou" mais c'est sain.
Là, vos règlages firewall dépendent d'une réponse DNS. Ce DNS est-il sécurisé ? Fiable ? Que faire si l'adresse IP change ? etc.
L'adresse IP fixe est quand même bien plus sûr. ;-)
Un moyen de répondre au besoin : utiliser une table à la place du nom et mettre à jour cette table après le boot (une fois que le DNS répond correctement) et de manière régulière (si l'adresse change)...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 14:57:11 +0100,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> écrivait (wrote):
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user
80 keep state label "www@any to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
remplacer par l'IP, mais c'est un peu relou.
C'est peut-être "relou" mais c'est sain.
Là, vos règlages firewall dépendent d'une réponse DNS. Ce DNS est-il
sécurisé ? Fiable ? Que faire si l'adresse IP change ? etc.
L'adresse IP fixe est quand même bien plus sûr. ;-)
Un moyen de répondre au besoin : utiliser une table à la place du nom et
mettre à jour cette table après le boot (une fois que le DNS répond
correctement) et de manière régulière (si l'adresse change)...
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Fri, 09 Dec 2011 14:57:11 +0100, patpro ~ Patrick Proniewski écrivait (wrote):
La ligne du pf.conf incriminée est :
pass out log quick proto tcp from any to smtp.univ-lyon2.fr port 25 user 80 keep state label " to smtp:25 output"
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
C'est peut-être "relou" mais c'est sain.
Là, vos règlages firewall dépendent d'une réponse DNS. Ce DNS est-il sécurisé ? Fiable ? Que faire si l'adresse IP change ? etc.
L'adresse IP fixe est quand même bien plus sûr. ;-)
Un moyen de répondre au besoin : utiliser une table à la place du nom et mettre à jour cette table après le boot (une fois que le DNS répond correctement) et de manière régulière (si l'adresse change)...
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Paul Gaborit
À (at) Fri, 09 Dec 2011 15:33:27 +0100, Eric Masson écrivait (wrote):
patpro ~ Patrick Proniewski writes:
'Lut,
Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une fois que la résolution dns serait opérationnelle, ce serait plus propre.
Je viens de trouver une discussion de 2007 qui suggère aussi une solution de ce genre :
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
patpro ~ Patrick Proniewski
In article , Eric Masson wrote:
patpro ~ Patrick Proniewski writes:
'Lut,
> Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais > remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une fois que la résolution dns serait opérationnelle, ce serait plus propre.
C'est une solution mais j'aime les choses simples ;) Puis bon, je maitrise les IP que j'ai mises en dur dans la conf, je ne dépend pas d'autres personnes qui pourraient par exemple changer l'IP du smtp.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
In article <nqi9r8-k7q.ln1@srvbsdfenssv.interne.associated-bears.org>,
Eric Masson <emss@free.fr> wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> writes:
'Lut,
> Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais
> remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une
fois que la résolution dns serait opérationnelle, ce serait plus propre.
C'est une solution mais j'aime les choses simples ;)
Puis bon, je maitrise les IP que j'ai mises en dur dans la conf, je ne
dépend pas d'autres personnes qui pourraient par exemple changer l'IP du
smtp.
patpro
--
Je cherche à changer d'air -> http://www.patpro.net/cv
> Visiblement, si ça résout pas au moment du boot, c'est cuit. Je vais > remplacer par l'IP, mais c'est un peu relou.
Il te faudrait une config pf minimaliste au boot que tu étendrais une fois que la résolution dns serait opérationnelle, ce serait plus propre.
C'est une solution mais j'aime les choses simples ;) Puis bon, je maitrise les IP que j'ai mises en dur dans la conf, je ne dépend pas d'autres personnes qui pourraient par exemple changer l'IP du smtp.
patpro
-- Je cherche à changer d'air -> http://www.patpro.net/cv
