Jusqu'il y a peu de temps, notre r�seau �tait reli� au r�seau global via PPP par un modem. Avec cette configuration, j'avais install� un pare-feu utilisant IPChains et cela fonctionnait correctement. Nous avons r�cemment �volu� vers une configuration DSL. Je pensais que ce serait une bagatelle de simplement basculer mon pare-feu de fa�on � ce qu'il m'isole du r�seau entrant associ� � la connexion DSL. J'avais tort. J'ai mis trois jours avant de parvenir � un r�sultat op�rationnel. J'ai trouv� beaucoup d'informations douteuses sur le r�seau qui m'ont procur� bien du d�sarroi. Ce mini-HOWTO a �t� �crit parce que je soup�onnais que notre installation serait plut�t banale dans le futur avec l'extansion de DSL et que je souhaitais aider les autres � s'�pargner une importante frustration.
Je pense que ceci est applicable � une connexion modem-c�ble mais ��c'est vous qui voyez�� dans la mesure o� je ne connais rien aux liaisons par modem-c�ble.
Le probl�me que je tente de r�soudre est de de configurer le syst�me de fa�on � ce que le code du pare-feu dans le noyau (qui est manipul� par ipchains) soit utilisable pour filtrer les paquets qui vont et viennent entre le monde ext�rieur et le r�seau local. J'avais �galement besoin que certaines machines locales soient ��vues�� du r�seau global (bien que filtr�es au travers du pare-feu de mani�re permanente). Ceci �liminait le masquage IP (voir le IP Masquerade HOWTO) qui, autrement, serait probablement une solution plus ais�e. Ce n'est pas si simple qu'il y para�t.
Pour arriver � notre but d'isoler un r�seau local du r�seau global (sur DSL) en utilisant notre linuxette, nous utiliserons deux cartes ethernet (NIC). Une de ces cartes est connect�e au r�seau local, l'autre au r�seau global. La seule machine qui peut directement communiquer avec l'ext�rieur est la machine Linux. Toutes les autres machines de notre r�seau local doivent passer par cette derni�re (pare-feu).
La configuration logicielle consiste en r�soudre deux probl�mes�:
router les paquets entre les r�seaux local et global (pontage)�;
filtrer les paquets pour en stopper certains lorsqu'ils transitent par le pare-feu.
Le Bridging mini-Howto) donne des instructions d�taill�es en ce qui concerne le premier probl�me de routage des paquets entre les deux parties du r�seau (local et global). Ceci fonctionne en positionnant les deux cartes ethernet sur le mode ��promiscuous�� de fa�on � ce qu'elles d�tectent les paquets sur chacune des interfaces et transf�rent ceux-ci quand ils appartiennent � l'autre c�t�. Ceci se fait de mani�re transparente�: les autres ordinateurs sur le r�seau ne voient m�me pas le pont, car celui-ci n'a m�me pas d'adresse IP. Mais cela ne r�sout pas totalement le probl�me. Je voulais que le pare-feu ait une adresse IP (du moins pour l'administrer � distance) et, plus ennuyeux, le code du pont dans le noyau interceptait et transf�rait les paquets AVANT qu'ils ne parviennent au code du pare-feu ce qui faisait que celui-ci n'avait aucun effet. Vous pouvez alternativement attribuer des adresses IP � vos cartes et continuer � les utiliser comme un pont. Bien que le Bridging mini-Howto ne le fait pas (en r�alit�, il utilise l'adresse de loopback), cela fonctionne bien. Cela r�sout un probl�me. En ce qui concerne le pare-feu, on se tourne vers une rustine sympa pour le noyau � http://ac2i.tzo.com/bridge_filter/ qui fait en sorte que les r�gles du pare-feu soient invoqu�es pour les paquets qui ont travers� le pont avec une nouvelle r�gle ��bridgein��.
Ce mini-HOWTO a pour but de vous aider � prendre en mains la situation o� vous avez une machine Linux configur�e comme une passerelle/pare-feu. Le syst�me a deux cartes r�seau. L'une des cartes est connect�e au monde ext�rieur (dans notre cas, un modem DSL) et rien d'autre. L'autre carte est connect�e � notre r�seau local.
Notez que je n'ai eu d'exp�rience de ceci que sur mon i386 (ABIT BP6 MOBO, w/2 c�l�ron) avec une RedHat 6.0, un noyau 2.2.13, un modem DSL connect� � un routeur et deux cartes Net Gear FA310TX. Votre cas peut �tre diff�rent.
Notez �galement que la d�marche propos�e laissera votre r�seau ouvert � des attaques �ventuelles au d�marrage (avant que le pare-feu ne soit activ�). Si vous �tes tr�s parano�aque, vous devrez prendre des mesures pour �viter ceci.
J'ai trouv� pas mal d'informations sur internet que j'ai utilis�e pour faire fonctionner les choses. Une partie de cette information �tait utile mais inappropri�e.
Le Bridging mini-HOWTO a jou� un r�le d�cisif pour la mise en œuvre. Malheureusement sa seule utilisation ne permet pas de mettre en place un pare-feu.
Le Linux Bridge+Firewall mini-HOWTO) me paraissait, au premier abord, �tre pile ce dont j'avais besoin. N�anmoins, il s'av�re que je pense qu'il est inappropri�. J'ai obtenu un fonctionnement relatif mais, en fin de compte, je me suis aper�u qu'il n'�tait pas n�cessaire de scinder notre sous-r�seau en deux comme il le pr�conise et je n'utiliserai pas cette m�thode. Si vous tombez sur ce document, consid�rez-le avec des r�serves.
La rustine Bridge Filter est la cl� pour obtenir un bon fonctionnement de l'ensemble. Assez bizarrement, l'information sur la page web vous redirige vers le Bridge+Firewall mini-HOWTO. Vous n'avez pas besoin de mettre en œuvre les indications du Bridge+Firewall mini-HOWTO pour obtenir que les choses fonctionnent. Vous aurez besoin de cette rustine.
Le IPCHAINS HOWTO est essentiel pour la mise en œuvre du pare-feu en lui-m�me. Je ne traiterai pas de l'installation du pare-feu dans ce document�; seules les choses qui diff�rent en raison de la mise en œuvre du pontage seront abord�es.
Hosting by: Hurra Communications GmbH
Generated: 2007-01-26 18:01:34