créer passerelle/firewall entre deux cartes réseaux

Support Debian
#1

Bonjour,

Sur un serveur, j’ai deux cartes réseaux :

  • 1ere carte adressée en 10.1.0.2/16, gateway : 10.1.0.250
  • 2nd carte adressée en 10.100.0.2/16, gateway : aucune

J’ai des PC sur les réseaux 10.1.x.x et 10.100.x.x.
J’aimerais que les PC en 10.1.x.x puisse accéder aux PC en 10.100.x.x mais que l’inverse ne soit pas possible.

Remarque : j’ai un troisième réseau en 10.0.x.x qui est relié au réseau 10.1.x.x par un firewall:

  • LAN1 : 10.0.x.x, ip du firewall 10.0.200.250
  • LAN2 : 10.1.x.x, ip du firewall 10.1.200.250
    => le firewall est configuré pour que LAN1 est accès à LAN2 mais pas l’inverse.
    => le port WAN du firewall (192.168.1.2) est connecté à une box internet (192.168.1.250).
    => J’aimerais que les machines en 10.0.x.x puisse aussi accéder au machine en 10.100.x.x.

Est-ce faisable ? Si oui, comment faire ?

Merci d’avance

#2

Voici ce que pour le moment j’ai fait

J’ai créé le fichier /etc/init.d/firewall (chmod +x)

[code]#!/bin/bash

vide les tables

iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
echo iptables clear [OK]

activation du forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

règles de routage

iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1.1000 -j MASQUERADE

echo iptables rules created [OK][/code]

=> Mais ça ne fonctionne pas T_T … je n’arrive pas à pinguer une machine en 10.100.x.x depuis 10.0.200.x (depuis mon serveur j’arrive à pinguer ces machines)
=> Depuis 10.0.200.x, j’arrive bien a pinguer mon serveur en 10.1.0.2

#3

Avant de s’attaquer aux règles iptables, je suggère de vérifier si les tables de routage des différentes machines contiennent toutes les routes nécessaires pour joindre les différentes destinations.

#4

ça semble bon.

Ping depuis le serveur fonctionne :

ping 10.100.0.10 PING 10.100.0.10 (10.100.0.10) 56(84) bytes of data. 64 bytes from 10.100.0.10: icmp_req=1 ttl=100 time=0.374 ms 64 bytes from 10.100.0.10: icmp_req=2 ttl=100 time=0.196 ms 64 bytes from 10.100.0.10: icmp_req=3 ttl=100 time=0.218 ms

Ping depuis 10.0.200.72 ne fonctionne pas :

[code]ping 10.100.0.10

Envoi d’une requête ‘Ping’ 10.100.0.10 avec 32 octets de données :
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.
Délai d’attente de la demande dépassé.[/code]

Sur l’interface entrante de mon serveur, j’ai fait une capture de ping provenant de 10.0.200.72 :

sudo tcpdump -i eth0 icmp -v tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 09:24:32.216930 IP (tos 0x0, ttl 127, id 26211, offset 0, flags [none], proto ICMP (1), l ength 60) 10.0.200.72 > 10.100.0.10: ICMP echo request, id 1, seq 44, length 40 09:24:36.979666 IP (tos 0x0, ttl 127, id 26213, offset 0, flags [none], proto ICMP (1), length 60) 10.0.200.72 > 10.100.0.10: ICMP echo request, id 1, seq 45, length 40 09:24:41.971924 IP (tos 0x0, ttl 127, id 26214, offset 0, flags [none], proto ICMP (1), length 60) 10.0.200.72 > 10.100.0.10: ICMP echo request, id 1, seq 46, length 40 09:24:46.979690 IP (tos 0x0, ttl 127, id 26220, offset 0, flags [none], proto ICMP (1), length 60) 10.0.200.72 > 10.100.0.10: ICMP echo request, id 1, seq 47, length 40

=> Est-ce suffisant pour prouver que mes routes jusqu’au serveur sont bonnes ?
=> Je fais quoi maintenant ?

#5

Mais encore ?

Quel serveur ?
Non, ce n’est pas suffisant. As-tu réellement examiné les tables de routage de toutes les machines impliquées dans le cheminement des paquets depuis la source vers la destination et retour ?

#6

C’est le serveur debian que j’utilise pour faire la passerelle entre 10.1.0.0/16 et 10.100.0.0/16
cjoint.com/doc/16_02/FBdpY2r3RYT_network.png

J’ai regardé la configuration du firewall : elle me semble bonne car :

  • le PC 10.0.200.72 arrive à pinguer 10.1.0.2
  • je vois sur la capture tcpdump faite à partir du serveur (interface eth0) les pings provenant de 10.0.200.72 à destination de 10.100.0.10 (mais pas dans le sens retour).
  • le serveur arrive à pinguer 10.100.0.10
