Routage avancé et vpn pptp

Support Debian
#1

Bonjours a tous.

j’ai un gros souci avec le routage avancé, car tout les tutos et forum que je trouve ne traite jamais mon cas, que je vais vous présenté.

j’ai un pc routeur sous debian qui me sert de passerelle pour mon reseau local. j’ai aussi une connexion vpn en ppp1.
eth0= ip publique internet
eth1= ip reseau local
ppp1= ip vpn

plutot que de vous montrer mes configs j’en ai essayer une vingtaine mais aucune ne marche je vous explique ce que je souhaite. j’aimerais que quand mon vpn est actif qu’un ordinateur du reseau soit accessible via remote desktop windows port ip 3389 par mon ip publique mais aussi par mon ip du vpn. sauf que quand je me connecte par l’ip publique ca marche mais pas quand j’essai avec l’ip du vpn, les trames arrive bien mais les réponses ressorte tout le temp via l’ip publique.

je sais plus quoi faire, comment vous procéderiez vous chère experts en routage avancé ??

#2

J’avoue que je ne vois pas bien en quoi cela requiert du routage avancé. Tu pourrais détailler le plan d’adressage, y compris ce qui se trouve de l’autre côté du VPN ?
Quand tu écris “via l’ip publique”, tu veux dire via l’interface publique (eth0) ou avec l’adresse IP publique ?

#3

pour schematisé :

freebox ---- eth0: pc routeur (debian squeeze) eth1 ----- reseau local 192.168.100.0/24
ppp1 : (une autre ip publique fournit par mon fournisseur vpn)

freebox en mode pont deux carte reseaux eth0 et eth1, et ppp1 passe par free eth0.

imaginons partir de ce script ( ou on accepte tout juste pour l’exercice)

#!/bin/bash

#activation du partage de connexion
echo 1 > /proc/sys/net/ipv4/ip_forward

# Initialisation de la table FILTER
iptables -t filter -F
iptables -t filter -X
iptables -t filter -P INPUT   ACCEPT
iptables -t filter -P OUTPUT  ACCEPT
iptables -t filter -P FORWARD ACCEPT

# Initialisation de la table NAT
iptables -t nat -F
iptables -t nat -X
iptables -t nat -P PREROUTING  ACCEPT
iptables -t nat -P POSTROUTING ACCEPT
iptables -t nat -P OUTPUT      ACCEPT

# Initialisation de la table MANGLE
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING  ACCEPT
iptables -t mangle -P INPUT       ACCEPT
iptables -t mangle -P OUTPUT      ACCEPT
iptables -t mangle -P FORWARD     ACCEPT
iptables -t mangle -P POSTROUTING ACCEPT

# J'accepte les packets entrants relatifs à des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
echo "[Ne pas casser les connexions établies : OK]"

on peu pk pas rajouté ça :

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

j’ai oublié de précisé que mon systcl.conf contient ceci :

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

voila, je peu donner plus de détail mais j’aimerais avant qu’on s’éparpille, voir comment vous procederiez

#4

Je comprends mieux. En fait le VPN n’est pas une liaison vers une machine ou un site particulier, mais comme une seconde connexion internet. Donc les adresses source des connexions RDP qui arrivent par le VPN sont quelconques et indiscernables de celles qui arrivent par la box. Je vois plusieurs approches possibles pour différencier les connexions selon la provenance :

a) Marquage avec iptables des connexions selon l’interface d’entrée/adresse destination d’origine

iptables -t mangle -A PREROUTING -i ppp1 -j CONNMARK --set-mark 0x1 iptables -t mangle -A PREROUTING -i eth1 -j CONNMARK --restore-mark ip rule add fwmark 0x1 lookup <table_de_routage_alternative>
b) Marquage des paquets sortants en fonction de l’adresse destination d’origine

[code]iptables -t mangle -A PREROUTING -i eth1 -m conntrack --ctorigdst <adresse_ppp1> -j MARK --set-mark 0x1

attention : si l’adresse de ppp1 change, il faut mettre à jour la règle

ip rule add fwmark 0x1 lookup <table_de_routage_alternative>[/code]
c) Ajout d’une adresse secondaire sur le PC cible et redirection vers une adresse différente selon la provenance, avec routage des paquets sortants selon l’adresse source

iptables -t nat -A PREROUTING -p tcp --dport 3389 -i ppp1 -j DNAT --to-destination 192.168.100.2 iptables -t nat -A PREROUTING -p tcp --dport 3389 -i eth0 -j DNAT --to-destination 192.168.100.1 ip rule from 192.168.100.2 lookup <table_de_routage_alternative>
Je passe les détails sur le remplissage de la table de routage alternative

#5

[quote=“Labure”]j’ai oublié de précisé que mon systcl.conf contient ceci :
net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0[/quote]
Petite remarque sans incidence pour le sujet : avec les noyaux actuels net.ipv4.conf.all.rp_filter=0 ne suffit pas pour désactiver le reverse path filtering : il faut aussi que chaque net.ipv4.conf..rp_filter=0 (ce qui est normalement le cas par défaut).

#6

l’option A marche tres bien, enfin j’y arrive merci beaucoup !!!

sauf que pas pour l’udp.

donc avec une table de routage alternative j’arrive a marquer les paquets sortant par type de service exemple ssh smtp ou autre j’arrive a marquer les paquets entrant grâce à PascalHambourg, mais j’arrive pas a marquer les paquets en udp ou y a t’il autre chose a vérifier ?

#7

bon apres reverification sa semble marche aussi en udp,

je vais tester en profondeur et vous dire si ça marche bien.

#8

En cas de problème, il faudrait préciser quel type de paquets UDP.

Pour être marqué par CONNMARK, un paquet UDP émis en réponse à un paquet UDP entrant (ex : DNS) doit être vu comme faisant partie de la même “connexion” au sens du suivi de connexion de netfilter : adresses et ports source et destination inversés par rapport au paquet entrant. Cette condition est aussi nécessaire pour que le NAT/masquerading fonctionne.

#9

j’ai pas eu le temps de tester l’UDP mais ça semble bizarre.

pour l’instant j’ai besoin que du tcp pour chez moi, mais par contre j’ai un autre routeur a configurer bientôt ou la il y aura pas mal de personnes qui font du P2P, donc pas question que ça passe par la connexion publique.

il me semble que torrent et qu’en tcp, mais pas emule il y a du udp.
d’ailleurs si quelqu’un a déjà des règle toutes faites pour interdire le P2P ou plutôt des règles qui peuvent énervé les téléchargeurs fou ?

Pour info ces sites sont relié par du openvpn, et chacun d’eux aura en plus une connexion vpn pptp supplémentaire pour avoir une deuxième IP publiques (Americaine) comme ça possibilité d’utilisé des services uniquement dispo pour les americiains.