Ipredator, protocole GRE

Support Debian
#1

Bonjour,

J’ai souscris au VPN ipredator, qui ne propose actuellement que du pptp.

Configuration ethernet :
1 box qui NAT
1 poste de travail sous Debian 6 (k2.6.32)

Le tunnel est fonctionnel (configuré via le shell) et je souhaite configurer netfilter (sur le poste de travail) moi-même :

avec ces règles pas de soucis, le tunnel est fonctionnel :
code:

modprobe ip_conntrack
modprobe ip_conntrack_pptp
iptables -F
iptables -X
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p ICMP -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p ICMP -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p UDP --dport 53 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p UDP --sport 53 -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p TCP --dport 80 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p TCP --sport 80 -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p TCP --dport 443 -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p TCP --sport 443 -j ACCEPT

iptables -A INPUT -p gre -j ACCEPT
iptables -A OUTPUT -p gre -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED -p tcp --sport 1723 -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p tcp --dport 1723 -j ACCEPT

Le gros problème c’est que là je laisse passer n’importe quel paquet de n’importe quelle provenance - connexion initiée ou non - pour peu qu’il possède un header GRE !

Pour “limiter la casse” j’ai filtré par état :
code :

iptables -A INPUT -m state --state ESTABLISHED -p gre -j ACCEPT
iptables -A OUTPUT -m state --state NEW,ESTABLISHED -p gre -j ACCEPT

Et là, c’est le drame ! La connexion pptp avec le serveur ipredator tombe (l’iface ppp0 aussi).

1/ Quels moyens ai-je pour cerner et corriger ce problème ?
2/ Je désirerais aussi filter par port, mais lequel dois-je filtrer ?

Sinon il y a aussi la stratégie d’authoriser le protocole GRE par ip de serveur, cependant je n’ai trouvé qu’une seule liste (joes.anarcho.dk/scripts/9999_whitelist_ipredator) et donc je ne peux pas croiser cette information.

3/ Comment trouver toutes les adresses ip des serveurs correspondantes a un nom de domaine spécifique (ici ipredator.se).

Merci d’avance car je sèche lamentablement ! :017

#2

Pour analyser le problème, examiner les caractéristiques et notamment dans quel état de suivi de connexion (NEW, ESTABLISHED, RELATED, INVALID) sont classés les paquets GRE bloqués en ajoutant des règles LOG pour chaque état dans les chaînes INPUT et OUTPUT.

Pour corriger, tu peux essayer d’ajouter l’état RELATED dans tes deux règles car le module ip_conntrack_pptp (qui s’appelle en réalité nf_conntrack_pptp maintenant, mais ce n’est pas gênant, ip_conntrack_pptp reste défini comme alias) a précisément comme fonction de marquer comme RELATED les paquets GRE (au moins le premier) liés à une connexion PPTP existante.

Visiblement tu l’a déjà fait, pour les ports 80 et 443 en TCP et 53 en UDP.

Tout simplement avec dig, host ou nslookup suivi du nom de domaine. Mais ipredator.se n’a qu’une seule adresse IP, je suppose que tu voulais dire vpn.ipredator.se ?

A noter que si on met un nom de domaine qui a plusieurs adresses IP comme source ou destination dans une règle iptables, iptables crée une règle différente avec chaque adresse IP.

#3

Merci beaucoup de m’avoir répondu, grace à toi j’ai un peu progressé :005

Oui en effet, comme il me manquait la fin de l’adresse je ne pouvais pas allez bien loin.
J’avais pour acquis d’ailleurs que netfilter ne travaillait qu’avec les ip, mais en effet il fait aussi les résolutions !

Donc pour la règle du protocole GRE filtrée par ip serveur c’est bon, une bonne première étape de bouclée :023

Et puis j’ai aussi testé ce que tu m’a conseillé :

iptables -A INPUT -m state --state RELATED,ESTABLISHED -p gre -j ACCEPT iptables -A OUTPUT -m state --state NEW,RELATED,ESTABLISHED -p gre -j ACCEPT iptables -A INPUT -p gre -j LOG --log-prefix "--GRE-in" iptables -A OUTPUT -p gre -j LOG --log-prefix "--GRE-out"

Mais la pareil cela ne passe pas, dans mon syslog je trouve :

Jul 18 05:56:58 debian kernel: [ 692.998003] --GRE-inIN=eth1 OUT= MAC=00:0d:60:13:9f:95:00:24:d4:b7:6b:2a:08:00 SRC=93.182.185.2 DST=192.168.0.13 LEN=95 TOS=0x00 PREC=0x00 TTL=57 ID=60366 DF PROTO=47 (...) Jul 18 05:59:17 debian kernel: [ 831.221696] --GRE-inIN=eth1 OUT= MAC=00:0d:60:13:9f:95:00:24:d4:b7:6b:2a:08:00 SRC=93.182.185.2 DST=192.168.0.13 LEN=53 TOS=0x00 PREC=0x00 TTL=57 ID=60703 DF PROTO=47 Jul 18 05:59:17 debian pptp[990]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed Jul 18 05:59:17 debian pptp[990]: anon log[callmgr_main:pptp_callmgr.c:258]: Closing connection (shutdown) Jul 18 05:59:17 debian pptp[990]: anon log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 12 'Call-Clear-Request' Jul 18 05:59:17 debian pptp[990]: anon log[pptp_read_some:pptp_ctrl.c:544]: read returned zero, peer has closed Jul 18 05:59:17 debian pptp[990]: anon log[call_callback:pptp_callmgr.c:79]: Closing connection (call state) Jul 18 05:59:17 debian pppd[931]: Modem hangup
Donc que du “–GRE-in” aucun “out”, j’ai sabré la cinquantaine de lignes identiques.

Après je me suis rendu compte que quand j’active ces règles

iptables -A INPUT -p gre -s vpn.ipredator.se -j ACCEPT iptables -A OUTPUT -p gre -d vpn.ipredator.se -j ACCEPT
après avoir changé le routage :

 # route add default dev ppp0 ; route del default dev eth1 ; cp resolv.conf.odns /etc/resolv.conf

iptables ne fait pas la résolution de vpn.ipredator.se
Si j’inverse la procédure ca marche (règles iptables puis route par défaut ppp0).

En fait actuellement je ne peux exploiter la connexion vpn qu’avec les serveurs odns, ceux de mon FAI ne fonctionnent pas avec ou sans pare-feu (les dns FAI marchent dans le cadre d’une connexion classique).

Je suis allé faire un tour dans /etc/ppp/options mais je n’ai trouvé qu’une section ms-dns.

J’ai plus le temps de chercher ce matin, mais je m’y remets ce soir, si tu as compris un truc que j’ai laissé passé n’hésites pas :stuck_out_tongue:

reste à faire :

  • régler le problème de dns
  • filtrer par état

Merci encore ++

#4

C’est bon, je filtre par ip serveur, état et port concernant ipredator.

Je n’ai pas encore compris pourquoi netfilter ne résoud pas les adresses quand je suis en mode tunnel avec les open DNS, mais l’essentiel c’est que mes règles soient fonctionnelles !

Merci beaucoup pour ta précieuse aide Pascal !