evolix
/
wiki
19
0
Fork 0
Code Releases Activity

Routage particulier (avec route-to) - amélioration et précisions

This commit is contained in:
jdubois 2020-03-24 16:57:50 +01:00
parent 6d22f063da
commit 97eb1b85cf
1 changed files with 8 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
HowtoOpenBSD/PacketFilter.md
View File

@ -179,25 +179,23 @@ La table ne se vide pas avec un rechargement de pf (`pfctl -f /etc/pf.conf`).
#### Routage particulier (avec route-to)
Pour avoir un routage spécifique, i.e. différent de celui donné par la table de
routage, on peut agir avec le mot-clé `route-to`.
Pour avoir un routage spécifique, c'est-à-dire différent de celui donné par la table de routage, on peut agir avec le mot-clé `route-to`.
Généralement c'est sous la forme
Ça se configure sous la forme suivante :
~~~
pass in on $lan_if ... to ! <lan> route-to ($otherext_if 192.0.2.254)
pass in on $lan_if ... to ! <lan> route-to { ($otherext_if 192.0.2.254) }
~~~
Cela ne matche que pour le lan et non pas pour le routeur lui-même. Dans ce
cas, on peut utiliser une règle du type
Cela ne matche que pour les paquets provenants du LAN et non pas pour ceux provenants du routeur lui-même, ni pour une réponse à un paquet provenant de l'extérieur.
Dans ce cas, on peut utiliser une règle du type :
~~~
pass out from $egress:0 ... route-to 192.0.2.254@$otherext_if nat-to 192.0.2.253
pass out from $egress:0 ... keep state route-to { ($otherext_if 192.0.2.254) } nat-to 192.0.2.253
~~~
La partie nat-to est nécessaire car sinon les paquets vont partir avec l'IP de
l'interface principale et l'opérateur réseau en face va voir cela comme une
usurpation et va refuser le paquet
La partie nat-to est nécessaire, sinon les paquets vont partir sur l'interface secondaire avec l'IP de l'interface principale. Aussi, l'opérateur réseau en face risque de voir cela comme une usurpation et refuser le paquet.
#### Options nat-to vs rdr-to vs binat-to