Digression : T&A Routage sélectif connexion internet 2daire

Support Debian
#21

Hola l’autre, comment il me traite ! Si on ne peut plus se laisser aller à un peu d’immodestie…

Comme promis, voici des explications sur rp_filter (reverse path filtering).

Le reverse path filtering est une fonctionnalité optionnelle qui fait partie de la validation d’adresse source des paquets IPv4 reçus, utilisée pour lutter contre l’usurpation d’adresse source (IP spoofing). Cette vérification a lieu au cours de la décision de routage d’entrée après les chaînes PREROUTING et avant les chaînes INPUT ou FORWARD d’iptables. Il y a deux modes, “strict” et “loose” (lâche) définis dans RFC3704.

Le principe de base est simple : on prend l’adresse source du paquet reçu et on regarde par quelle interface cette adresse serait routée si on devait répondre au paquet. Si l’interface correspond à l’interface d’entrée du paquet (en mode strict) ou simplement existe (en mode loose), alors le paquet peut continuer son chemin. Sinon il est écarté.

Le reverse path filtering en mode strict fonctionne bien dans une configuration de routage classique (basé seulement sur la destination) et symétrique (les deux direction d’une communication avec une adresse donnée passent par la même interface). Dans une configuration de routage avancé, où le routage est basé sur d’autres données que la destination, ou asymétrique, le reverse path filtering peut bloquer des paquets légitimes, car l’interface qui reçoit le trafic est différente de l’interface de sortie “par défaut” (sans routage avancé). Des améliorations sont censées prendre en compte le routage avancé, mais ce n’est pas très clair.

Comme la plupart des paramètres du noyau dans net.ipv4.conf, la valeur fonctionnelle pour une interface ${interface} est le résultat d’une combinaison logique ou arithmétique entre les valeurs de net.ipv4.conf.${interface}.rp_filter et net.ipv4.conf.all.rp_filter. La valeur par défaut de net.ipv4.conf.${interface}.rp_filter est la valeur de net.ipv4.conf.default.rp_filter quand l’interface ${interface} est créée. Dans Debian, des valeurs initiales peuvent être fixées dans le fichier /etc/sysctl.conf.

Pour compliquer le tout, le fonctionnement du reverse path filtering a évolué avec les versions du noyau. Historique :

avant 2.6.30

  • rp_filter est un booléen avec 1=activé (strict) et 0=désactivé
  • combinaison “et logique” entre all et interface

2.6.30

  • rp_filter devient un entier avec 0=désactivé, 1=strict et 2=loose
  • mise à jour de ip-sysctl.txt pour refléter le changement

2.6.31

  • changement de de combinaison en “max” entre all et interface

2.6.32

  • utilisation du routage avancé par marque pour le reverse path filtering (à préciser)

2.6.33

  • mise à jour de ip-sysctl.txt pour refléter le changement de logique en 2.6.31

Le changement le plus notable est qu’avant le noyau 2.6.30 net.ipv4.conf.all.rp_filter=1 est une condition nécessaire (mais pas suffisante) pour activer le reverse path filtering sur une interface, et donc net.ipv4.conf.all.rp_filter=0 est une condition suffisante pour le désactiver sur toutes les interfaces. A partir du noyau 2.6.30, net.ipv4.conf.all.rp_filter=1 devient une condition suffisante pour l’activer sur toutes les interfaces, et net.ipv4.conf.all.rp_filter=0 est une condition nécessaire (mais plus suffisante) pour le désactiver sur une interface. Une installation peut donc se retrouver avec le reverse path filtering involontairement activé sur toutes les interfaces après une mise à jour du noyau, par exemple lors du passage de Lenny à Squeeze.

En conclusion je n’ai en fait pas grand mérite à avoir identifié le problème car d’expérience c’est la cause la plus fréquence de dysfonctionnement du routage avancé. Cette particularité devrait à mon avis figurer en gros dans le T&A.

#22

merci pour toutes ces explications !

#23

Hello all

je ressort ce sujet.

moi mon problème est le suivant je me suis servi de ce tutos sauf que chez moi la différence c’est pas pour un ordinateur mais une passerelle sous debian. donc le but est de faire du routage selectif pour tout un reseau local. donc mais regles sont construite un peu différemment.

Voici ma config : une connection internet en eth0 avec ip publique et mon reseau local connecté en eth1 et une connexion vpn pptp en ppp1.

