Bonjour à tous,
Voila j’utilise un VPN pour surfer et j’aimerais savoir comment on peut interdire l’accès au net quand mon VPN est Down.
Je sais que l’on peut le faire grâce à iptables mais je suis un peu perdu.
Si quelqu’un c’est déjà intéressé à la question et bien j’aimerais bien un petit coup de main.
Merci d’avance
@+
Je suis en train de configurer IPTABLES - Je ne suis pas un expers mais peut être que si tu expliquais mieux ton architecture je pourrais t’aider.
de toute facon, avec IPTABLEs tu pourrais interdire le port 80 et 443 depuis le LAN - authoriser les port 1723 et proto 47 (pour monter le tunnel) vers les destination du serveur VPN ensuite le FW ne filtrera plus rien car ce sera crypté.
Sans cryptage pas d’accès a Internet.
[quote=“didebian”]Je suis en train de configurer IPTABLES - Je ne suis pas un expers mais peut être que si tu expliquais mieux ton architecture je pourrais t’aider.
de toute facon, avec IPTABLEs tu pourrais interdire le port 80 et 443 depuis le LAN - authoriser les port 1723 et proto 47 (pour monter le tunnel) vers les destination du serveur VPN ensuite le FW ne filtrera plus rien car ce sera crypté.
Sans cryptage pas d’accès a Internet.
[/quote]
Merci d’avoir répondu.
Avec un ifconfig j’ai ça ( deux liaisons ethernet, une boucle locale et ma liaison VPN )
eth0 Link encap:Ethernet HWaddr ac:22:0b:cc:40:75
inet adr:192.168.0.44 Bcast:192.168.0.255 Masque:255.255.255.0
adr inet6: fe80::ae22:bff:fecc:4075/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:5653 erreurs:0 :0 overruns:0 frame:0
TX packets:3758 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:5997975 (5.9 MB) Octets transmis:711589 (711.5 KB)
eth1 Link encap:Ethernet HWaddr ac:22:0b:cc:3e:71
UP BROADCAST MULTICAST MTU:1500 Metric:1
Packets reçus:0 erreurs:0 :0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:1000
Octets reçus:0 (0.0 B) Octets transmis:0 (0.0 B)
Interruption:20 Mémoire:dff00000-dff20000
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:65536 Metric:1
Packets reçus:339 erreurs:0 :0 overruns:0 frame:0
TX packets:339 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
Octets reçus:31622 (31.6 KB) Octets transmis:31622 (31.6 KB)
tap0 Link encap:Ethernet HWaddr f6:ed:36:7e:64:99
inet adr:79.141.169.132 Bcast:79.141.169.159 Masque:255.255.255.224
adr inet6: fe80::f4ed:36ff:fe7e:6499/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Packets reçus:5451 erreurs:0 :0 overruns:0 frame:0
TX packets:3535 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:100
Octets reçus:5533736 (5.5 MB) Octets transmis:413761 (413.7 KB)C’est un PC maison avec linux derrière une freebox.
Ce que je voudrais c’est que quand mon VPN est Down ( ce qui peut arriver ) j’aimerais que mon internet soit bloqué pour éviter de me retrouver avec une IP freebox sur le net même furtivement.
Ma table de routage :
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 79.141.169.129 128.0.0.0 UG 0 0 0 tap0
default 192.168.0.254 0.0.0.0 UG 0 0 0 eth0
79.141.169.128 * 255.255.255.224 U 0 0 0 tap0
79.141.173.17 192.168.0.254 255.255.255.255 UGH 0 0 0 eth0
128.0.0.0 79.141.169.129 128.0.0.0 UG 0 0 0 tap0
192.168.0.0 * 255.255.255.0 U 1 0 0 eth0J’avais déjà réglé iptables avant sans VPN et cela marché nickel mais là j’avoue que je suis un peu perdu
Avant tout, comme toujours il faut établir un cahier des charges précis de ce qui doit être accepté ou bloqué. “Interdire l’accès au net”, ce n’est pas assez précis.
Par exemple :
A partir de là, il est assez facile d’écrire les règles iptables pour chaque action.
C’est possible d’avoir deux passerelles par défaut ?
Oui dans la mesure où ce n’est pas interdit, mais opérationnellement ça ne fonctionne pas forcément comme on pense. Le concept de “par défaut” suppose qu’on a épuisé tous les autres choix, or s’il y a deux passerelles ou routes par défaut il y a forcément encore un choix, c’est donc une situation quelque peu paradoxale. En pratique, le noyau utilise une des deux et ignore l’autre. Il ne fait pas de redondance : si la passerelle qu’il a choisie est injoignable, il ne va pas essayer d’utiliser l’autre.
Mais dans le cas présent il n’y a pas deux routes par défaut. Si tu regardes bien, l’un des deux routes a un masque à 128.0.0.0, ce n’est donc pas une route par défaut mais plutôt une “demi-route par défaut”, couvrant la moitié inférieure de l’espace d’adressage. Une autre route avec le même masque couvre la moitié supérieure. C’est une astuce utilisée par certains clients VPN pour avoir priorité sur la route par défaut : chacune de ces deux routes a priorité sur la route par défaut, et les deux réunies couvrent l’ensemble de l’espace d’adressage comme le ferait une route par défaut.
[quote=“PascalHambourg”]Avant tout, comme toujours il faut établir un cahier des charges précis de ce qui doit être accepté ou bloqué. “Interdire l’accès au net”, ce n’est pas assez précis.
Par exemple :
A partir de là, il est assez facile d’écrire les règles iptables pour chaque action.[/quote]
Merci de ta réponse et comme je ne suis pas un expert c’est vrai que mes questions peuvent ne pas être clair pour un habitué.
Donc ce que je voudrais c’est bloqué tout le traffic vers internet ( http, https , pop, etc ) quand mon VPN est down.
Je suppose que je doit accepter les requêtes DNS du FAI et je suppose que l’on peut accepter le traffic sur le LAN ( 192.168.0.0/24).
Comme je ne suis pas un expert je demande conseil pour éclairer ma petite lanterne.
@+
Ben justement je pensais qu’on pouvais peut être en supprimer une et que c’est openvpn ( par l’intermédiaire de mon VPN ) qu’il l’a créer je suppose.
Ça, tu l’avais déjà dit. (Sauf le trafic du VPN lui-même évidemment, qu’il faut caractériser pour ne pas empêcher l’établissement du VPN.)
[quote=“Arizona”]Donc ce que je voudrais c’est bloqué tout le traffic vers internet ( http, https , pop, etc ) quand mon VPN est down.
Je suppose que je doit accepter les requêtes DNS du FAI et je suppose que l’on peut accepter le traffic sur le LAN ( 192.168.0.0/24).[/quote]
Il ne s’agit pas de supposer mais de décider.
Supprimer la route par défaut via la freebox est une solution alternative au filtrage envisageable, à condition de la remplacer par une route vers le serveur VPN pour que celui-ci reste joignable et de ne pas avoir besoin de faire des requêtes DNS vers des serveurs DNS extérieurs (donc DNS sur la freebox ou serveur VPN par adresse IP). Cependant si cette route par défaut provient de la configuration automatique par le serveur DHCP de la freebox, elle reviendra. On peut bidouiller la configuration du client DHCP pour ne pas recevoir de route par défaut, mais à ce stade il sera certainement plus simple de faire une configuration IP statique pour eth0.
Ça, tu l’avais déjà dit. (Sauf le trafic du VPN lui-même évidemment, qu’il faut caractériser pour ne pas empêcher l’établissement du VPN.)
[quote=“Arizona”]Donc ce que je voudrais c’est bloqué tout le traffic vers internet ( http, https , pop, etc ) quand mon VPN est down.
Je suppose que je doit accepter les requêtes DNS du FAI et je suppose que l’on peut accepter le traffic sur le LAN ( 192.168.0.0/24).[/quote]
Il ne s’agit pas de supposer mais de décider.
Supprimer la route par défaut via la freebox est une solution alternative au filtrage envisageable, à condition de la remplacer par une route vers le serveur VPN pour que celui-ci reste joignable et de ne pas avoir besoin de faire des requêtes DNS vers des serveurs DNS extérieurs (donc DNS sur la freebox ou serveur VPN par adresse IP). Cependant si cette route par défaut provient de la configuration automatique par le serveur DHCP de la freebox, elle reviendra. On peut bidouiller la configuration du client DHCP pour ne pas recevoir de route par défaut, mais à ce stade il sera certainement plus simple de faire une configuration IP statique pour eth0.[/quote]
Je préfère laisser tomber car si c’est pour me faire reprendre à chaque phrase ça ne m’intéresse pas.
Je veux juste comprendre mais toi tu m’insultes en me méprisant de haut avec tes connaissances.
Tu as juste oublié qu’un jour toi aussi tu ne savais pas et tu étais bien content de trouver quelqu’un pour t’expliquer les choses.
Merci aux autres qui m’ont répondus.
@+
C’est le bon état d’esprit, plutôt que de demander une recette toute faite qu’on applique sans comprendre. Mais tu sembles abandonner un peu vite face à la difficulté.
Pur procès d’intention.
En ce qui concerne iptables, j’ai appris par moi-même en lisant la documentation et en expérimentant.
[quote=“PascalHambourg”]Mais tu sembles abandonner un peu vite face à la difficulté.
[/quote]
Sache que je suis quelqu’un qui aime bien comprendre les choses et le fait de m’intéresser à iptables en est un exemple.
Je viens de passer sous Linux et le domaine que je découvre est vaste.
Il y un moment ou l’on a besoin d’un peu d’explication pour progresser malgré que le net soit une mine d’informations.
Quand tu écrit : [quote=“PascalHambourg”]Il ne s’agit pas de supposer mais de décider.[/quote] le ton que tu emplois n’est pas des plus chaleureux et quand on ne connais pas bien un sujet on fait d’abord des suppositions et ensuite grâce à de l’entraide ou de la lecture on en arrive à des demandes précises et à une meilleure compréhension.
Sache qu’avant de venir demander de l’aide j’ai fait des tests mais qui hélas ne fonctionnent pas d’ou ma demande d’aide.Tant mieux si toi tu maîtrises facilement mais sache que chaque personne est différente et que pour certains domaines celles-ci aient besoin d’un peu d’aide et d’explications autre qu’une lecture pour avancer.
@+
Le ton de mes interventions en ligne n’est jamais chaleureux avec qui que ce soit. la chaleur, c’est de l’énergie et je n’ai pas envie de dépenser de l’énergie à être chaleureux. Cf. la première ligne de ma signature.
Dommage que tu n’aies pas décrit ces tests, cela aurait pu être un bon point de départ pour savoir où tu en es. Parfois un bon script vaut mieux qu’un long discours. Cf. la deuxième ligne de ma signature.
Pour le moment je n’ai pas la moindre idée de ce qui te bloque et iptables est un sujet bien trop vaste pour que je me lance dans des explications. Est-ce dans la définition détaillée du cahier des charges (étape indispensable, je le répète, et trop souvent négligée) ? Dans la traduction de celui-ci en règles iptables ?
[quote=“PascalHambourg”]
Pour le moment je n’ai pas la moindre idée de ce qui te bloque et iptables est un sujet bien trop vaste pour que je me lance dans des explications. Est-ce dans la définition détaillée du cahier des charges (étape indispensable, je le répète, et trop souvent négligée) ? Dans la traduction de celui-ci en règles iptables ?[/quote]
Comme mes tests de iptables ne fonctionnent pas, forcement mon cahier des charges doit être erroné.
J’ai peut être du mal à visualiser comment s’intègre mon VPN dans mon architecture réseau.
Moi je vois un réseau LAN ( 192.168… ) , une interface ( freebox ) qui fait la passerelle entre mon réseau LAN et internet et un VPN qui lui doit faire l’interface entre mon réseau LAN et le serveur distant de mon VPN et qui doit shunté ma freebox.
Mais peut être que je suis à côté de la plaque.
D’un point de vue général, il n’est pas incorrect de considérer la freebox comme une “interface” entre le réseau local et internet. Mais dans le contexte de ta machine et d’iptables, la freebox est un routeur (“passerelle” est un terme obsolète bien qu’encore largement utilisé), et eth0 est l’interface qui connecte ta machine au réseau local. tap0 est l’interface qui connecte ta machine au VPN, qui est une liaison réseau virtuelle avec le serveur VPN distant ; ce dernier agit comme un routeur entre le VPN et internet.
La “subtilité” avec un VPN, c’est qu’il n’est pas indépendant des autres interfaces et réseaux ; le trafic dans le VPN sur tun0 se traduit par du trafic ethernet sur eth0, mais sous une autre forme (encapsulée). Pour simplifier, un paquet émis ou reçu par tap0 va engendrer un paquet (différent) sur eth0 depuis ou vers le serveur VPN. Les règles de filtrage ne doivent pas bloquer ces deux paquets.
Pas forcément ; sa traduction en règles peut aussi être erronée. C’est la double exigence de l’utilisation d’iptables, qui fait sa difficulté :
Tu ne veux vraiment pas donner le genre de règles que tu avais testé, et en quoi elles ne fonctionnaient pas (ne bloquaient pas, ou trop) ?
Merci pour les explications ça permet d’y voir plus clair, voici ma dernière version d’iptables :
[code]
#!/bin/sh
modprobe ip_conntrack ; # Module principal du suivi de connexion
iptables -t filter -F
iptables -t filter -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
iptables -t filter -A INPUT -p all -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
iptables -t filter -A FORWARD -i lo -j ACCEPT
iptables -t filter -A FORWARD -o lo -j ACCEPT
iptables -t filter -A INPUT -i tap0 -j ACCEPT
iptables -t filter -A OUTPUT -o tap0 -j ACCEPT
iptables -t filter -A OUTPUT -d 79.141.173.17 -o eth0 -j ACCEPT
iptables -t filter -A OUTPUT -p all -m conntrack --ctstate RELATED,ESTABLISHED,UNTRACKED -j ACCEPT[/code]
Par contre je viens de remarquer lors d’un ifconfig que mon interface tap0 disparais quand j’applique mes règles iptables.
C’est pas mal, dans l’ensemble.
(Détails non gênants : le [mono]modprobe[/mono] est superflu car les modules nécessaires aux règles sont chargés autormatiquement ; [mono]-p all[/mono] est superflu ; les règles dans FORWARD pour le loopback sont sans objet car il ne peut y avoir de forward sur le loopback.)
Il n’y a pas de règles autorisant le trafic avec le réseau local ni des serveurs DNS externes, mais c’est facile à ajouter si nécessaire.
[code]# requêtes DNS en UDP
iptables -t filter -A OUTPUT -p udp --dport 53 -d <ip_dns> -j ACCEPT
iptables -t filter -A OUTPUT -p tcp --dport 53 -d <ip_dns> -j ACCEPT
iptables -t filter -A OUTPUT -d 192.168.0.0/24 -j ACCEPT
iptables -t filter -A INPUT -d 192.168.0.0/24 -j ACCEPT[/code]
Immédiatement et systématiquement ? Vérifie avec [mono]ifconfig -a[/mono] si elle n’existe plus ou a seulement été désactivée (présente mais sans flag UP).
Cela pourrait arriver si le client VPN tente d’envoyer un paquet qui est bloqué par iptables (il reçoit un code d’erreur en retour) ; cependant ton jeu de règles autorise les paquets sortants vers l’adresse du serveur VPN, à moins que le paquet soit émis dans le court intervalle entre le moment où la politique par défaut est passée à DROP et le moment où la règle autorisant les paquets à destination du serveur VPN est ajoutée.
Quand je cherche ce qui coince, j’ajoute des règles LOG en fin de chaînes pour enregistrer les paquets bloqués dans les logs du noyau affichables avec dmesg ou dans /var/log/kern.log. Tu peux ajouter ceci à la fin de tes règles :
iptables -t filter -A OUTPUT -j DROP
iptables -t filter -A INPUT -j DROP
et relancer le VPN, puis voir les logs. Il y aura certainement du tri à faire pour éliminer tout le trafic “parasite” qui n’a aucun rapport avec le VPN.
Bon maintenant j’ai mon interface tun0 quand j’utilise iptables, c’est déjà ça.
Mes nouvelles règles :
#!/bin/sh
# modprobe ip_conntrack ; # Module principal du suivi de connexion
# Vidage des règles dans les chaînes
iptables -t filter -F
# Suppression des chaînes autres que celles par défaut
iptables -t filter -X
# Idem mais pour la table nat
iptables -t nat -F
iptables -t nat -X
# Idem mais pour la table mangle
iptables -t mangle -F
iptables -t mangle -X
# Interdire toute connexion entrante et sortante
iptables -t filter -P INPUT DROP
iptables -t filter -P FORWARD DROP
iptables -t filter -P OUTPUT DROP
# Autoriser les entrées sorties loopback
iptables -t filter -A INPUT -i lo -j ACCEPT
iptables -t filter -A OUTPUT -o lo -j ACCEPT
# Autoriser les connexions sur le réseau local en entrée et en sortie
iptables -t filter -A INPUT -d 192.168.0.0/24 -j ACCEPT
iptables -t filter -A OUTPUT -d 192.168.0.0/24 -j ACCEPT
# Autoriser les requetes DNS
iptables -t filter -A OUTPUT -p udp --dport 53 -d 212.27.40.240 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -d 212.27.40.240 -j ACCEPT
# Ne pas casser les connexions etablies en entrée
iptables -t filter -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Autoriser les connexions sur l'interface VPN
iptables -t filter -A INPUT -i tun0 -j ACCEPT
iptables -t filter -A OUTPUT -i tun0 -j ACCEPT
# Autoriser les connexions vers le serveur VPN
iptables -t filter -A OUTPUT -d 79.141.173.17 -o eth0 -j ACCEPT
# Ne pas casser les connexions etablies en sortie
iptables -t filter -A OUTPUT -m conntrack --ctstate RELATED,ESTABLISHED,UNTRACKED -j ACCEPTMais toujours pas de connexion au net…
Peut être me pencher sur l’IP de mon VPN ou les DNS ???
Je vais refaire des essais sur ces deux paramètres
@+
Tiens, l’interface tap0 est devenue tun0 ? Tu as changé de mode dans openvpn ?
Dans la configuration d’openvpn, le serveur est spécifié par son adresse IP ou son nom de domaine ? Dans le second cas, la résolution DNS doit être opérationnelle avant que le VPN soit monté. Et il faut aussi vérifier si cette adresse IP peut changer, car dans ce cas la règle acceptant les paquets vers le serveur VPN ne fonctionnera plus.
Ta règle dans la chaîne INPUT pour le DNS est erronée et inutile. Erronée car les paquets reçus sont des réponses DNS, ayant l’adresse du serveur DNS et le port 53 comme source et non comme destination. Inutile car ces paquets de réponse sont déjà pris en compte par la règle de suivi de connexion de la chaîne INPUT. A noter que Free fournit deux adresses de DNS, donc il faut aussi ajouter une règle dans OUTPUT pour l’autre adresse.
A propos de DNS, vérifie si le serveur VPN “pousse” ses propres adresses de DNS lors de l’établissement du VPN. Dans le cas contraire, la résolution DNS via les DNS de Free ne fonctionnera pas : les requêtes sortent par le VPN avec l’adresse source de l’interface tun/tap qui n’est pas reconnue comme une adresse appartenant à Free, donc les serveurs DNS de Free refuseront de répondre. On peut contourner cela en ajoutant des routes statiques pour atteindre ces serveurs via la Freebox en toutes circonstance, mais cela signifie que Free (et potentiellement d’autres) peuvent savoir sur quels sites tu vas. Une alternative consiste à utiliser des DNS publics comme ceux de Google, en passant par le VPN ; ainsi Google sait sur quels sites tu vas mais ne sais pas qui tu es grâce au VPN, contrairement à Free lorsque tu interroges ses DNS via la Freebox.
Qu’entends-tu exactement par “pas de connexion au net” ?
Que donne un traceroute vers une adresse IP publique ?
Ajoute les règles LOG et tu verras tout de suite les paquets bloqués dans les logs du noyau.
PS : J’ai fait une erreur dans la règle pour accepter en entrée les paquets provenant du LAN; il faut évidemment se baser sur l’adresse source et non l’adresse destination. Donc :
Pour tun0 c’est une erreur, comme je fais beaucoup d’essai je me suis trompé ( c’est bien tap0 ).
Mais bon cela change rien au problème.
Je suis en train de regarder au niveau des DNS et de l’IP du serveur VPN.
@+