Soit une solution proxy de filtrage du type SQUID que je veux faire
fonctionner sur un LAN public en DHCP.
Je ne peux configurer automatiquement le proxy des navigateurs web des
clients.
Est il donc possible de le placer en aval du firewall ?
Soit le croquis suivant:
@-----|proxy|-----|firewall|-------|LAN|
Dans ce cas comment cela se paramètrerait il sur le firewall ?
Si je comprends bien, je devrai patcher mon noyau 2.4 pour pouvoir utiliser tout ça (comme dirait l'autre, je passerai à la série 2. 6 quand elle sera stable). Car pour l'instant mon /proc/sys/net/ ne contient pa s de sous-répertoire 'bridge', même quand un bridge est créé.
L'appel aux « hooks » IP de netfilter est automatique dans la versi on 2.4 (pour autant que je me souvienne, car je considère le 2.6 stable pour cette partie là:)) ). Il n'y a pas besoin de jouer avec sysctl.
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n eta nt pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Si je comprends bien, je devrai patcher mon noyau 2.4 pour pouvoir
utiliser tout ça (comme dirait l'autre, je passerai à la série 2. 6 quand
elle sera stable). Car pour l'instant mon /proc/sys/net/ ne contient pa s
de sous-répertoire 'bridge', même quand un bridge est créé.
L'appel aux « hooks » IP de netfilter est automatique dans la versi on
2.4 (pour autant que je me souvienne, car je considère le 2.6 stable
pour cette partie là:)) ). Il n'y a pas besoin de jouer avec sysctl.
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n eta nt pas
encore considere comme stable par leur circuit de validation. il viennent a
peine de mettre le 2.4 en standart :p
Si je comprends bien, je devrai patcher mon noyau 2.4 pour pouvoir utiliser tout ça (comme dirait l'autre, je passerai à la série 2. 6 quand elle sera stable). Car pour l'instant mon /proc/sys/net/ ne contient pa s de sous-répertoire 'bridge', même quand un bridge est créé.
L'appel aux « hooks » IP de netfilter est automatique dans la versi on 2.4 (pour autant que je me souvienne, car je considère le 2.6 stable pour cette partie là:)) ). Il n'y a pas besoin de jouer avec sysctl.
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n eta nt pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Pascal
Content-Transfer-Encoding: quoted-printable
Grmbl. Tu pourrais corriger ça stp ?
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n etant pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus ! La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez attendue, marre d'ipchains), la série 2.6 est dans la Debian stable actuelle. Mais ce n'est pas pour autant que je considère la série 2.6 comme stable (au sens de "stabilisée", pas au sens de "non buggée", hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur. En gros ce que j'attends d'une série de noyaux "stable", c'est que je puisse remplacer une version x.y.z par une version ultérieure x.y.z+n et que tout continue à marcher pareil (ou mieux) sans avoir à changer quoi que ce soit d'autre dans le système. S'il faut changer ou mettre à jour les outils du noyau à chaque nouvelle version, non merci. Je ne suis pas un aventurier.
Sur ce, je viens de me compiler le dernier 2.4.32 pour tester sur ma Sarge. :) Depuis le temps j'avais presque oublié comment on fait, alors pour le 2.6 on verra plus tard.
Content-Transfer-Encoding: quoted-printable
Grmbl. Tu pourrais corriger ça stp ?
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n
etant pas encore considere comme stable par leur circuit de validation.
il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus !
La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez
attendue, marre d'ipchains), la série 2.6 est dans la Debian stable
actuelle. Mais ce n'est pas pour autant que je considère la série 2.6
comme stable (au sens de "stabilisée", pas au sens de "non buggée",
hein). Entre les gros changements dont j'entends parler ici et là (devfs
-> udev, répercussion sur la façon de construire l'initrd même si je
n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4
nombres, avouez que ça fait un peu peur. En gros ce que j'attends d'une
série de noyaux "stable", c'est que je puisse remplacer une version
x.y.z par une version ultérieure x.y.z+n et que tout continue à marcher
pareil (ou mieux) sans avoir à changer quoi que ce soit d'autre dans le
système. S'il faut changer ou mettre à jour les outils du noyau à chaque
nouvelle version, non merci. Je ne suis pas un aventurier.
Sur ce, je viens de me compiler le dernier 2.4.32 pour tester sur ma
Sarge. :) Depuis le temps j'avais presque oublié comment on fait, alors
pour le 2.6 on verra plus tard.
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n etant pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus ! La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez attendue, marre d'ipchains), la série 2.6 est dans la Debian stable actuelle. Mais ce n'est pas pour autant que je considère la série 2.6 comme stable (au sens de "stabilisée", pas au sens de "non buggée", hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur. En gros ce que j'attends d'une série de noyaux "stable", c'est que je puisse remplacer une version x.y.z par une version ultérieure x.y.z+n et que tout continue à marcher pareil (ou mieux) sans avoir à changer quoi que ce soit d'autre dans le système. S'il faut changer ou mettre à jour les outils du noyau à chaque nouvelle version, non merci. Je ne suis pas un aventurier.
Sur ce, je viens de me compiler le dernier 2.4.32 pour tester sur ma Sarge. :) Depuis le temps j'avais presque oublié comment on fait, alors pour le 2.6 on verra plus tard.
TiChou
Dans le message <news:dmichm$282k$, ** tapota sur f.c.o.l.configuration :
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n etant pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus ! La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez attendue, marre d'ipchains), la série 2.6 est dans la Debian stable actuelle. Mais ce n'est pas pour autant que je considère la série 2.6 comme stable (au sens de "stabilisée", pas au sens de "non buggée", hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur. En gros ce que j'attends d'une série de noyaux "stable", c'est que je puisse remplacer une version x.y.z par une version ultérieure x.y.z+n et que tout continue à marcher pareil (ou mieux) sans avoir à changer quoi que ce soit d'autre dans le système. S'il faut changer ou mettre à jour les outils du noyau à chaque nouvelle version, non merci. Je ne suis pas un aventurier.
Tout pareil !
-- TiChou
Dans le message <news:dmichm$282k$1@biggoron.nerim.net>,
*Pascal@plouf* tapota sur f.c.o.l.configuration :
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n
etant pas encore considere comme stable par leur circuit de validation.
il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus !
La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez
attendue, marre d'ipchains), la série 2.6 est dans la Debian stable
actuelle. Mais ce n'est pas pour autant que je considère la série 2.6
comme stable (au sens de "stabilisée", pas au sens de "non buggée", hein).
Entre les gros changements dont j'entends parler ici et là (devfs -> udev,
répercussion sur la façon de construire l'initrd même si je n'utilise ni
l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça
fait un peu peur. En gros ce que j'attends d'une série de noyaux "stable",
c'est que je puisse remplacer une version x.y.z par une version ultérieure
x.y.z+n et que tout continue à marcher pareil (ou mieux) sans avoir à
changer quoi que ce soit d'autre dans le système. S'il faut changer ou
mettre à jour les outils du noyau à chaque nouvelle version, non merci. Je
ne suis pas un aventurier.
Dans le message <news:dmichm$282k$, ** tapota sur f.c.o.l.configuration :
je pense au qu il veut dire stable au sens de debian. le kernel 2.6 n etant pas encore considere comme stable par leur circuit de validation. il viennent a peine de mettre le 2.4 en standart :p
Eh, oh, il ne faudrait pas exagérer non plus ! La série 2.4 était déjà dans l'ancienne Debian stable (je l'ai assez attendue, marre d'ipchains), la série 2.6 est dans la Debian stable actuelle. Mais ce n'est pas pour autant que je considère la série 2.6 comme stable (au sens de "stabilisée", pas au sens de "non buggée", hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur. En gros ce que j'attends d'une série de noyaux "stable", c'est que je puisse remplacer une version x.y.z par une version ultérieure x.y.z+n et que tout continue à marcher pareil (ou mieux) sans avoir à changer quoi que ce soit d'autre dans le système. S'il faut changer ou mettre à jour les outils du noyau à chaque nouvelle version, non merci. Je ne suis pas un aventurier.
Tout pareil !
-- TiChou
Matthieu Moy
"" writes:
hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps. Il n'a pas ouvert de branche 2.7, donc des changements majeurs sont intégrés petit à petit dans la branche 2.6 (les outils de gestion de version décentralisés aidant à tester les modifs dans d'autres branches avant de les mettre dans la branche officielle). Si tu veux une branche "stable" au sens "qui bouge pas", il faut regarder le "y" dans 2.6.x.y, ou choisir une distribution qui backporte des bugs dans sa version stable du noyau.
L'intérêt est que le développement va vite. Les inconvénients, c'est ceux que tu as cités.
hein). Entre les gros changements dont j'entends parler ici et là
(devfs -> udev, répercussion sur la façon de construire l'initrd même
si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4
nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps. Il n'a pas ouvert
de branche 2.7, donc des changements majeurs sont intégrés petit à
petit dans la branche 2.6 (les outils de gestion de version
décentralisés aidant à tester les modifs dans d'autres branches avant
de les mettre dans la branche officielle). Si tu veux une branche
"stable" au sens "qui bouge pas", il faut regarder le "y" dans
2.6.x.y, ou choisir une distribution qui backporte des bugs dans sa
version stable du noyau.
L'intérêt est que le développement va vite. Les inconvénients, c'est
ceux que tu as cités.
hein). Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps. Il n'a pas ouvert de branche 2.7, donc des changements majeurs sont intégrés petit à petit dans la branche 2.6 (les outils de gestion de version décentralisés aidant à tester les modifs dans d'autres branches avant de les mettre dans la branche officielle). Si tu veux une branche "stable" au sens "qui bouge pas", il faut regarder le "y" dans 2.6.x.y, ou choisir une distribution qui backporte des bugs dans sa version stable du noyau.
L'intérêt est que le développement va vite. Les inconvénients, c'est ceux que tu as cités.
-- Matthieu
Pascal
"" writes:
Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps.
Je sais, et je ne critique pas. Je dis juste que ce n'est pas pour moi. Si ça se trouve la série 2.4 a aussi subi des changements aussi importants au cours de son histoire, mais comme j'ai commencé à l'utiliser à partir de la version 2.4.18, je ne l'ai pas vu.
[...] Si tu veux une branche "stable" au sens "qui bouge pas", il faut regarder le "y" dans 2.6.x.y,
Que veux-tu dire ?
ou choisir une distribution qui backporte des bugs dans sa version stable du noyau.
Entre les gros changements dont j'entends parler ici et là
(devfs -> udev, répercussion sur la façon de construire l'initrd même
si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4
nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps.
Je sais, et je ne critique pas. Je dis juste que ce n'est pas pour moi.
Si ça se trouve la série 2.4 a aussi subi des changements aussi
importants au cours de son histoire, mais comme j'ai commencé à
l'utiliser à partir de la version 2.4.18, je ne l'ai pas vu.
[...] Si tu veux une branche "stable" au sens "qui bouge pas",
il faut regarder le "y" dans 2.6.x.y,
Que veux-tu dire ?
ou choisir une distribution qui backporte des bugs dans sa
version stable du noyau.
Entre les gros changements dont j'entends parler ici et là (devfs -> udev, répercussion sur la façon de construire l'initrd même si je n'utilise ni l'un ni l'autre) et les sous-sous-sous-versions à 4 nombres, avouez que ça fait un peu peur.
C'est la politique de Linus depuis quelques temps.
Je sais, et je ne critique pas. Je dis juste que ce n'est pas pour moi. Si ça se trouve la série 2.4 a aussi subi des changements aussi importants au cours de son histoire, mais comme j'ai commencé à l'utiliser à partir de la version 2.4.18, je ne l'ai pas vu.
[...] Si tu veux une branche "stable" au sens "qui bouge pas", il faut regarder le "y" dans 2.6.x.y,
Que veux-tu dire ?
ou choisir une distribution qui backporte des bugs dans sa version stable du noyau.
# Le noyau (2.0.29, 2.0.31 et plus) doit être compilé avec les options [...] CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_ALWAYS_DEFRAG=y [...] ipfwadm -I -a accept -W lo
Salut à tous!
J'ai un problème qui m'embarrasse vraiment, j'ai vu des question du genre sur le site, mais je n'ai pas trouvé une problématique vraiment semblable à la mienne. je vous prie de m'aider du mieux que vous pouvez. Merci d'avance.
En effet, j'ai un appliance Linux faisant office de proxy pour mon réseau interne. Cette machine permet également via le nat, à mes utilisateurs internes d'aller sur internet et à mes utilisateurs externes de se connecter aux serveurs internes suivant des règles définies sur le firewall/proxy. Pour les connexions depuis l'extérieur, je dispose d'une plage d'adresses publique de mon FAI et pour chaque serveur interne accessible depuis l'extérieur, j'ai fait un DNAT sur une adresse publique spécifique.
Pour se connecter à internet, le firewall sert de mes passerelle pour les utilisateurs internes, et pour se connecter à mes serveurs depuis l'extérieur, mes utilisateurs disposent d'une adresse publique pour chaque serveur qui sera ensuite NATée sur l'adresse privée du serveur concerné.
J'ai une deuxième connexion internet aujourd'hui voici ma problématique:
- Je veux mettre en entrée de mon réseau un routeur Linux qui va gérer le loadbalancing/failover pour les connexion sortantes
- Derrière le routeur se trouvera mon firewall/proxy qui gère le réseau interne
-Comment pourrait-je permettre au routeur de router les requêtes des utilisateurs externes vers le proxy, et en suite du proxy vers les serveurs internes concernés?
- Pourrais-je toujours faire de la redirection d'adresses publiques avec désormais la carte externe de mon firewall sur une adresse privée? Ou alors à ce niveau c'est une redirection de port qui s'impose? Si oui petit détail
- Si je pourrai faire de la redirection d'adresses publiques pour les connexions depuis l'extérieur, est-ce que je pourrai utiliser mes deux plages d'adresses publiques? (Mon nouveau FAI m'as également donnée une plage d'adresses publiques)
- Enfin comment puis-je efficacement gérer les accès depuis l'extérieur avec mes deux connexions internet? Laisser seul le firewall pourqu'il gère le trafic entrant et sortant, et le loadbalancing/failover? Si oui comment. Placer mon routeur debian configuré pour le loaadbalancing/failover en entrée? Dans ce cas comment gérer l'accès au serveurs derrière le firewall depuis l'extérieur?
Des explications théorique mais techniques et des précisions sur la topologie à adopter pourraient m'apporter une meilleure vision que des commandes iptables et autres à entrée, car je m'en sors assez bien à ce niveau. Toutefois donnez moi toute ce que vous pensez pouvoir m'être utile.
Vous avez ci-joint un petit schéma de l'architecture que je prévois, et j'attends vos objections et propositions.
Je précise que je n'ai aucun problème pour l'implémentation du loadbalancing/failover en sortie; j'ai déjà développé les scripts sur mon routeur Linux Debian, mais je ne sais pas comment le placer en production afin qu'il cohabite avec mon firewall.
# Le noyau (2.0.29, 2.0.31 et plus) doit être compilé avec les
options
[...]
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
[...]
ipfwadm -I -a accept -W lo
Salut à tous!
J'ai un problème qui m'embarrasse vraiment, j'ai vu des question du genre sur le site, mais je n'ai pas trouvé une problématique vraiment semblable à la mienne.
je vous prie de m'aider du mieux que vous pouvez. Merci d'avance.
En effet, j'ai un appliance Linux faisant office de proxy pour mon réseau interne. Cette machine permet également via le nat, à mes utilisateurs internes d'aller sur internet et à mes utilisateurs externes de se connecter aux serveurs internes suivant des règles définies sur le firewall/proxy.
Pour les connexions depuis l'extérieur, je dispose d'une plage d'adresses publique de mon FAI et pour chaque serveur interne accessible depuis l'extérieur, j'ai fait un DNAT sur une adresse publique spécifique.
Pour se connecter à internet, le firewall sert de mes passerelle pour les utilisateurs internes, et pour se connecter à mes serveurs depuis l'extérieur, mes utilisateurs disposent d'une adresse publique pour chaque serveur qui sera ensuite NATée sur l'adresse privée du serveur concerné.
J'ai une deuxième connexion internet aujourd'hui voici ma problématique:
- Je veux mettre en entrée de mon réseau un routeur Linux qui va gérer le loadbalancing/failover pour les connexion sortantes
- Derrière le routeur se trouvera mon firewall/proxy qui gère le réseau interne
-Comment pourrait-je permettre au routeur de router les requêtes des utilisateurs externes vers le proxy, et en suite du proxy vers les serveurs internes concernés?
- Pourrais-je toujours faire de la redirection d'adresses publiques avec désormais la carte externe de mon firewall sur une adresse privée? Ou alors à ce niveau c'est une redirection de port qui s'impose? Si oui petit détail
- Si je pourrai faire de la redirection d'adresses publiques pour les connexions depuis l'extérieur, est-ce que je pourrai utiliser mes deux plages d'adresses publiques? (Mon nouveau FAI m'as également donnée une plage d'adresses publiques)
- Enfin comment puis-je efficacement gérer les accès depuis l'extérieur avec mes deux connexions internet? Laisser seul le firewall pourqu'il gère le trafic entrant et sortant, et le loadbalancing/failover? Si oui comment. Placer mon routeur debian configuré pour le loaadbalancing/failover en entrée? Dans ce cas comment gérer l'accès au serveurs derrière le firewall depuis l'extérieur?
Des explications théorique mais techniques et des précisions sur la topologie à adopter pourraient m'apporter une meilleure vision que des commandes iptables et autres à entrée, car je m'en sors assez bien à ce niveau. Toutefois donnez moi toute ce que vous pensez pouvoir m'être utile.
Vous avez ci-joint un petit schéma de l'architecture que je prévois, et j'attends vos objections et propositions.
Je précise que je n'ai aucun problème pour l'implémentation du loadbalancing/failover en sortie; j'ai déjà développé les scripts sur mon routeur Linux Debian, mais je ne sais pas comment le placer en production afin qu'il cohabite avec mon firewall.
# Le noyau (2.0.29, 2.0.31 et plus) doit être compilé avec les options [...] CONFIG_IP_TRANSPARENT_PROXY=y CONFIG_IP_ALWAYS_DEFRAG=y [...] ipfwadm -I -a accept -W lo
Salut à tous!
J'ai un problème qui m'embarrasse vraiment, j'ai vu des question du genre sur le site, mais je n'ai pas trouvé une problématique vraiment semblable à la mienne. je vous prie de m'aider du mieux que vous pouvez. Merci d'avance.
En effet, j'ai un appliance Linux faisant office de proxy pour mon réseau interne. Cette machine permet également via le nat, à mes utilisateurs internes d'aller sur internet et à mes utilisateurs externes de se connecter aux serveurs internes suivant des règles définies sur le firewall/proxy. Pour les connexions depuis l'extérieur, je dispose d'une plage d'adresses publique de mon FAI et pour chaque serveur interne accessible depuis l'extérieur, j'ai fait un DNAT sur une adresse publique spécifique.
Pour se connecter à internet, le firewall sert de mes passerelle pour les utilisateurs internes, et pour se connecter à mes serveurs depuis l'extérieur, mes utilisateurs disposent d'une adresse publique pour chaque serveur qui sera ensuite NATée sur l'adresse privée du serveur concerné.
J'ai une deuxième connexion internet aujourd'hui voici ma problématique:
- Je veux mettre en entrée de mon réseau un routeur Linux qui va gérer le loadbalancing/failover pour les connexion sortantes
- Derrière le routeur se trouvera mon firewall/proxy qui gère le réseau interne
-Comment pourrait-je permettre au routeur de router les requêtes des utilisateurs externes vers le proxy, et en suite du proxy vers les serveurs internes concernés?
- Pourrais-je toujours faire de la redirection d'adresses publiques avec désormais la carte externe de mon firewall sur une adresse privée? Ou alors à ce niveau c'est une redirection de port qui s'impose? Si oui petit détail
- Si je pourrai faire de la redirection d'adresses publiques pour les connexions depuis l'extérieur, est-ce que je pourrai utiliser mes deux plages d'adresses publiques? (Mon nouveau FAI m'as également donnée une plage d'adresses publiques)
- Enfin comment puis-je efficacement gérer les accès depuis l'extérieur avec mes deux connexions internet? Laisser seul le firewall pourqu'il gère le trafic entrant et sortant, et le loadbalancing/failover? Si oui comment. Placer mon routeur debian configuré pour le loaadbalancing/failover en entrée? Dans ce cas comment gérer l'accès au serveurs derrière le firewall depuis l'extérieur?
Des explications théorique mais techniques et des précisions sur la topologie à adopter pourraient m'apporter une meilleure vision que des commandes iptables et autres à entrée, car je m'en sors assez bien à ce niveau. Toutefois donnez moi toute ce que vous pensez pouvoir m'être utile.
Vous avez ci-joint un petit schéma de l'architecture que je prévois, et j'attends vos objections et propositions.
Je précise que je n'ai aucun problème pour l'implémentation du loadbalancing/failover en sortie; j'ai déjà développé les scripts sur mon routeur Linux Debian, mais je ne sais pas comment le placer en production afin qu'il cohabite avec mon firewall.
