La doc de pf ne me semble pas très précise sur un point. J'ai un
paquet qui arrive sur l'interface if1, qui est décapsulé ipsec et qui
va passer dans ifipsec (enc0) s'il est correct. Enfin, le paquet sort
par if2.
Ainsi, un paquet chiffré fait if1 -> ifipsec -> if2.
Un paquet non chiffré fait if1 -> if2.
Parmi les règles, j'ai :
pass on $ifipsec from <clients> to any tag AUTHOK keep state
Cela me permet de laisser passer ceux qui ont fait de l'IPsec :
pass on $if2 from <clients> to any tagged AUTHOK keep state
Maintenant, je voudrais que ceux qui n'ont pas fait d'IPsec soient
redirigés sur un serveur web. Sur quelle interface suis-je sensé faire
le rdr ?
Avec cette règle, tout le monde va se retrouver sur le serveur web :
rdr on $if1 inet proto tcp from <clients> to ! $monip
port www -> localhost port www
Si je tente de matcher sur le tag, je pense que ce sera aussi le cas
car le paquet n'est pas encore taggué. Est-ce que je peux faire le rdr
sur la seconde interface ? Cela me semble un peu tordu :
rdr on $if2 inet proto tcp from <clients> to ! $monip
port www -> localhost port www ! tagged AUTHOK
Est-ce que mon intuition est bonne pour l'ordre dans lequel les
paquets traversent les règles ? D'abord if1, puis ifipsec, tagage ici,
puis je peux utiliser le tag sur if2 dans un rdr ? Un rdr sur
l'interface de sortie est-il autorisé ?
--
#ifdef STUPIDLY_TRUST_BROKEN_PCMD_ENA_BIT
2.4.0-test2 /usr/src/linux/drivers/ide/cmd640.c
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane Catteau
Vincent Bernat devait dire quelque chose comme ceci :
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Si je tente de matcher sur le tag, je pense que ce sera aussi le cas car le paquet n'est pas encore taggué. Est-ce que je peux faire le rdr sur la seconde interface ? Cela me semble un peu tordu :
man pf.conf, du côté des options. Tu verras que contrairement à ipf, qui considérait toutes les interfaces comme une seule, et appliquait à l'une ce qui avait été décidé pour les autres, pf peut lui les considérer de façon indépendante (j'ai d'ailleurs l'impression que c'est la conf par défaut contrairement à ce que dit la page man). Du coup, en abstraction tu peux te représenter chaque interface comme étant une machine indépendante liée directement à la précédente/suivante, et ce n'est plus tordu de faire la redirection sur l'interface de sortie.
rdr on $if2 inet proto tcp from <clients> to ! $monip port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les tag. Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Est-ce que mon intuition est bonne pour l'ordre dans lequel les paquets traversent les règles ? D'abord if1, puis ifipsec, tagage ici, puis je peux utiliser le tag sur if2 dans un rdr ?
C'est : - table d'état - if1 - table d'état - ifipsec - table d'état - if2 Donc ça dépend des options. Si les interfaces sont à considérer comme dépendantes, les règles d'if2 ne seront jamais traitées puisque tu as un keep state sur la règle qui tag le paquet. Dans le cas contraire il y a une table d'état par interface, et tant que tu n'as pas eu un keep state concernant if2, cela ira jusqu'au bout, et donc jusqu'au rdr.
Un rdr sur l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne : arrivée sur if1 : - table d'état - redirection - filtrage arrivée sur ifipsec : - table d'état - redirection - filtrage arrivée sur if2 : - table d'état - redirection - filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
Vincent Bernat devait dire quelque chose comme ceci :
pass on $ifipsec from <clients> to any tag AUTHOK keep state
pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Si je tente de matcher sur le tag, je pense que ce sera aussi le cas
car le paquet n'est pas encore taggué. Est-ce que je peux faire le rdr
sur la seconde interface ? Cela me semble un peu tordu :
man pf.conf, du côté des options. Tu verras que contrairement à ipf,
qui considérait toutes les interfaces comme une seule, et appliquait à
l'une ce qui avait été décidé pour les autres, pf peut lui les
considérer de façon indépendante (j'ai d'ailleurs l'impression que
c'est la conf par défaut contrairement à ce que dit la page man). Du
coup, en abstraction tu peux te représenter chaque interface comme
étant une machine indépendante liée directement à la
précédente/suivante, et ce n'est plus tordu de faire la redirection sur
l'interface de sortie.
rdr on $if2 inet proto tcp from <clients> to ! $monip
port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les tag.
Si ce n'est pas le cas tu devras prendre le problème à l'envers et
faire une redirection port pour port lorsque le paquet est tagé, et
ensuite faire une redirection vers le serveur HTTP pour les paquets qui
restent.
Est-ce que mon intuition est bonne pour l'ordre dans lequel les
paquets traversent les règles ? D'abord if1, puis ifipsec, tagage ici,
puis je peux utiliser le tag sur if2 dans un rdr ?
C'est :
- table d'état
- if1
- table d'état
- ifipsec
- table d'état
- if2
Donc ça dépend des options. Si les interfaces sont à considérer comme
dépendantes, les règles d'if2 ne seront jamais traitées puisque tu as
un keep state sur la règle qui tag le paquet. Dans le cas contraire il
y a une table d'état par interface, et tant que tu n'as pas eu un keep
state concernant if2, cela ira jusqu'au bout, et donc jusqu'au rdr.
Un rdr sur
l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne :
arrivée sur if1 :
- table d'état
- redirection
- filtrage
arrivée sur ifipsec :
- table d'état
- redirection
- filtrage
arrivée sur if2 :
- table d'état
- redirection
- filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une
redirection sur l'interface de sortie.
Vincent Bernat devait dire quelque chose comme ceci :
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Si je tente de matcher sur le tag, je pense que ce sera aussi le cas car le paquet n'est pas encore taggué. Est-ce que je peux faire le rdr sur la seconde interface ? Cela me semble un peu tordu :
man pf.conf, du côté des options. Tu verras que contrairement à ipf, qui considérait toutes les interfaces comme une seule, et appliquait à l'une ce qui avait été décidé pour les autres, pf peut lui les considérer de façon indépendante (j'ai d'ailleurs l'impression que c'est la conf par défaut contrairement à ce que dit la page man). Du coup, en abstraction tu peux te représenter chaque interface comme étant une machine indépendante liée directement à la précédente/suivante, et ce n'est plus tordu de faire la redirection sur l'interface de sortie.
rdr on $if2 inet proto tcp from <clients> to ! $monip port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les tag. Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Est-ce que mon intuition est bonne pour l'ordre dans lequel les paquets traversent les règles ? D'abord if1, puis ifipsec, tagage ici, puis je peux utiliser le tag sur if2 dans un rdr ?
C'est : - table d'état - if1 - table d'état - ifipsec - table d'état - if2 Donc ça dépend des options. Si les interfaces sont à considérer comme dépendantes, les règles d'if2 ne seront jamais traitées puisque tu as un keep state sur la règle qui tag le paquet. Dans le cas contraire il y a une table d'état par interface, et tant que tu n'as pas eu un keep state concernant if2, cela ira jusqu'au bout, et donc jusqu'au rdr.
Un rdr sur l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne : arrivée sur if1 : - table d'état - redirection - filtrage arrivée sur ifipsec : - table d'état - redirection - filtrage arrivée sur if2 : - table d'état - redirection - filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
Vincent Bernat
OoO Peu avant le début de l'après-midi du jeudi 03 novembre 2005, vers 13:13, "Stephane Catteau" disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
rdr on $if2 inet proto tcp from <clients> to ! $monip port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les tag.
Cela fonctionne (et c'est confirmé par le man).
Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Un rdr sur l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne : arrivée sur if1 : - table d'état - redirection - filtrage arrivée sur ifipsec : - table d'état - redirection - filtrage arrivée sur if2 : - table d'état - redirection - filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Et cela fonctionne. En fait, le tag ne sert pas à grand chose. Le paquet arrive sur $if1. S'il est chiffré, il ne matche pas le rdr parce que c'est de l'ESP. S'il n'est pas chiffré, il matche le rdr car il n'est pas non plus taggué.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :) -- je bavarde de ce que je veux -+- CF in Guide du Fmblien Assassin : bien configurer son bavardage -+-
OoO Peu avant le début de l'après-midi du jeudi 03 novembre 2005, vers
13:13, "Stephane Catteau" <steph.nospam@sc4x.net> disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state
pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
rdr on $if2 inet proto tcp from <clients> to ! $monip
port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les
tag.
Cela fonctionne (et c'est confirmé par le man).
Si ce n'est pas le cas tu devras prendre le problème à l'envers
et faire une redirection port pour port lorsque le paquet est tagé, et
ensuite faire une redirection vers le serveur HTTP pour les paquets
qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Un rdr sur
l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne :
arrivée sur if1 :
- table d'état
- redirection
- filtrage
arrivée sur ifipsec :
- table d'état
- redirection
- filtrage
arrivée sur if2 :
- table d'état
- redirection
- filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une
redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http
pass on $ifipsec from <clients> to any tag AUTHOK keep state
Et cela fonctionne. En fait, le tag ne sert pas à grand chose. Le
paquet arrive sur $if1. S'il est chiffré, il ne matche pas le rdr
parce que c'est de l'ESP. S'il n'est pas chiffré, il matche le rdr
car il n'est pas non plus taggué.
Mon problème ne se pose donc plus. J'ai essayé de faire trop
compliqué. :)
--
je bavarde de ce que je veux
-+- CF in Guide du Fmblien Assassin : bien configurer son bavardage -+-
OoO Peu avant le début de l'après-midi du jeudi 03 novembre 2005, vers 13:13, "Stephane Catteau" disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
rdr on $if2 inet proto tcp from <clients> to ! $monip port www -> localhost port www ! tagged AUTHOK
Par contre, je ne sais plus si la négation marche aussi sur les tag.
Cela fonctionne (et c'est confirmé par le man).
Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Un rdr sur l'interface de sortie est-il autorisé ?
Le paquet passe trois fois dans pf, ce qui donne : arrivée sur if1 : - table d'état - redirection - filtrage arrivée sur ifipsec : - table d'état - redirection - filtrage arrivée sur if2 : - table d'état - redirection - filtrage
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Et cela fonctionne. En fait, le tag ne sert pas à grand chose. Le paquet arrive sur $if1. S'il est chiffré, il ne matche pas le rdr parce que c'est de l'ESP. S'il n'est pas chiffré, il matche le rdr car il n'est pas non plus taggué.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :) -- je bavarde de ce que je veux -+- CF in Guide du Fmblien Assassin : bien configurer son bavardage -+-
Stephane Catteau
Vincent Bernat n'était pas loin de dire :
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire l'inverse, à savoir bloquer tout, et n'autoriser que les cas particuliers, avec un quick cette fois. Actuellement un cas non prévu au manuel sera considéré comme valide, alors que c'est l'inverse qui devrait se passer.
Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Euh, non en fait, mais bon ce n'est pas nécessaire donc tant mieux.
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles : - Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK, alors faire cela - Si le paquet étudié au niveau de ifipsec est ceci alors on met un tag AUTHOK => Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis lorsque ta règle de redirection sera utilisée.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton problème. Amha tu as ne prend pas le problème dans le bon sens, et tu gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet d'avoir très peu de règles et de ne pas travailler dans l'abstraction pure comme c'est trop souvent le cas avec les autres filtre IP, il serait dommage que tu t'en passes. Si tu veux je fais un p'tit topo rapide sur fcs.
Vincent Bernat n'était pas loin de dire :
pass on $ifipsec from <clients> to any tag AUTHOK keep state
pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire
l'inverse, à savoir bloquer tout, et n'autoriser que les cas
particuliers, avec un quick cette fois. Actuellement un cas non prévu
au manuel sera considéré comme valide, alors que c'est l'inverse qui
devrait se passer.
Si ce n'est pas le cas tu devras prendre le problème à l'envers
et faire une redirection port pour port lorsque le paquet est tagé, et
ensuite faire une redirection vers le serveur HTTP pour les paquets
qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Euh, non en fait, mais bon ce n'est pas nécessaire donc tant mieux.
En théorie je ne vois donc pas ce qui interdirait de faire une
redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged
AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK
keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles :
- Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK,
alors faire cela
- Si le paquet étudié au niveau de ifipsec est ceci alors on met un tag
AUTHOK
=> Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis
lorsque ta règle de redirection sera utilisée.
Mon problème ne se pose donc plus. J'ai essayé de faire trop
compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton
problème. Amha tu as ne prend pas le problème dans le bon sens, et tu
gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet
d'avoir très peu de règles et de ne pas travailler dans l'abstraction
pure comme c'est trop souvent le cas avec les autres filtre IP, il
serait dommage que tu t'en passes.
Si tu veux je fais un p'tit topo rapide sur fcs.
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire l'inverse, à savoir bloquer tout, et n'autoriser que les cas particuliers, avec un quick cette fois. Actuellement un cas non prévu au manuel sera considéré comme valide, alors que c'est l'inverse qui devrait se passer.
Si ce n'est pas le cas tu devras prendre le problème à l'envers et faire une redirection port pour port lorsque le paquet est tagé, et ensuite faire une redirection vers le serveur HTTP pour les paquets qui restent.
Un seul rdr sera appliqué sur un paquet ? Mais bon, la négation fonctionne.
Euh, non en fait, mais bon ce n'est pas nécessaire donc tant mieux.
En théorie je ne vois donc pas ce qui interdirait de faire une redirection sur l'interface de sortie.
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles : - Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK, alors faire cela - Si le paquet étudié au niveau de ifipsec est ceci alors on met un tag AUTHOK => Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis lorsque ta règle de redirection sera utilisée.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton problème. Amha tu as ne prend pas le problème dans le bon sens, et tu gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet d'avoir très peu de règles et de ne pas travailler dans l'abstraction pure comme c'est trop souvent le cas avec les autres filtre IP, il serait dommage que tu t'en passes. Si tu veux je fais un p'tit topo rapide sur fcs.
Vincent Bernat
OoO Vers la fin de l'après-midi du jeudi 03 novembre 2005, vers 16:55, "Stephane Catteau" disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire l'inverse, à savoir bloquer tout, et n'autoriser que les cas particuliers, avec un quick cette fois. Actuellement un cas non prévu au manuel sera considéré comme valide, alors que c'est l'inverse qui devrait se passer.
Je commence par block all puis j'ai des pass sur des cas particuliers, puis des block qui restreignent certains des pass en question, dont celui qui nous intéresse (y'a une sous classe de <clients> qui n'a pas le droit de sortir trop).
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles : - Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK, alors faire cela - Si le paquet étudié au niveau de ifipsec est ceci alors on met un tag AUTHOK => Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis lorsque ta règle de redirection sera utilisée.
Oui, oui, c'est bien ce que j'ai dit dans la suite de mon message : le tag ne sert à rien parce que finalement, mon rdr ne peut avoir lieu que sur des paquets non chiffrés, donc faisant le chemin if1 -> if2 donc forcément non taggués.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton problème. Amha tu as ne prend pas le problème dans le bon sens, et tu gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet d'avoir très peu de règles et de ne pas travailler dans l'abstraction pure comme c'est trop souvent le cas avec les autres filtre IP, il serait dommage que tu t'en passes.
Je suis d'accord qu'il faudra que je refasse un jour les règles, ce n'est pas très clair comme c'est actuellement mais je pense que ça fait effectivement ce que je veux. -- BOFH excuse #80: That's a great computer you have there; have you considered how it would work as a BSD machine?
OoO Vers la fin de l'après-midi du jeudi 03 novembre 2005, vers 16:55,
"Stephane Catteau" <steph.nospam@sc4x.net> disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state
pass on $if2 from <clients> to any tagged AUTHOK keep state
Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire
l'inverse, à savoir bloquer tout, et n'autoriser que les cas
particuliers, avec un quick cette fois. Actuellement un cas non prévu
au manuel sera considéré comme valide, alors que c'est l'inverse qui
devrait se passer.
Je commence par block all puis j'ai des pass sur des cas particuliers,
puis des block qui restreignent certains des pass en question, dont
celui qui nous intéresse (y'a une sous classe de <clients> qui n'a pas
le droit de sortir trop).
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http !
tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to
any tag AUTHOK keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles :
- Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK,
alors faire cela
- Si le paquet étudié au niveau de ifipsec est ceci alors on met un
tag AUTHOK
=> Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis
lorsque ta règle de redirection sera utilisée.
Oui, oui, c'est bien ce que j'ai dit dans la suite de mon message : le
tag ne sert à rien parce que finalement, mon rdr ne peut avoir lieu
que sur des paquets non chiffrés, donc faisant le chemin if1 -> if2
donc forcément non taggués.
Mon problème ne se pose donc plus. J'ai essayé de faire trop
compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton
problème. Amha tu as ne prend pas le problème dans le bon sens, et tu
gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet
d'avoir très peu de règles et de ne pas travailler dans l'abstraction
pure comme c'est trop souvent le cas avec les autres filtre IP, il
serait dommage que tu t'en passes.
Je suis d'accord qu'il faudra que je refasse un jour les règles, ce
n'est pas très clair comme c'est actuellement mais je pense que ça
fait effectivement ce que je veux.
--
BOFH excuse #80: That's a great computer you have there; have you
considered how it would work as a BSD machine?
OoO Vers la fin de l'après-midi du jeudi 03 novembre 2005, vers 16:55, "Stephane Catteau" disait:
pass on $ifipsec from <clients> to any tag AUTHOK keep state pass on $if2 from <clients> to any tagged AUTHOK keep state Pas de quick ?
Nope, y'a des block de cas particuliers plus loin.
Pour la règle tagante ok, mais l'autre... En théorie tu devrais faire l'inverse, à savoir bloquer tout, et n'autoriser que les cas particuliers, avec un quick cette fois. Actuellement un cas non prévu au manuel sera considéré comme valide, alors que c'est l'inverse qui devrait se passer.
Je commence par block all puis j'ai des pass sur des cas particuliers, puis des block qui restreignent certains des pass en question, dont celui qui nous intéresse (y'a une sous classe de <clients> qui n'a pas le droit de sortir trop).
J'ai finalement ceci :
rdr on $if1 inet proto tcp from <clients> to ! $monip port http ! tagged AUTHOK -> $monip port http pass on $ifipsec from <clients> to any tag AUTHOK keep state
Euh... Tu es sûr d'avoir if1 -> ifipsec -> if2 ? Regarde tes règles : - Si le paquet étudié au niveau de if1 est ceci et a le tag AUTHOK, alors faire cela - Si le paquet étudié au niveau de ifipsec est ceci alors on met un tag AUTHOK => Si if1 est vraiment avant ifipsec, le tag ne sera pas encore mis lorsque ta règle de redirection sera utilisée.
Oui, oui, c'est bien ce que j'ai dit dans la suite de mon message : le tag ne sert à rien parce que finalement, mon rdr ne peut avoir lieu que sur des paquets non chiffrés, donc faisant le chemin if1 -> if2 donc forcément non taggués.
Mon problème ne se pose donc plus. J'ai essayé de faire trop compliqué. :)
J'ai quand même l'impression que ça ne répond pas tout à fait à ton problème. Amha tu as ne prend pas le problème dans le bon sens, et tu gagnerais à revoir l'ensemble de tes règles. La souplesse de pf permet d'avoir très peu de règles et de ne pas travailler dans l'abstraction pure comme c'est trop souvent le cas avec les autres filtre IP, il serait dommage que tu t'en passes.
Je suis d'accord qu'il faudra que je refasse un jour les règles, ce n'est pas très clair comme c'est actuellement mais je pense que ça fait effectivement ce que je veux. -- BOFH excuse #80: That's a great computer you have there; have you considered how it would work as a BSD machine?