le but est que quand ma connections vpn et up mon firewall doit faire ceci : du routage sélectif selon des port ip tcp et udp et aussi de la translation d’adresse du vpn vers le réseau local.

sauf que le routage sélectif a bien l’air de marcher mais impossible de routé comme il faut les demandes entrante du vpn vers mon réseau local. exactement le même problème que gsavin les demande sont reçu par mon vpn mais les reponse sorte par connexion publique.

ça fait deux jours que je seche.

pour info voila pour l’instant comment je procede, quand ma connexion vpn est up, grace au script que j’ai creer dans /etc/ppp/ip-up.d/vpn le firewall recoit des nouvelles regles

script :

[code]#!/bin/sh

Créer les règles de routage (avant de créer le marquage de paquets)

Usage:

createRoutingPolicy MARKER IFACE IFACE_IP GATEWAY

echo Starting vyprvpn routing

createRoutingPolicy()
{
local MARKER="$1"
local IFACE="$2"
local IFACE_IP="$3"
local GATEWAY="$4"

(2) table de routage alternative

ip route flush table "$MARKER"
ip route show table main | grep -Ev ^default | while read ROUTE; do ip route add table “$MARKER” $ROUTE; done
ip route add table “$MARKER” default via “$GATEWAY” dev “$IFACE”

(3) activation du routage

ip rule add fwmark “$MARKER” table "$MARKER"
ip route flush cache

(4) translation NAT

    #iptables -t nat -A POSTROUTING -o ppp1 -m mark --mark "$MARKER" -j MASQUERADE
    iptables -t nat -A POSTROUTING -o "$IFACE" -m mark --mark "$MARKER" ! -s "$IFACE_IP" -j SNAT --to-source "$IFACE_IP"

}

Créer le marquage de paquets (une fois les règles de routage en place)

Usage:

createMarkingPolicy MARKER [REGLES_IPTABLES]*

createMarkingPolicy()
{
local MARKER="$1"
shift

(5) ajout du marquage de paquets

iptables -t mangle -A OUTPUT “$@” -j MARK --set-mark “$MARKER”
}

Supprimer le marquage de paquets (avant de supprimer les règles de routage)

Usage:

removeMarkingPolicy MARKER [REGLES_IPTABLES]*

removeMarkingPolicy()
{
local MARKER="$1"
shift

(5) suppression du marquage de paquets

iptables -t mangle -D OUTPUT “$@” -j MARK --set-mark “$MARKER”
}

Supprimer les règles de routage (une fois le marquage de paquets supprimé)

Usage:

removeRoutingPolicy MARKER IFACE IFACE_IP

removeRoutingPolicy()
{
local MARKER="$1"
local IFACE="$2"
local IFACE_IP="$3"

(4) translation NAT

iptables -t nat -D POSTROUTING -o “$IFACE” -m mark --mark “$MARKER” ! -s “$IFACE_IP” -j SNAT --to-source “$IFACE_IP”

(3) désactivation du routage

ip rule del fwmark “$MARKER” table “$MARKER”

(2) table de routage alternative

ip route flush table "$MARKER"
ip route flush cache
}

le script recoit de pppd en $1 = interface $4 = ip du vpn

MARKER='78’
IFACE=$1
IFACE_IP=$4

gateway sert pas a grand chose avec du pptp j’ai mi l’ip du vpn

GATEWAY=$4

sysctl -w net.ipv4.conf.all.rp_filter=0
sysctl -w net.ipv4.conf.ppp1.rp_filter=0
sysctl -p

createRoutingPolicy “$MARKER” “$IFACE” “$IFACE_IP” “$GATEWAY”

Autoriser tout ppp1

    iptables -A INPUT -i ppp1 -j ACCEPT
    iptables -A FORWARD -i ppp1 -j ACCEPT
    iptables -A FORWARD -o ppp1 -j ACCEPT
    iptables -A OUTPUT -o ppp1 -j ACCEPT

iptables -t nat -A PREROUTING -p tcp --dport 3389 -i ppp1 -j DNAT --to-destination 192.168.100.1:3389

iptables -t mangle -A PREROUTING -i ppp1 -m state --state NEW -j CONNMARK --set-mark 78
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 80 -j MARK --set-mark 78
iptables -t mangle -A PREROUTING -i eth1 -p tcp --dport 3389 -s 192.168.100.0/24 -j MARK --set-mark 78
iptables -t mangle -A PREROUTING -i eth1 -p tcp --sport 3389 -s 192.168.100.0/24 -j MARK --set-mark 78
[/code]

