[Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

tooney · Le 21/08/2010, à 15:17

Bonjour à tous!

Aujourd'hui j'ai décidé de m'attaquer à un problème un peu compliqué...

Chez moi j'ai un serveur Apache avec une interface eth1 qui accède à Internet (connecté en direct à une Freebox).

J'ai souscrit une offre VPN par OpenVPN. La connexion se fait à travers eth1 et monte une nouvelle interface tun1. A partir de là, tout le trafic passe par tun1 par le tunnel VPN.

Donc jusqu'ici tout va bien. De plus mon offre VPN est avec IP dédiée et redirection de port, et j'accède bien à mon serveur Apache par l'adresse IP WAN du VPN, pas de soucis.

Mais bon voilà, ça m'ennuie que mon serveur Apache soit joignable à travers le VPN. Je préférerais qu'il continue à passer par mon accès Free direct, donc eth1.

Avec un bon routeur Cisco, c'est faisable. Donc je me suis dit, y a pas de raison qu'on ne puisse pas le faire avec Linux!

J'ai donc suivi l'exemple qu'on trouve ici : http://www.tldp.org/HOWTO/Adv-Routing-H … ilter.html.

Bon je l'ai un peu adapté puisque ce n'est pas exactement ce que je veux faire pour la règle iptables :

# iptables -A PREROUTING -i lo -t mangle -p tcp --sport 80 -j MARK --set-mark 1

Avec un tcpdump, je vois bien le flux arriver sur le port 80 de mon serveur quand j'essaye de le joindre de l'extérieur en passant par la Freebox :

# tcpdump -n -i eth1 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:12:30.436080 IP 85.249.XXX.XXX.8619 > 192.168.XXX.XXX.80: S 1590689374:1590689374(0) win 8192 <mss 1368,nop,wscale 2,nop,nop,sackOK>
15:12:33.420046 IP 85.249.XXX.XXX.8619 > 192.168.XXX.XXX.80: S 1590689374:1590689374(0) win 8192 <mss 1368,nop,wscale 2,nop,nop,sackOK>

Par contre je ne vois rien qui se passe dans les logs Apache... Comme si le flux arrivait bien sur l'interface eth1, mais n'était pas traité par la couche applicative...

Quelqu'un a-t-il une piste ?

Dernière modification par tooney (Le 22/08/2010, à 18:17)

pat_bateman · Le 21/08/2010, à 15:48

Si je comprends bien tu veux qu'apache n'écoute que sur eth1?
Pourquoi ne pas spécifier un listen (listen IP_ADDRESS:PORT) sur l'interface eth1 dans ta conf apache?

-Pat

tooney · Le 21/08/2010, à 16:08

Merci pour ta réponse Pat. En fait j'ai une interface LAN (eth0) et une WAN (eth1).
Le VPN (tun1) est monté sur eth1.

Je veux qu'Apache puisse tout de même répondre en local sur le LAN (eth0).

Mais tu as raison, du coup ma conf iptables n'était pas tout à fait exact, il me manque des règles...

pat_bateman · Le 21/08/2010, à 17:18

Si tu as un listen sur l'IP eth0 et l'IP eth1 ça devrait faire l'affaire.
tun1 doit posséder sa propre adresse IP il me semble?
Et si tu veux jouer avec IP table il manque effectivement des règles, ce que tu as mis plus haut permet seulement de marquer le paquet.

-Pat

tooney · Le 21/08/2010, à 17:46

pat_bateman a écrit :

Si tu as un listen sur l'IP eth0 et l'IP eth1 ça devrait faire l'affaire.
tun1 doit posséder sa propre adresse IP il me semble?

Je vais essayer, mais je ne suis pas sûr que ça fonctionne. En plus je veux faire ça pour plusieurs services (FTP, SSH,...). Je préfère le faire avec le Policy Routing.

pat_bateman a écrit :

Et si tu veux jouer avec IP table il manque effectivement des règles, ce que tu as mis plus haut permet seulement de marquer le paquet

Tu n'as pas lu le lien que j'ai mis en copie La règle iptables n'est que la première étape. On marque le paquet avant qu'il ne soit routé. Ensuite le "Policy Routing" permet de router non plus par rapport à l'adresse IP destination (routage classique), mais par rapport au marquage effectué avec iptables. Voici mes règles :

# echo 201 apache >> /etc/iproute2/rt_tables
# ip rule add fwmark 1 table apache
# ip route add default via @IP_freebox dev eth1 table apache

Pour faire le parallèle avec Cisco, c'est la méthode utilisée pour le routage grâce aux ACL étendues (contrairement au routage standard).

pat_bateman · Le 21/08/2010, à 18:04

tooney a écrit :

Je vais essayer, mais je ne suis pas sûr que ça fonctionne. En plus je veux faire ça pour plusieurs services (FTP, SSH,...). Je préfère le faire avec le Policy Routing.

ça complique l'affaire! FTP et SSH écoutent sur toutes tes interfaces, il suffit de bloquer le trafic sur l'interface tun1 ainsi ftp et SSH restent accessibles via les autres interface. Mais je me demande si je comprends bien ton problème...
Si tu veux continuer avec le policy routing (ça ne semble pas simple sous linux!), tu devrais peut être activer l'ip forwarding pour que les paquets passent d'une interface à l'autre.
echo 1 > /proc/sys/net/ipv4/ip_forward

tooney a écrit :

Tu n'as pas lu le lien que j'ai mis en copie

Si justement, et je pensais que tu t'étais arrêté à la première règle
Juste une question, pourquoi la première règle d'iptables est sur lo?

Je pense qu'ici s'arrête ma compétence en la matière.

Bon courage

-Pat

tooney · Le 21/08/2010, à 18:17

pat_bateman a écrit :

echo 1 > /proc/sys/net/ipv4/ip_forward

En fait ce serveur Linux me sert également de passerelle / firewall pour le reste de mon LAN. Donc l'IP forwarding est bien sûr activé.

pat_bateman a écrit :

Juste une question, pourquoi la première règle d'iptables est sur lo?

En fait, ma règle iptable se traduirait comme suit :
"Tous les paquets provenant du localhost (-i lo) et comprenant le port source TCP/80 (-p tcp --sport 80) doivent être marqués avec le chiffre 1 (-j MARK --set-mark 1)"

Les paquets sont donc marqués dans la table mangle en PREROUTING, donc avant la décision de routage.

Ensuite, le serveur/routeur consulte ses "tables" de routage. Il voit que pour les paquets marqués de 1, il faut qu'il suive la table de routage "apache" :

# ip rule ls
0:      from all lookup local
32765:  from all fwmark 0x1 lookup apache
32766:  from all lookup main
32767:  from all lookup default

En consultant la table "apache", il voit que la default gateway est définie vers la Freebox via eth1 :

# ip route show table apache
default via 192.168.10.1 dev eth1

Dernière modification par tooney (Le 21/08/2010, à 18:20)

pat_bateman · Le 21/08/2010, à 18:26

Effectivement ça a du sens. Je ne vois pas la faille du coup.
Tu devrais essayer la même chose avec le port 443 et SSH pour voir si c'est un problème applicatif.

-Pat

tooney · Le 21/08/2010, à 18:32

Bon je pense que je me suis planté... C'est plutôt au niveau de la chaine OUTPUT qu'il faut faire le marquage !

En changeant ma règle iptables pour :

sudo iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark 1

mon serveur web ne répond plus non plus par l'adresse IP du VPN.

Je pense que je suis sur la bonne voie!

tooney · Le 21/08/2010, à 20:49

Bon ça ne marche toujours pas... A mon avis l'interface tun1 modifie la façon dont eth1 reçoit les informations, mais j'arrive pas à voir à quel niveau...

tooney · Le 22/08/2010, à 01:08

Ouf!!! J'ai enfin trouvé la réponse à mon problème, et j'aurais pu chercher longtemps sans jamais trouver...

J'ai trouvé la réponse par hasard sur ce site : http://www.clintoneast.com/articles/multihomed.php

En fait ma configuration (iptables + iproute) était bonne! Je trouvais ça étonnant que les paquets arrivent bien sur l'interface eth1, mais ne soient pas remontés à la couche applicative (Apache).

En fait, j'aurais du y penser, c'était tout simplement du à l'anti-spoofing activé par défaut...

Je l'ai désactivé grâce à la commande :

# echo 0 > /proc/sys/net/ipv4/conf/eth1/rp_filter

et comme par magie, tout est passé!

Bon il m'a fallu affiner ma commande iptables pour que le LAN (eth0) puisse continuer à accéder au serveur :

iptables -A OUTPUT -t mangle -s! 192.168.0.0/24 -p tcp --sport 80 -j MARK --set-mark 1

Merci pat_bateman pour ton aide J'espère que mon post pourra être utile à quelqu'un. J'essaierai d'en faire un tuto sur mon blog.

A+

Dernière modification par tooney (Le 22/08/2010, à 01:09)

rafy47 · Le 22/02/2011, à 18:15

Bonjour
Désolé de faire du déterrage de topic, mais a priori ma problématique correspond bien au problème de départ et je finis par m'arracher les cheveux dessus.
Comme tooney j'ai activé une connexion vpn (PPTP) et je souhaite pouvoir continuer accéder à mon Apache, via ma redirection no-ip.
Je me retrouve donc avec trois interfaces ppp0, eth0 et lo. Dans un premier temps, je suis parti de l'idée que l'ensemble du trafic devait passer par le vpn et que je devrais rediriger les paquets émanant des port 443 et 80 vers la eth0.
Comme évoqué dans l'échange plus haut, avec tcpdump, je voyais bien les paquets arriver sur le serveur mais celui-ci ne remontait alors rien au client : j'ai remplacé la valeur de rp_filter, sans plus de succès.

Je suis passé dans la problématique inverse : limiter le trafic dans le vpn à un port, et laisser le trafic par défaut sur eth0... mais là non plus je ne brille pas plus.
Voilà mon script pour le 2e cas que je cherche à mettre en oeuvre.
Le port 8080 est donc celui pour lequel que je veux que mes paquets transitent via le VPN, mon routeur est sur 192.168.1.50, et mon serveur a l'IP 192.168.1.13.

#!/bin/bash
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -F
iptables -t filter -X
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 8080 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 8080 -j ACCEPT


iptables -t filter -A INPUT -p tcp --dport 1723 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 1723 -j ACCEPT
iptables -A INPUT -p gre -i eth0 -j ACCEPT
iptables -A OUTPUT -p gre -o eth0 -j ACCEPT

iptables -A OUTPUT -m state --state NEW -o ppp0 -j ACCEPT
iptables -A OUTPUT -t mangle -s! 192.168.1.0/24 -p tcp --sport 8080 -j MARK --set-mark 1
echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter
echo 1 > /proc/sys/net/ipv4/ip_forward
echo 201 tom >> /etc/iproute2/rt_tables
ip rule add fwmark 1 table tom
ip route add default dev ppp0 table tom

Si jamais vous pouviez me faire avancer sur mon problème, ça serait super sympa :s

Dernière modification par rafy47 (Le 22/02/2011, à 18:19)

tooney · Le 24/02/2011, à 10:50

Bonjour rafy47

Bon alors nous allons essayer de t'aider un peu...

Pour commencer, il faut que je clarifie mon install par rapport à la tienne :

- Mon installation : mon serveur iptables en coupure de deux LAN (192.168.0.0 /24 et 192.168.10.0 /24, donc deux interfaces physiques) avec une patte directement connectée sur ma Freebox (192.168.10.254 <=> 192.168.10.1). Ma connexion VPN établie est faite par OpenVPN par un fournisseur VPN (ce qui signifie qu'à chaque connexion VPN, mes tables de routage sont complétement effacées par sa conf...)

- Ton installation : Un LAN (192.168.1.0 /24) comprenant tous tes équipements (I guess...?) dont un serveur Linux (avec service Apache sur le port 8080) initiant une connexion VPN PPTP.

A noter plusieurs points importants dans ma configuration :
- Pour accéder à des services sur mon adresse IP perso (Freebox) : j'ai NATé sur la Freebox les ports correspondant (basiquement j'ai un serveur web sur mon Linux, donc j'ai ouvert le port 80 sur ma Freebox)
- Pour accéder à des services sur mon adresse IP fournie par VPN (et ce point est très important!!!) : j'ai demandé à mon fournisseur d'accès de NATer certains ports vers le endpoint du tunnel OpenVPN (mon serveur Linux)

De base je vois plusieurs erreurs sur les lignes suivantes :

iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT

iptables -t filter -A INPUT -p tcp --dport 8080 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 8080 -j ACCEPT

Dans la première partie, tu as des lignes identiques répétées deux fois. A mon avis tu voulais mettre ceci :

iptables -t filter -A INPUT -p tcp --dport 80 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --sport 80 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --sport 443 -j ACCEPT

Idem pour la deuxième partie :

iptables -t filter -A INPUT -p tcp --dport 8080 -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --sport 8080 -j ACCEPT

En sortie, tes paquets ont comme port source le numéro de port correspondant à ton service. Donc --dport devient --sport

Ceci dit, pour debugger tout ça, je te conseille dans un premier temps de :

- Désactiver toutes les règles iptables :

iptables -t filter -P INPUT ACCEPT
iptables -t filter -P OUTPUT ACCEPT
iptables -t filter -P FORWARD ACCEPT

iptables -t filter -F

- Une fois qu'il n'y a plus de règle parasite, active ton VPN et indique nous la sortie des commandes :

- ifconfig
- ip route show
- iptables -L -nv -t filter

Pour commencer, je crois que ce sera déjà bien

rafy47 · Le 24/02/2011, à 12:51

Merci pour ta réponse Tooney !
Effectivement pour les règles et les doublons, ce sont bien des coquilles.
Pour reprendre, je suis donc reparti du cas où tout transite par le vpn, moins l'apache que je veux joindre via le port 443 ou le 80.
Pour la conf, effectivement l'ensemble de mes machines sont en 192.168.1.*, gérées par un routeur en 192.168.1.50, immédiatement derrière ma Freebox. La machine sur laquelle j'établis ma connexion VPN et que je veux pouvoir joindre a pour IP 192.168.1.13.
Après connexion sur le VPN (également fourni par un provider dédié), je me retrouve avec 3 interfaces (sans compter lo), eth0, wlan0 (inutilisé) et ppp0.

pour les traces, les voici

$ifconfig
eth0      Link encap:Ethernet  HWaddr 00:e0:4c:XX:XX:XX  
          inet adr:192.168.1.13  Bcast:192.168.1.255  Masque:255.255.255.0
          adr inet6: fe80::2e0:4cff:fe68:6e17/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          Packets reçus:222620 erreurs:0 :0 overruns:0 frame:0
          TX packets:156065 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:145550735 (145.5 MB) Octets transmis:32849995 (32.8 MB)
          Interruption:45 Adresse de base:0xc000 

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          Packets reçus:12958 erreurs:0 :0 overruns:0 frame:0
          TX packets:12958 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          Octets reçus:7460335 (7.4 MB) Octets transmis:7460335 (7.4 MB)

ppp0      Link encap:Protocole Point-à-Point  
          inet adr:69.80.XXX.XXX  P-t-P:192.168.35.108  Masque:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1396  Metric:1
          Packets reçus:611 erreurs:0 :0 overruns:0 frame:0
          TX packets:588 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:3 
          Octets reçus:329303 (329.3 KB) Octets transmis:117681 (117.6 KB)

wlan0     Link encap:Ethernet  HWaddr 00:18:XX:XX:XX:35  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          Packets reçus:0 erreurs:0 :515 overruns:0 frame:0
          TX packets:53136 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          Octets reçus:0 (0.0 B) Octets transmis:3931936 (3.9 MB)
          Interruption:18 Mémoire:f8098000-f8098100 

$ip route show
192.168.35.108 dev ppp0  proto kernel  scope link  src 69.80.XXX.XXX 
216.168.YYY.YYY via 192.168.1.50 dev eth0  src 192.168.1.13 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.13  metric 1 
169.254.0.0/16 dev eth0  scope link  metric 1000 
default dev ppp0  scope link 

$iptables -L -nv -t filter
Chain INPUT (policy ACCEPT 2599 packets, 914K 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 2476 packets, 406K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain LOG_REJECT_SMTP (0 references)
 pkts bytes target     prot opt in     out     source               destination

tooney · Le 24/02/2011, à 14:38

OK donc tout est assez logique au niveau routage sur ton serveur. D'après ce que je lis, la connexion VPN est bien établie, et par défaut tout le trafic passe par là.

Au niveau de ton routeur, je suppose que ta Freebox est en mode transparent, et que ton routeur a directement une adresse IP joignable depuis Internet...?

Dans ce cas, je suppose que les ports 80 et 443 sont nattés sur ton routeur vers ton serveur Linux. Lorsque le VPN est désactivé, ton serveur est donc joignable depuis Internet sur ces ports ?

C'est la base mais je préfère m'en assurer

Donc deuxième point, nous allons essayer de rediriger les flux des ports 80 et 443 vers le LAN (192.168.1.50), et non vers le VPN.

Mmmmm... En fait, étant donné que tu n'as qu'un seul LAN, et que ton routeur NAT les paquets entrants, ton serveur va avoir l'impression que les requêtes depuis Internet proviennent du 192.168.1.50. Je me demande donc s'il est vraiment nécessaire de marquer les paquets et de faire du policy routing. En effet, le LAN a une route spécifique (192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.13 metric 1).

Essaye juste de désactiver l'anti-spoofing pour voir :

echo 0 > /proc/sys/net/ipv4/conf/eth0/rp_filter
echo 0 > /proc/sys/net/ipv4/conf/ppp0/rp_filter

Dernière modification par tooney (Le 24/02/2011, à 14:42)

tooney · Le 24/02/2011, à 14:40

Avec cette conf basique, peux-tu nous dire également si ton serveur Apache est joignable depuis une autre machine de ton LAN ?

On verra pour remettre le filtrage après...

tooney · Le 24/02/2011, à 14:43

Ah j'oubliais également!!! Il faut que tu vires le marquage de paquet sur ta table mangle :

iptables -t mangle -F

rafy47 · Le 24/02/2011, à 15:22

je te confirme : le VPN stoppé, j'accède sans problème à mon serveur depuis l'extérieur : côté routeur, la redirection port extérieur/machine:port passe bien.
Côté antispoofing : sur eth0 c'était bon ; j'ai fait la modif sur ppp0.
J'ai exécuté la commande que tu m'as donné plus haut pour mangle et ça ne passe pas encore :s

Par contre, il me reste d'autre traces quand je fais un :

$ ip rule ls
0:      from all lookup local
32764:  from all fwmark 0x1 lookup 201
32765:  from all fwmark 0x1 lookup 201
32766:  from all lookup main
32767:  from all lookup default

je supprime aussi ces règles ?
Sinon, sur le LAN je n'ai pas de problème en fait : j'ai bien accès au serveur depuis une autre machine. C'est quand je suis à l'extérieur que ça coince :-s
Et le plus étrange, c'est qu'en suivant tes indications du début par rapport à tcpdump, je voyais bien des appels lorsque je cherchais à accéder à mon serveur, le VPN lancé, même si celui-ci ne renvoyait rien :s

tooney · Le 24/02/2011, à 15:52

Ok alors forçons la réponse de ton serveur Apache à passer par le LAN :

# Marquage des paquets provenant d'Apache
iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark 1

# Ajout de la route par défaut pour les paquets marqués vers le routeur du LAN
ip route add default via 192.168.1.50 dev eth0 table tom

Tous tes paquets ayant le port source 80 seront marqués avec le flag "1". Automatiquement la table de routage qui va être appliquée sera "tom" sur ces paquets, et les flux seront redirigés vers ton routeur. Par contre juste avec ça, je ne suis pas sûr que ton service soit toujours joignable du LAN. On planchera là-dessus après.

Concernant ta remarque sur les doublons dans ip rule ls, j'avais remarqué ça aussi dans ma conf. Ce que je fais dans mon script est que je supprime toutes les tables avant de la remettre (ip rule add fwmark 1 table tom).
Mais bon on mettra ton script à jour plus tard. Pour l'instant ces lignes existent déjà dans tes règles, donc tu peux les laisser.

rafy47 · Le 24/02/2011, à 17:06

Bon je n'y comprends plus rien...
J'ai bien vidé mangle, rajouté la règle de marquage et la règle de routage des paquets marqués.
Ça ne passe toujours pas : voilà ce que j'ai quand je fais un ip route show

$ip route show
216.168.XXX.XXX via 192.168.1.50 dev eth0  src 192.168.1.13
192.168.35.52 dev ppp0  proto kernel  scope link  src 69.80.YYY.YYY
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.13  metric 1
169.254.0.0/16 dev eth0  scope link  metric 1000
default dev ppp0  scope link

et voilà la partie tom

ip route show table tom
default via 192.168.1.50 dev eth0

Dernière modification par rafy47 (Le 24/02/2011, à 17:14)

tooney · Le 24/02/2011, à 17:31

Tu disais que tu voyais tout de même les paquets arriver au niveau de ton serveur. Peux-tu nous donner quelques lignes d'un tcpdump sur les interfaces eth0 et ppp0 :

tcpdump -i eth0 port 80
tcpdump -i ppp0 port 80

rafy47 · Le 24/02/2011, à 17:46

Voilà ce que me donnent les tcpdump

$ tcpdump -i eth0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
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 0
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 0
16:35:45.592828 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 0
16:35:47.404250 IP 69.80.XXX.XXX.53728 > XXXXXXXX-in-f139.1e100.net.www: Flags [s], seq 341273755, win 5424, options [mss 1356,sackOK,TS val 37808688 ecr 0,nop,wscale 6], length 0
^C

$ tcpdump -i ppp0 port 80
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

Rien sur ppp0 donc : mais a priori c'est plutôt normal, non ?

tooney · Le 24/02/2011, à 17:55

Je suppose que sur les lignes suivantes :

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 0

Il s'agit d'un trafic http de ta part depuis le serveur en passant par le VPN (69.80.XXX.XXX) vers l'extérieur (XXXXXXXX-in-f139.1e100.net.www).

Sinon une commande qui peut être utile lorsque des modifications de routage ont été effectuées :

ip route flush cache

tooney · Le 24/02/2011, à 18:02

Egalement si tu veux voir si une règle iptables est matchée (je pense à iptables -A OUTPUT -t mangle -p tcp --sport 80 -j MARK --set-mark 1), tu fais plusieurs :

iptables -L -nv -t mangle

et tu regardes si le nombre de paquets s'incrémente (bien sûr il faut générer des requêtes entre chaque commande )

Dernière modification par tooney (Le 24/02/2011, à 18:02)

rafy47 · Le 24/02/2011, à 18:02

Les données du tcpdump viennent d'un appel depuis l'extérieur vers le serveur.
Si 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
J'ai tenté le

 ip route flush cache

et ai retenté de me connecter dans la foulée, en vain.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 21/08/2010, à 15:17

[Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#2 Le 21/08/2010, à 15:48

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#3 Le 21/08/2010, à 16:08

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#4 Le 21/08/2010, à 17:18

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#5 Le 21/08/2010, à 17:46

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#6 Le 21/08/2010, à 18:04

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#7 Le 21/08/2010, à 18:17

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#8 Le 21/08/2010, à 18:26

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#9 Le 21/08/2010, à 18:32

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#10 Le 21/08/2010, à 20:49

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#11 Le 22/08/2010, à 01:08

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#12 Le 22/02/2011, à 18:15

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#13 Le 24/02/2011, à 10:50

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#14 Le 24/02/2011, à 12:51

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#15 Le 24/02/2011, à 14:38

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#16 Le 24/02/2011, à 14:40

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#17 Le 24/02/2011, à 14:43

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#18 Le 24/02/2011, à 15:22

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#19 Le 24/02/2011, à 15:52

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#20 Le 24/02/2011, à 17:06

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#21 Le 24/02/2011, à 17:31

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#22 Le 24/02/2011, à 17:46

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#23 Le 24/02/2011, à 17:55

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#24 Le 24/02/2011, à 18:02

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

#25 Le 24/02/2011, à 18:02

Re : [Résolu] VPN et Policy Routing - routage de flux hors VPN selon port

Pied de page des forums