![[BANNER]](/templates/iceage/images/banniere.jpg)
![[NEWS]](templates/iceage/images/icon-news.png){kind=icon}
Envoyé par unreal
Nous avons déjà évoqué certaines fonctionnalités avancées de PF, par exemple la protection anti DOS et le filtrage IPv6. Dans cet article, nous allons explorer les possibilités de policy routing ou politique de routage en français. Ce type de configuration est nécessaire quand le routeur dispose de plusieurs accès Internet et que vous souhaitez contrôler les flux.
Ci-dessous un schéma de principe :
Plusieurs remarques importantes :
- le routeur, installé en FreeBSD 8.1 x64, offre déjà les fonctionnalités de NAT/FW
- vlan1 et tun1 ont des IP publiques statiques (mais seulement vlan1 a une route par défaut)
- le laptop et serveur ont le routeur comme gw vers Internet
Gestion des flux entrants
Pour commencer, nous allons configurer PF pour que l'interface tun1 puisse répondre à l'ICMP echoreq (ping) et que le serveur Web soit accessible depuis les deux IP publiques. Le routeur héberge un serveur SSH sur port 2222, nous allons autoriser les connexions depuis tun1.
Pour ce faire, nous allons utiliser l'option reply-to qui permet de forcer le chemin de retour ailleurs que par la route par défaut.
pf.conf
Cet exemple est assez explicite et ne contient que la partie qui nous intéresse, à savoir le routage des flux. On peut noter que l'adresse de la passerelle de l'interface pppoe_gw est configurée statiquement, car elle est utilisée par l'option reply-to pour router les paquets.
Un autre cas de figure qui est intéressant de gérer c'est les flux sortants.
Gestion de flux sortants
Le but cette fois-ci sera de contrôler par quel lien passera le traffic (naté) sortant.
Ceci peut présenter plusieurs intérêts :
- router des flux sensibles (SSH, VoIP, jeux en ligne) via un lien dédié
- dédier un lien à un utilisateur ou à un groupe d'utilisateurs
- réduire les coûts en routant les flux non critiques via un lien bon marché
- améliorer la performance en profitant des accords de peering de plusieurs opérateurs, en routant par exemple vers Google via l'opérateur qui a la meilleure connectivité vers Google
Ainsi de suite.
Ceci se fait avec l'option route-to, comme dans l'exemple ci-dessous :
Cet exemple se contente de rerouter les flux vers http://myip.dk/ via tun1, alors que la passerelle par défaut est vlan1.
On peut formuler plusieurs remarques par rapport au fonctionnement de cet exemple :
- Le re-routage des flux sortants se fait en deux étapes : routage vers la bonne interface ($pppoe_if), puis réécriture de l'IP source.
- La règle de pass in est appliquée avant le NAT, qu'on applique donc bien sur l'interface de sortie souhaitée $pppoe_if.
- Les règles de NAT sont évaluées de haut en bas. La première règle qui correspond est appliquée ; il faut donc mettre la directive par défaut en bas, et les exceptions en haut.
Conclusion
PF est un outil très flexible pour réaliser de la politique de routage statiques grâce aux options reply-to et route-to.
Historique :
- 20110216 : première version
- 20110222 : refonte de la partie sur les flux sortants
Ci-dessous un schéma de principe :
Plusieurs remarques importantes :
- le routeur, installé en FreeBSD 8.1 x64, offre déjà les fonctionnalités de NAT/FW
- vlan1 et tun1 ont des IP publiques statiques (mais seulement vlan1 a une route par défaut)
- le laptop et serveur ont le routeur comme gw vers Internet
Gestion des flux entrants
Pour commencer, nous allons configurer PF pour que l'interface tun1 puisse répondre à l'ICMP echoreq (ping) et que le serveur Web soit accessible depuis les deux IP publiques. Le routeur héberge un serveur SSH sur port 2222, nous allons autoriser les connexions depuis tun1.
Pour ce faire, nous allons utiliser l'option reply-to qui permet de forcer le chemin de retour ailleurs que par la route par défaut.
pf.conf
# Definitions d'interfaces
def_if = "em0"
nc_if = "vlan1"
loopback_if = "lo0"
pppoe_if = "tun1"
# Definitions IP et port
pppoe_gw="111.222.333.1"
macmini = "192.168.1.1"
macmini_web_ports = "{ 80, 443 }"
# Translations de port
rdr on $nc_if proto tcp from any to any port $macmini_web_ports -> $macmini
rdr on $pppoe_if proto tcp from any to any port $macmini_web_ports -> $macmini
# Connexions entrantes
# Tout refuser par défaut
block in on $nc_if all
block in on $pppoe_if all
# ICMP
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto icmp all icmp-type echoreq
# SSH
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port 2222 keep state
# Web
pass in on $nc_if proto tcp from any to any port $macmini_web_ports keep state
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port $macmini_web_ports keep state
def_if = "em0"
nc_if = "vlan1"
loopback_if = "lo0"
pppoe_if = "tun1"
# Definitions IP et port
pppoe_gw="111.222.333.1"
macmini = "192.168.1.1"
macmini_web_ports = "{ 80, 443 }"
# Translations de port
rdr on $nc_if proto tcp from any to any port $macmini_web_ports -> $macmini
rdr on $pppoe_if proto tcp from any to any port $macmini_web_ports -> $macmini
# Connexions entrantes
# Tout refuser par défaut
block in on $nc_if all
block in on $pppoe_if all
# ICMP
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto icmp all icmp-type echoreq
# SSH
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port 2222 keep state
# Web
pass in on $nc_if proto tcp from any to any port $macmini_web_ports keep state
pass in on $pppoe_if reply-to ($pppoe_if $pppoe_gw) inet proto tcp from any to any port $macmini_web_ports keep state
Cet exemple est assez explicite et ne contient que la partie qui nous intéresse, à savoir le routage des flux. On peut noter que l'adresse de la passerelle de l'interface pppoe_gw est configurée statiquement, car elle est utilisée par l'option reply-to pour router les paquets.
Un autre cas de figure qui est intéressant de gérer c'est les flux sortants.
Gestion de flux sortants
Le but cette fois-ci sera de contrôler par quel lien passera le traffic (naté) sortant.
Ceci peut présenter plusieurs intérêts :
- router des flux sensibles (SSH, VoIP, jeux en ligne) via un lien dédié
- dédier un lien à un utilisateur ou à un groupe d'utilisateurs
- réduire les coûts en routant les flux non critiques via un lien bon marché
- améliorer la performance en profitant des accords de peering de plusieurs opérateurs, en routant par exemple vers Google via l'opérateur qui a la meilleure connectivité vers Google
Ainsi de suite.
Ceci se fait avec l'option route-to, comme dans l'exemple ci-dessous :
pppoe_if = "tun1"
nc_if = "vlan1"
def_if = "em0"
internal_net = "192.168.10.0/24"
pppoe_gw="178.32.37.1"
# NAT
# Exception du routage de flux
nat on $pppoe_if proto tcp from $internal_net to myip.dk port 80 -> ($pppoe_if)
# Route par defaut
nat on $nc_if from $internal_net to any -> ($nc_if)
# Exception du routage de flux
pass in on $def_if route-to ($pppoe_if $pppoe_gw) inet proto tcp from $internal_net to myip.dk port 80 keep state
nc_if = "vlan1"
def_if = "em0"
internal_net = "192.168.10.0/24"
pppoe_gw="178.32.37.1"
# NAT
# Exception du routage de flux
nat on $pppoe_if proto tcp from $internal_net to myip.dk port 80 -> ($pppoe_if)
# Route par defaut
nat on $nc_if from $internal_net to any -> ($nc_if)
# Exception du routage de flux
pass in on $def_if route-to ($pppoe_if $pppoe_gw) inet proto tcp from $internal_net to myip.dk port 80 keep state
Cet exemple se contente de rerouter les flux vers http://myip.dk/ via tun1, alors que la passerelle par défaut est vlan1.
On peut formuler plusieurs remarques par rapport au fonctionnement de cet exemple :
- Le re-routage des flux sortants se fait en deux étapes : routage vers la bonne interface ($pppoe_if), puis réécriture de l'IP source.
- La règle de pass in est appliquée avant le NAT, qu'on applique donc bien sur l'interface de sortie souhaitée $pppoe_if.
- Les règles de NAT sont évaluées de haut en bas. La première règle qui correspond est appliquée ; il faut donc mettre la directive par défaut en bas, et les exceptions en haut.
Conclusion
PF est un outil très flexible pour réaliser de la politique de routage statiques grâce aux options reply-to et route-to.
Historique :
- 20110216 : première version
- 20110222 : refonte de la partie sur les flux sortants
Posté le 16/02/11 à 10:52