le but ici et que quand le vpn est actif les connexions du reseau local sur port 80 utilise le vpn (juste pour test en fesant un what is my ip adresse j’ai bien l’ip du vpn)

apres c’est que je puisse prendre la main sur un pc interne en RDP port 3389 (la ça marche pas les demande sont reçu mais les reponse sorte par eth0.

Si quelqu’un a une idée ???

#24

Salut,

@Syam:
J’ai parcouru rapidement ton tuto, mais avant d’aller plus loin et de commencer à comprendre comment fonction iptables et Cie, j’aimerais savoir si ce que je veux faire est possible.

J’ai un PC de bureau avec 2 utilisateurs et 2 interfaces ethernet (eth0 et eth1).
Est-il possible que tous les process lancés par l’utilisateur n°1 utilisent l’interface eth0 et que les process lancés par l’utilisateur n°2 utilisent l’interface eth1 ?

Les deux interfaces sont raccordées à une Freebox.

Le but est que lorsque les utilisateurs sont connectés à leur session en même temps, ils utilisent une interface bien distincte chacun pour accéder à internet via la Freebox.
:006

#25

@nico : oui c’est tout à fait faisable (règle iptables --uid-owner calquée sur la règle --gid-owner présente dans le T&A du forum ---- pff va falloir que je remette de l’ordre dans tout ça moi quand j’aurai le courage).
Cela dit je m’interroge sur la pertinence de ce que tu veux faire : si au final c’est pour accéder à la même connexion internet, tu gagneras pas en vitesse (car la connexion internet est forcément plus lente que ton LAN 100Mbps voire 1Gbps).
Ce genre de routage avancé c’est plutôt quand tu veux accéder à deux connexions distinctes, ou déporter certaines connexions via un VPN, etc.

@Labure : suite à ton MP je te réponds ici… honnêtement pour les connexions entrantes je me suis jamais penché dessus, et les détails du routage sont devenus un peu flous pour moi depuis le temps que j’ai fait ce tuto… c’est pas tous les 4 matins que je bricole là-dedans. :blush:
À l’occasion quand j’aurai suffisamment de temps libre je remettrai tout à plat avec les nouvelles infos que j’ai eu entre temps, mais c’est pas pour tout de suite.

#26

[quote=“syam”]@nico : oui c’est tout à fait faisable (règle iptables --uid-owner calquée sur la règle --gid-owner présente dans le T&A du forum ---- pff va falloir que je remette de l’ordre dans tout ça moi quand j’aurai le courage).
Cela dit je m’interroge sur la pertinence de ce que tu veux faire : si au final c’est pour accéder à la même connexion internet, tu gagneras pas en vitesse (car la connexion internet est forcément plus lente que ton LAN 100Mbps voire 1Gbps).
Ce genre de routage avancé c’est plutôt quand tu veux accéder à deux connexions distinctes, ou déporter certaines connexions via un VPN, etc.[/quote]
Ma femme et moi utilisons souvent le PC en même temps (configuration multi-sièges).
J’ai pensé qu’on peut peut-être aussi jouer en pseudo LAN ensemble. Le problème est que lorsque chacun de nous lance un jeu, la même interface ethernet est détectée dans le jeu.
Donc je me suis dit, si chaque utilisateur utilise une interface ethx, un des utilisateurs peut “héberger” le jeu et l’autre utilisateur peut rejoindre la partie.
Je ne sais pas si j’ai été assez clair.
Peut-être que mon raisonnement a été trop simpliste ? :017

#27

Ça ne marche pas comme ça. On ne peut pas envoyer des paquets IP par une interface et les recevoir par une autre sur la même machine. Les communications entre processus locaux utilisent l’interface de loopback lo. Une application normale n’est pas censée s’amuser à “détecter” les interfaces réseau, elle doit laisser ça au système.

#28

salut
quel trvail accompli
je suis sur que tu vas pouvoir m’aidé
mon souci est simple
serveur sous debian interfaces eth0 passerelle vers réseau local ayant pour net mask 255.255.240.0 donc plusieurs sous réseau
interface eth1 connexion internet
interface eth2 connexion internet
je souhaiterai routé une partie des sous réseaux vers eth1 l’autre vers eth2 en fonction de leur adresse ip comment puis je faire
cordialement