#26 Le 24/02/2011, à 17:10
- rafy47
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
j'ai tenté
iptables -L -nv -t mangle:
$ sudo iptables -L -nv -t mangle
Chain PREROUTING (policy ACCEPT 247K packets, 172M bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 246K packets, 172M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 224K packets, 51M bytes)
pkts bytes target prot opt in out source destination
0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 MARK xset 0x1/0xffffffff
104 5876 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK xset 0x1/0xffffffff
Chain POSTROUTING (policy ACCEPT 224K packets, 51M bytes)
pkts bytes target prot opt in out source destination $ sudo iptables -L -nv -t mangle
Chain PREROUTING (policy ACCEPT 247K packets, 172M bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 246K packets, 172M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 224K packets, 51M bytes)
pkts bytes target prot opt in out source destination
0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 MARK xset 0x1/0xffffffff
104 5876 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 MARK xset 0x1/0xffffffff
Chain POSTROUTING (policy ACCEPT 224K packets, 51M bytes)
pkts bytes target prot opt in out source destinationJe n'ai pas de variation en terme de paquets on dirait bien.
Par contre les destinations et sources en 0.0.0.0 me paraissent étranges.
Hors ligne
#27 Le 24/02/2011, à 17:33
- tooney
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Je vais t'embêter encore un peu avec un tcpdump, justement pour qu'on puisse suivre l'établissement des connexions (SYN, ACK, SYN ACK) :
tcpdump -nv -i eth0 port 80Si j'interprète, ça veut dire qu'à une tentative de connexion sur mon serveur depuis l'extérieur, les paquets sont renvoyés par apache via eth0 sur l'extrémité du VPN ?? o_O
Par contre sur ce point là, je ne le traduis pas comme ça :
16:35:42.532692 IP 100-227.XXX-XXX.static-ip.XXXXXXXX.fr.15478 > WEBSERVER.www: Flags [s], seq 2714628487, win 64240, options [mss 1460,nop,nop,sackOK], length 0Ton paquet arrive sur ton serveur sur son adresse LAN (WEBSERVER port www) depuis l'extérieur (100-227.XXX-XXX.static-ip.XXXXXXXX.fr)
16:35:44.396507 IP 69.80.XXX.XXX.53728 > XXXXXXXX-in-f139.1e100.net.www: Flags [s], seq 341273755, win 5424, options [mss 1356,sackOK,TS val 37807936 ecr 0,nop,wscale 6], length 0Ton serveur initie une connexion http vers un serveur externe (XXXXXXXX-in-f139.1e100.net). S'il s'agissait d'une réponse de ton serveur web, le port "www" apparaitrait au niveau de la source, et non de la destination.
Loi de Bonaldi appliquée à Linux : L’expérience prouve que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
Hors ligne
#28 Le 24/02/2011, à 17:47
- tooney
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Sorry, je n'avais pas vu ton dernier post...
pkts bytes target prot opt in out source destination
0 0 MARK tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp spt:80 MARK xset 0x1/0xffffffffC'est très bizarre que le nombre de matchs reste à 0... Cela signifie qu'il n'y aurait aucun paquet qui aurait comme port source 80....
Pour info, le 0.0.0.0/0 équivaut à any, c'est-à-dire toutes les IP.
Loi de Bonaldi appliquée à Linux : L’expérience prouve que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
Hors ligne
#29 Le 24/02/2011, à 19:11
- rafy47
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Merci encore Tooney pour tes réponses !
Bon en tout cas, j'apprends plein de trucs sur la partie réseau 
Voilà ce qui se passe lors du tcpdump (je suis rentré à la maison donc c'est plus simple à gérer).
$tcpdump -nv -i eth0 port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
19:04:05.267558 IP (tos 0x0, ttl 241, id 775, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.50420 > 192.168.1.13.80: Flags [s], cksum 0xc2f0 (correct), seq 3381369201, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490530482 ecr 0,sackOK,eol], length 0
19:04:08.267565 IP (tos 0x0, ttl 241, id 1882, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.50420 > 192.168.1.13.80: Flags [s], cksum 0xb738 (correct), seq 3381369201, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490533482 ecr 0,sackOK,eol], length 0
19:04:11.468337 IP (tos 0x0, ttl 241, id 3729, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.50420 > 192.168.1.13.80: Flags [s], cksum 0xaab8 (correct), seq 3381369201, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490536682 ecr 0,sackOK,eol], length 0
19:04:14.667129 IP (tos 0x0, ttl 241, id 9753, offset 0, flags [DF], proto TCP (6), length 48)
92.90.XXX.XXX.50420 > 192.168.1.13.80: Flags [s], cksum 0x1999 (correct), seq 3381369201, win 4380, options [mss 1460,sackOK,eol], length 0
19:04:17.917751 IP (tos 0x0, ttl 241, id 28771, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.54273 > 192.168.1.13.80: Flags [s], cksum 0x6cef (correct), seq 3699219465, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490543132 ecr 0,sackOK,eol], length 0
19:04:20.925052 IP (tos 0x0, ttl 241, id 32972, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.54273 > 192.168.1.13.80: Flags [s], cksum 0x6137 (correct), seq 3699219465, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490546132 ecr 0,sackOK,eol], length 0
19:04:24.117662 IP (tos 0x0, ttl 241, id 46327, offset 0, flags [DF], proto TCP (6), length 64)
92.90.XXX.XXX.54273 > 192.168.1.13.80: Flags [s], cksum 0x54b7 (correct), seq 3699219465, win 4380, options [mss 1460,nop,wscale 0,nop,nop,TS val 1490549332 ecr 0,sackOK,eol], length 0
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernelDernière modification par rafy47 (Le 24/02/2011, à 19:13)
Hors ligne
#30 Le 24/02/2011, à 20:14
- tooney
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Donc si je résume, on voit les paquets arriver sur le port 80, mais aucune sortie de ce port (le tcpdump et iptables nous le montrent bien).
Comme si l'anti-spoofing était encore actif 
Peut-être une chose toute bête à faire :
- vérifie que le paramètre rp_filter est bien à 0 pour toutes tes interfaces
- redémarre le service réseau :
sudo service networking restart
ou
/etc/init.d/networking restartJe pense qu'il faut tout simplement redémarrer la couche réseau pour que le paramètre soit pris en compte!
Loi de Bonaldi appliquée à Linux : L’expérience prouve que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
Hors ligne
#31 Le 24/02/2011, à 21:32
- rafy47
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
AAAAAAAAAAAAAAAAAAAAAAAAAAAAH
j'ai trouvé !!!!
Dans un premier temps, j'ai tenté le redémarrage mais ça passait pas.
J'ai relu ton analyse et alors j'ai voulu reprendre étape par étape : en fouinant du côté du /proc/sys/net/ipv4/conf j'ai vu qu'en plus de eth0 et ppp0 il y avait aussi lo et all : j'ai repassé le rp_filter pour les deux à 0... et ça roule !!!
Un énorme merci à toi Tooney pour ta patience et tes conseils !!!
Je vais tenter de reprendre mes anciens filtres sur iptables, compléter le tout avec ce que tu m'as fais tester.
Hors ligne
#32 Le 24/02/2011, à 21:42
- tooney
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Bon courage à toi, et hésite pas à revenir si t'as besoin d'un coup de main sur le filtrage
Tchuss!
Loi de Bonaldi appliquée à Linux : L’expérience prouve que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
Hors ligne
#33 Le 24/02/2011, à 22:09
- tooney
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Bizarre quand même ton histoire de rp_filter... Je viens de vérifier ma conf, et la seule interface où j'ai eu besoin de désactiver l'anti-spoofing est eth1 (dans ton cas eth0)... Ce qui est assez logique somme toute...
Bon ceci dit, je te joins mon script de démarrage "iptables", ça pourra peut-être te donner des idées :
#!/bin/sh
#
# Script de mise en place des règles de filtrage réseaux
# et du policy routing
#
start() {
# initialisation du périphérique internet
/sbin/ifup eth1
# Dans cette partie, on met en place le firewall
# vidage des chaines
iptables -F
# destruction des chaines personnelles
iptables -X
# stratégies par défaut
iptables -P INPUT DROP
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
# init des tables NAT et MANGLE (pas forcément nécessaire)
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
iptables -t mangle -F
iptables -t mangle -X
iptables -t mangle -P PREROUTING ACCEPT
iptables -t mangle -P OUTPUT ACCEPT
# Acceptation de toutes les connexions en local
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Maintien des sessions ouvertes sur serveur local
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
####################################################################################
#### Acces au serveur local - creation de la chaine INPUT (table FILTER) #####
####################################################################################
#######
### Services accessibles sur tous les ports (eth0, eth1, tun0, tun1)
# Ouverture port pour acces SSH
iptables -A INPUT -p tcp --dport ssh -j ACCEPT
# Ouverture ports serveur DNS local
iptables -A INPUT -p udp --dport 53 -j ACCEPT
iptables -A INPUT -p tcp --dport 53 -j ACCEPT
# Ouverture ports serveur DHCP local
iptables -A INPUT -i eth0 -p udp --dport 67 -j ACCEPT
# Ouverture ports serveur Web + FTP
iptables -A INPUT -p tcp --dport www -j ACCEPT
iptables -A INPUT -p tcp --dport ftp -j ACCEPT
iptables -A INPUT -p tcp --dport ftp-data -j ACCEPT
# Ouverutre port pour serveur Squid
iptables -A INPUT -i! tun1 -p tcp --dport 3128 -j ACCEPT
# Ouverture ports serveur OpenVPN local
iptables -A INPUT -i! tun1 -p tcp --dport 443 -j ACCEPT
# .....
# Plein d'autres règles ACCEPT pour les différents services réseaux
# .....
## Regles de Policy Routing
# Le trafic "marqué" passe par l'acces Free, et non par le tunnel VPN
# On desactive l'anti-spoofing
echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter
# On active le filtrage arp par interface (evite reponses arp sur eth0 + eth1)
echo 1 > /proc/sys/net/ipv4/conf/eth0/arp_filter
echo 1 > /proc/sys/net/ipv4/conf/eth1/arp_filter
# Ajout de la regle de routage
ip rule del prio 32765
ip rule add fwmark 1 table policy prio 32765
# On installe la route par defaut vers la Freebox pour les paquets marqués
ip route add default via 192.168.10.1 dev eth1 table policy
# On oblige le LAN a passer en direct par Free
iptables -A PREROUTING -t mangle -s 192.168.0.0/24 -d! 10.8.0.0/24 -j MARK --set-mark 1
# On oblige les services heberges sur le serveur a repondre par l'acces Free
iptables -A OUTPUT -t mangle -s! 192.168.0.0/24 -d! 10.8.0.0/24 -p tcp --sport 80 -j MARK --set-mark 1
#iptables -A OUTPUT -t mangle -s! 192.168.0.0/24 -d! 10.8.0.0/24 -p tcp --sport 22 -j MARK --set-mark 1
iptables -A OUTPUT -t mangle -s! 192.168.0.0/24 -p tcp --sport 443 -j MARK --set-mark 1
# Les DNS passent directement par l'acces Free
iptables -A OUTPUT -t mangle -p tcp --dport 53 -j MARK --set-mark 1
iptables -A OUTPUT -t mangle -p udp --dport 53 -j MARK --set-mark 1
# activation du forwarding dans le noyau
# mise en place du partage de connexion sur le réseau local
echo 1 >/proc/sys/net/ipv4/ip_forward
# On natte les machines du LAN vers l'interface de sortie (-o! eth0 = eth1 ou tun1 selon celle qui est active)
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o! eth0 -j MASQUERADE
# Redemarrage des connexions VPN
/etc/init.d/openvpn restart
}
stop() {
echo 0 >/proc/sys/net/ipv4/ip_forward
ifdown eth1
}
case "$1" in
start)
start
;;
stop)
stop
;;
restart)
stop && start
;;
*)
echo "Usage $0 {start|stop|restart}"
exit 1
esac
exit 0Concernant l'activation du paramètre arp_filter, c'est utile uniquement si tu as plusieurs interfaces physiques sur un même serveur.
Loi de Bonaldi appliquée à Linux : L’expérience prouve que c’est lorsqu’on dit « tu vas voir, linux c’est facile » que se produisent les pannes.
Hors ligne
#34 Le 19/11/2013, à 16:22
- Bimbadaboom
Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port
Bonjour,
Je fais un up pour ce post car j'ai également le même problème
J'ai un serveur Ubuntu server 13.04 qui se connecte à un VPN PPTP
Voici mon fichiers de configuration vpn:
pty "pptp $VPNHOSTNAME --nolaunchpppd --debug"
name $USERNAME
password $PASSWORD
remotename PPTP
require-mppe-128
require-mschap-v2
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
noauth
debug
persist
maxfail 0
defaultroute
replacedefaultroute
Pour que la totalité de mon traffic passe par l'interface ppp0 j'ai ajouté ces deux lignes:
defaultroute
replacedefaultroute
Pas de souci jusqu'à là tous fonctionne.
Mais, j'aimerais pouvoir communiquer en SSH sur mon seveur, ceci est impossible des que le VPN est en route car l'interface ppp0 est la route par defaut.
J'aimerais donc exclure de la route par défaut (ppp0) le port ssh (22)
Je pense qu'il faut le force sur mon interface eth0 ...
J'imagine que iptables doit pouvoir le faire, mais j'avoue je suis un peu perdu ...
Une idée?
Merci
Dernière modification par Bimbadaboom (Le 19/11/2013, à 16:24)
Hors ligne