#7

C’est bon j’ai trouvé le problème : le script n’était pas lancé au démarrage car j’ai omis de lancer la commande :

=> Désolé je suis débutant

Par contre j’ai encore un problème : le PC 10.100.0.10 arrive à avoir accès aux réseaux 10.1.0.0/16 et 192.168.1.0/24 => je ne voudrais pas que ça soit le cas
=> comment faire ? Je pensais que la règle de routage que j’ai déclarée était bonne (en source j’ai déclaré uniquement 10.1.0.250 => voir mon script cité précedemment) : j’ai du mal comprendre comment ça fonctionnait …

Merci d’avance

#8

A quoi devrait-il avoir accès ? Tout le reste ?

Il n’y a aucune règle de routage dans ton script, mais seulement une règle iptables de masquerading (NAT source automatique) dont je ne comprends absolument pas l’utilité.

De toute façon, pour empêcher une communication ce n’est ni du routage ni du NAT qu’il faut mais du filtrage. Pour faire du filtrage, il faut définir pour chaque flux les interfaces d’entrée et de sortie, les adresses ou préfixes source et destination, le cas échéant les protocoles (TCP, UDP…), ports source et destination…

#9

le PC 10.100.0.10 ne doit avoir accès qu’à son LAN

[quote=“PascalHambourg”]
Il n’y a aucune règle de routage dans ton script, mais seulement une règle iptables de masquerading (NAT source automatique) dont je ne comprends absolument pas l’utilité.

De toute façon, pour empêcher une communication ce n’est ni du routage ni du NAT qu’il faut mais du filtrage. Pour faire du filtrage, il faut définir pour chaque flux les interfaces d’entrée et de sortie, les adresses ou préfixes source et destination, le cas échéant les protocoles (TCP, UDP…), ports source et destination…[/quote]
C’est un script que j’ai trouvé sur le net pour faire une passerelle : j’avoue ne pas bien comprendre ce que fait exactement la ligne de commande “iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1.1000 -j MASQUERADE” : si je la supprime, le PC 10.200.0.72 aura quand même accès au PC 10.100.0.10 ? Je pensais qu’elle servait à dire que tout ce qui provient de 10.1.0.250 est autorisé à sortir sur l’interface eth1.1000.
C’est la ligne “echo 1 > /proc/sys/net/ipv4/ip_forward” qui permet d’activer la passerelle ?
Quelle est la commande qu’il faut utiliser pour faire du filtrage ?

#10

Cette restriction s’applique seulement à cette machine ou à toutes celles de ce sous-réseau ?

Cette commande crée une règle iptables qui a pour but de remplacer l’adresse source 10.1.0.250 des connexions sortant par l’interface eth1.1000 (VLAN 1000 sur eth0) par l’adresse de cette interface. Je peux dire ce qu’elle fait, mais je ne vois pas pourquoi. En tout cas elle ne fait ni routage ni filtrage.

Oui, elle active la fonction routeur IPv4 qui permet de retransmettre les paquets reçus à destination d’une autre machine.

Il faut créer des règles iptables de filtrage dans la chaîne FORWARD pour accepter ou bloquer les paquets routés entre deux interfaces, une seule règle ne suffira pas forcément. Une règle peut prendre en compte divers critères comme les interfaces d’entrée et de sortie, les addresses source et destination, le protocole, les ports source et destination…

Pour la construction du jeu de règles il y a deux approches opposées :

  • on bloque tout par défaut et on accepte au cas par cas ;
  • on accepte tout par défaut et on bloque au cas par cas.
    La première approche est plus sure mais la seconde peut être plus simple quand le blocage est l’exception.

D’abord, quels sont les noms des interfaces réseau de ce serveur ?

#11

Ce sont les chaines FORWARD qui gèrent ce qui traverse la passerelle.

Par exemple, ce qui rentre par eth0 pour sortir par eth1
iptables -P FORWARD -i eth0 -o eth1 …

Pour bloquer la sortie des machines sur le réseau correspondant à eth0 :
iptables -P FORWARD -i eth0 DROP

Pour bloquer l’accès des machines sur le réseau correspondant à eth0
iptables -P FORWARD -o eth0 DROP

Par exemple :
iptables -P FORWARD -i eth0 -o eth1 ACCEPT
iptables -P FORWARD -i eth0 DROP
Permet de traverser de eth0 vers eth1, mais interdit de eth0 vers eth2

Les règles ressemblent aux règles input et output. Attention, il n’y a pas d’impact/interaction entre “INPUT -i eth0” et “FORWARD -i eth0” (idem pour output).

