j'ai un serveur que je voudrai transf=C3=A9rer petit =C3=A0 petit, que je p=
eux pas
vraiment toucher pour d'obscures raisons...
il est en 192.168.100.10, et je ne peux pas toucher son IP. dessus, j'ai
plein de services, que je voudrais transf=C3=A9rer (et =C3=A9clater) sur d'=
autres
b=C3=A9canes.
donc, je me dis que le moment est venu de tester pf en vrai. je monte
une petite machine avec openbsd, dont l'objectif est juste de r=C3=A9cup=C3=
=A9rer
l'ip .10 (plus tard) et de faire du forward de port, d'abord tout sur la
m=C3=AAme machine, puis diviser les services diff=C3=A9rents sur des machin=
es
diff=C3=A9rentes...
je me retrouve donc avec le fichier de conf pf suivant :
-----------------------------------------
set skip on lo
# pour le forward des ports : machines
gw_addr =3D "192.168.100.13"
http_srv =3D "192.168.100.10"
# on laisse tout sortir, keep state
pass out all keep state
# By default, do not permit remote connections except from our networks
block in on ! lo0 from any to any
pass in on $if from $our_networks to any
#pass in quick on $if proto tcp from any to $gw_addr port 80 rdr-to $http_s=
rv port 80
#pass in quick on $if proto tcp from any to $gw_addr port 443 rdr-to $http_=
srv port 443
rdr pass on $if proto tcp to port 80 -> $http_srv port 80
rdr pass on $if proto tcp to port 443 -> $http_srv port 443
-----------------------------------------
j'ai essay=C3=A9 avec les deux lignes pass comment=C3=A9es, sans r=C3=A9sul=
tat ; plus
exactement, le tcpdump voit passer des choses du genre (.0.50 est mon IP) :
16:13:47.635943 192.168.0.50.31788 > 192.168.100.13.80[...]
16:13:47.635989 192.168.0.50.31788 > 192.168.100.10.80[...]
mais rien de plus. les lignes avec rdr font des syntax error...
j'ai bien pens=C3=A9 =C3=A0 activer le net.inet.ip.forwarding, et je suis a=
vec un
OpenBSD 5.0 tout frais install=C3=A9.
de ce que j'ai vu comme doc, ce genre de trucs fonctionne tr=C3=A8s bien av=
ec
du NAT, mais j'ai trouv=C3=A9 personne qui veut le faire comme moi, sur un
r=C3=A9seau =C3=A0 plat...
quelqu'un aurait une id=C3=A9e pour que je puisse avancer ?
merci,
--=20
Mais j'aime pas Metapost, j'abhorre m=C3=A9tapost, j'y peu rien, j'suis
allergique, =C3=A7a me gratouille, dans les doigts rien que d'=C3=A9crire le
nom.
-+- Olivier R. in fr.comp.text.tex -+-
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
Patrick Lamaizière
Thomas vO :
bonjour,
Yo,
block in on ! lo0 from any to any
Pour pas un simple "block all" ? C'est de bon ton (on bloque tout), et tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est changée, mais pas l'adresse source. Le serveur destinataire va répondre au client qui n'attend pas de réponse de ce serveur (pas la même ip) et drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et si tu as des contrôles sur l'IP ce n'est pas top, de même pour la tracabilité. Mais ça marche et c'est simple, je suis en train de tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS internes (pour éviter des attaques aux niveaux des clients qui changent l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne sont pas pour elle, il faut agir au niveau du pare-feu (local) pour rediriger les paquets. Tu trouveras des exemples pour cela dans des conf de squid en proxy transparent.
Si tu ne peux pas où ne veux pas agir au niveau du serveur en local, il y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler de ton réseau en ajoutant une interface et si nécessaire une machine en tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon ----- serveur
Dans ce cas tu aurais des règles du genre : pass in iface0 from any to self port XXX route-to (iface1 ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la machine tampon, qui doit alors router vers ton serveur. Sur ton serveur tu n'as plus qu'à configurer une route par défaut vers tampon (et configurer le routage de celle ci). De cette manière ça peut-être complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la main, faut regarder. Je ne sais pas comment va comporter le routage avec des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Thomas vO :
bonjour,
Yo,
block in on ! lo0 from any to any
Pour pas un simple "block all" ? C'est de bon ton (on bloque tout), et
tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est
changée, mais pas l'adresse source. Le serveur destinataire va répondre
au client qui n'attend pas de réponse de ce serveur (pas la même ip) et
drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT
rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse
du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et
si tu as des contrôles sur l'IP ce n'est pas top, de même pour
la tracabilité. Mais ça marche et c'est simple, je suis en train de
tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS
internes (pour éviter des attaques aux niveaux des clients qui changent
l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers
ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination
sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne
sont pas pour elle, il faut agir au niveau du pare-feu (local) pour
rediriger les paquets. Tu trouveras des exemples pour cela dans des conf
de squid en proxy transparent.
Si tu ne peux pas où ne veux pas agir au niveau du serveur en local, il
y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler
de ton réseau en ajoutant une interface et si nécessaire une machine en
tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon -----
serveur
Dans ce cas tu aurais des règles du genre :
pass in iface0 from any to self port XXX route-to (iface1
ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la
machine tampon, qui doit alors router vers ton serveur. Sur ton serveur
tu n'as plus qu'à configurer une route par défaut vers tampon (et
configurer le routage de celle ci). De cette manière ça peut-être
complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la
main, faut regarder. Je ne sais pas comment va comporter le routage avec
des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Pour pas un simple "block all" ? C'est de bon ton (on bloque tout), et tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est changée, mais pas l'adresse source. Le serveur destinataire va répondre au client qui n'attend pas de réponse de ce serveur (pas la même ip) et drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et si tu as des contrôles sur l'IP ce n'est pas top, de même pour la tracabilité. Mais ça marche et c'est simple, je suis en train de tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS internes (pour éviter des attaques aux niveaux des clients qui changent l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne sont pas pour elle, il faut agir au niveau du pare-feu (local) pour rediriger les paquets. Tu trouveras des exemples pour cela dans des conf de squid en proxy transparent.
Si tu ne peux pas où ne veux pas agir au niveau du serveur en local, il y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler de ton réseau en ajoutant une interface et si nécessaire une machine en tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon ----- serveur
Dans ce cas tu aurais des règles du genre : pass in iface0 from any to self port XXX route-to (iface1 ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la machine tampon, qui doit alors router vers ton serveur. Sur ton serveur tu n'as plus qu'à configurer une route par défaut vers tampon (et configurer le routage de celle ci). De cette manière ça peut-être complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la main, faut regarder. Je ne sais pas comment va comporter le routage avec des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Patrick Lamaizière
supersedes, manque des mots :(
Thomas vO :
bonjour,
Yo,
block in on ! lo0 from any to any
Pourquoi pas un simple "block all" ? C'est de bon ton (on bloque tout), et tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est changée, mais pas l'adresse source. Le serveur destinataire va répondre au client qui n'attend pas de réponse de ce serveur (pas la même ip) et drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et si tu as des contrôles sur l'IP ce n'est pas top, de même pour la tracabilité. Mais ça marche et c'est simple, je suis en train de tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS internes (pour éviter des attaques aux niveaux des clients qui changent l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne sont pas pour elle, il faut agir au niveau du pare-feu (local) pour rediriger les paquets. Tu trouveras des exemples pour cela dans des conf de squid en proxy transparent.
Si tu ne peux pas, ou ne veux pas agir au niveau du serveur en local, il y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler de ton réseau en ajoutant une interface et si nécessaire une machine en tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon ----- serveur
Dans ce cas tu aurais des règles du genre : pass in iface0 from any to self port XXX route-to (iface1 ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la machine tampon, qui doit alors router vers ton serveur. Sur ton serveur tu n'as plus qu'à configurer une route par défaut vers tampon (et configurer le routage de celle ci). De cette manière ça peut-être complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la main, faut regarder. Je ne sais pas comment va se comporter le routage avec des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
supersedes, manque des mots :(
Thomas vO :
bonjour,
Yo,
block in on ! lo0 from any to any
Pourquoi pas un simple "block all" ? C'est de bon ton (on bloque tout),
et tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est
changée, mais pas l'adresse source. Le serveur destinataire va répondre
au client qui n'attend pas de réponse de ce serveur (pas la même ip) et
drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT
rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse
du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et
si tu as des contrôles sur l'IP ce n'est pas top, de même pour
la tracabilité. Mais ça marche et c'est simple, je suis en train de
tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS
internes (pour éviter des attaques aux niveaux des clients qui changent
l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers
ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination
sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne
sont pas pour elle, il faut agir au niveau du pare-feu (local) pour
rediriger les paquets. Tu trouveras des exemples pour cela dans des conf
de squid en proxy transparent.
Si tu ne peux pas, ou ne veux pas agir au niveau du serveur en local, il
y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler
de ton réseau en ajoutant une interface et si nécessaire une machine en
tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon -----
serveur
Dans ce cas tu aurais des règles du genre :
pass in iface0 from any to self port XXX route-to (iface1
ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la
machine tampon, qui doit alors router vers ton serveur. Sur ton serveur
tu n'as plus qu'à configurer une route par défaut vers tampon (et
configurer le routage de celle ci). De cette manière ça peut-être
complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la
main, faut regarder. Je ne sais pas comment va se comporter le routage
avec des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
Pourquoi pas un simple "block all" ? C'est de bon ton (on bloque tout), et tu skip lo0 de toutes façons.
...
Le problème de la redirection c'est que l'adresse destination est changée, mais pas l'adresse source. Le serveur destinataire va répondre au client qui n'attend pas de réponse de ce serveur (pas la même ip) et drop le paquet. La solution c'est de nater en sortie :
Quelque chose du genre :
pass in quick inet proto tcp from any to self port XXX tag TREDIRECT rdr-to ip_du_serveur
pass out quick tagged TREDIRECT nat-to ip_du_pf
Ainsi PF va remplacer l'adresse source par la sienne, lors de la réponse du serveur il fait l'inverse et le client n'y voit que du feu.
Inconvénient (de taille) : le serveur voit les demandes depuis le PF et si tu as des contrôles sur l'IP ce n'est pas top, de même pour la tracabilité. Mais ça marche et c'est simple, je suis en train de tester cela pour rediriger les flux DNS sortants vers nos serveurs DNS internes (pour éviter des attaques aux niveaux des clients qui changent l'adresse des DNS)
Une autre solution serait peut-être d'utiliser route-to pour router vers ton nouveau serveur.
Avantage : on ne touche pas au paquet, les adresse source et destination sont conservées.
Inconvénient : la machine serveur va voir arriver des paquets qui ne sont pas pour elle, il faut agir au niveau du pare-feu (local) pour rediriger les paquets. Tu trouveras des exemples pour cela dans des conf de squid en proxy transparent.
Si tu ne peux pas, ou ne veux pas agir au niveau du serveur en local, il y a peut-être la possibilité de garder l'ip du serveur, mais de l'isoler de ton réseau en ajoutant une interface et si nécessaire une machine en tampon et de jouer sur les routes.
lan -------(iface0)PF(iface1) (route to tampon)---- machine tampon ----- serveur
Dans ce cas tu aurais des règles du genre : pass in iface0 from any to self port XXX route-to (iface1 ip_machine_tampon)
Ce qui veut dire que tu routes les requetes vers le port XXX vers la machine tampon, qui doit alors router vers ton serveur. Sur ton serveur tu n'as plus qu'à configurer une route par défaut vers tampon (et configurer le routage de celle ci). De cette manière ça peut-être complètement transparent ama.
On peut peut-être éviter une machine tampon en ajoutant des routes à la main, faut regarder. Je ne sais pas comment va se comporter le routage avec des IP identiques sur deux réseaux "directly connected"
Voilà, c'est l'idée je n'ai pas du tout tester les règles.