Pour masquerade, ça sert uniquement lorsque l’adresse est privé et que l’accès se fait à un réseau public.

#12

-P sert à definer la politique par défaut d’une chaîne, c’est-à-dire le sort des paquets (accepté/bloqué) qui atteignent la fin de la chaîne. Pour créer une règle, on utilise -A ou -I.

Une connexion est une communication bidirectionnelle qui implique la transmission de paquets dans les deux sens. Bloquer les paquets dans un sens empêche donc toute communication dans les deux sens. Autoriser les connexions dans un seul sens n’est pas aussi simple ; il faut utiliser le suivi de connexion pour identifier le début d’une connexion.

#13

Merci à tous pour vos réponses

Je préfère de loin la première solution, ça réduit grandement le risque de faille de sécurité.
Je veux donc que eth0 vers eth1 passe mais pas l’inverse.
L’option MASQUERADE me semble aussi importante : les machines qui sont sur le WAN 10.100.0.0/16 (eth1) n’ont pas à connaitre l’adresse IP source.
=> en gros, je veux faire un firewall entre eth0 (LAN) et eth1 (WAN).

Voici où j’en suis mais après quelque tests, ça semble pas fonctionner => eth1 arrive à communiquer avec eth0

[code]#!/bin/bash

###########################

vide les tables

iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -t nat -X
iptables -t mangle -X

echo iptables clear [OK]

#########################

activation du forwarding (laisse passer tous les paquets => ne pas activer)

echo 1 > /proc/sys/net/ipv4/ip_forward

########################

règles de routage

iptables -P FORWARD -i eth0 -o eth1 ACCEPT
iptables -P FORWARD -i eth0 DROP

#######################

pour changer l’adresse IP source

iptables -t nat -A POSTROUTING -s 10.1.0.250 -o eth1 -j MASQUERADE

echo iptables rules created [OK]
[/code]

Par contre j’ai cette erreur :
sudo /etc/init.d/firewall restart

iptables clear [OK] iptables v1.4.14: -X requires a chain and a policy Try `iptables -h' or 'iptables --help' for more information. iptables v1.4.14: -X requires a chain and a policy Try `iptables -h' or 'iptables --help' for more information. iptables rules created [OK]

#14

J’ai fait quelques modif du script pour ne plus avoir de message d’erreur :

… Mais je n’arrive toujours pas à bloquer les connexion de 10.100.0.10 vers eth0

#15

=> Je pense que le problème vient de là… actuellement je pense savoir bloquer chaque sens de communication mais je ne sais comment les passer le paquets de “retour” lorsque que dans le sens retours j’ai créé un règle de blocage de paquets. Comment fait-on exactement ?

#16

En quoi est-ce utile ou souhaitable, du moment que les machines du WAN ont la bonne route pour atteindre l’adresse source ?

Cette phrase ne veut rien dire. eth1 et eth0 ne communiquent pas ensemble, elles sont sur des réseaux distincts.

Les paquets retour sont identifiables par leur état ESTABLISHED ou RELATED. Les paquets aller peuvent aussi avoir cet état quand une connexion est établie, mais le premier paquet a toujours l’état NEW. En n’autorisant que les paquets dans l’état ESTABLISHED ou RELATED dans un sens, on empêche donc les connexions dans ce sens.

Note : Il n’est pas nécessaire de faire du filtrage dans les chaînes INPUT et OUTPUT qui ne sont pas impliquées dans le traitement des paquets retransmis d’une interface à une autre. Ceux-ci ne traversent que la chaîne FORWARD.

#17

Peut être :

Ou 10.100.0.0/24 si tu veux bloquer toutes les machines 10.100.0.XX
Ca induit que les machines connectée du coté eth1 ne pourront pas recevoir de réponse de 10.100.0.10 sauf si tu as mis les règles concernant les communications en cours (cf -m state --state ESTABLISHED,RELATED)

Désolé pour l’erreur “-P”

#18

[quote=“PascalHambourg”]-m state --state ESTABLISHED,RELATED
[/quote]
Merci, c’est ce que je recherchais

#19

J’ai une autre petite question.

Si j’installe un serveur DHCP sur eth1, je suppose qu’il faut configurer quelque chose (je veux que sur le serveur on n’est accès qu’au serveur DHCP… pas d’accès SSH et autre ) ?

#20

Aussi j’aimerai savoir comment avoir les log de ces commandes :

iptables -P INPUT DROP iptables -P OUTPUT DROP iptables -P FORWARD DROP
=> j’ai cherché sur le net mais je ne trouve que des méthodes pour d’anciennes versions de iptables (j’utilise la version 1.4.14) : le mot clef LOG ne semble plus reconnu

merci d’avance