Comment puis-je forcer tout le trafic Internet à passer par un VPN PPTP tout en permettant l'accès au réseau local ?

Il y a deux approches à cela, celle basée sur le routage et celle basée sur le pare-feu.

Approche du routage

La table de routage typique d'une machine non connectée à un VPN ressemble à ceci :

10.23.11.0/24 dev eth0
default via 10.23.11.1

La première route est destinée aux hôtes du réseau local, et la seconde route envoie tout le reste vers la passerelle par défaut. Lorsqu'il est connecté à un VPN, la table de routage ressemble à ceci (où 1.2.3.4 est l'IP publique du serveur VPN et 10.8.0.1 est l'IP privée du serveur VPN) :

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1
default via 10.8.0.1

La première route est la même, et la troisième route est celle qui envoie tout sur le VPN. Notez cependant la deuxième règle : elle indique que pour atteindre l'IP publique du serveur VPN, les paquets doivent être envoyés via la passerelle par défaut. Ceci afin que les paquets tunnelisés créés par le client VPN atteignent réellement le serveur ; si cette route n'est pas en place, les paquets créés par le client VPN seront à nouveau envoyés sur le VPN et n'atteindront jamais le serveur.

Maintenant, si la troisième route est supprimée, les paquets destinés à n'importe quel endroit sur Internet en dehors du serveur VPN n'auront pas de route correspondante, et l'hôte ne les enverra donc jamais. Nous voulons donc que la table de routage ressemble à ceci lorsque le VPN n'est pas connecté :

10.23.11.0/24 dev eth0
1.2.3.4 via 10.23.11.1

Les hôtes du réseau local peuvent toujours être atteints, et le serveur VPN peut toujours être atteint (puisque nous devons être en mesure de démarrer le VPN), mais tout le reste ne sera pas acheminé. Obtenir cette configuration peut être un peu délicat, surtout si vous utilisez DHCP. Une configuration statique sur Debian impliquerait ce qui suit en /etc/network/interfaces cependant :

auto eth0
iface eth0 inet static
    address 10.23.11.10
    netmask 255.255.255.0
    up ip route add 1.2.3.4 via 10.23.11.1

Notez qu'il n'y a pas de gateway puisque c'est ce qui installe la route par défaut.

L'inconvénient de cette approche est que le trafic non VPN vers le serveur VPN est toujours autorisé à sortir en clair. Si vous exécutez d'autres services sur le serveur VPN et que vous devez vous assurer qu'ils sont protégés, vous devrez utiliser l'approche du pare-feu.

Editar : @JamesRyan suggère que cette approche est fragile car une route par défaut pourrait être ajoutée automatiquement ou accidentellement. Une autre approche consiste à ajouter une route trou noir, qui envoie le trafic à un endroit où il ne sera pas acheminé plus loin. Cependant, cela ne fonctionnera pas avec une route par défaut ajoutée automatiquement, car elle utilise déjà la métrique 0, la plus haute priorité. La route par défaut doit toujours être supprimée, mais quelque chose comme ce qui suit peut être ajouté.

default via 127.255.255.255

Approche pare-feu

L'idée ici est de bloquer tout le trafic sortant sur l'interface physique, à l'exception du trafic tunnelé créé par le client VPN et du trafic destiné au LAN. Le trafic à autoriser pour le VPN dépend du protocole utilisé. PPTP utilise le port TCP 1723 comme canal de contrôle, et GRE comme le tunnel réel. OpenVPN utilise le port UDP 1194. Les règles du pare-feu ressembleraient à ceci :

iptables --append OUTPUT --out-interface eth0 --destination 10.23.11.0/24 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol tcp --dport 1723 --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --destination 1.2.3.4 --protocol gre --jump ACCEPT
iptables --append OUTPUT --out-interface eth0 --jump REJECT

La première règle accepte le trafic pour le réseau local. Les deuxième et troisième règles acceptent le trafic VPN vers le serveur VPN. La quatrième règle rejette tout autre trafic sortant de l'interface physique.

La seule autre chose que vous devrez peut-être accepter est le DNS si vous utilisez un serveur DNS qui n'est pas sur le LAN, car le client VPN doit probablement faire une recherche DNS afin de trouver le serveur VPN. La règle suivante insérée avant le REJECT autoriserait le trafic DNS vers le service DNS public de Google.

iptables --append OUTPUT --out-interface eth0 --destination 8.8.8.8 --protocol udp --dport 53 --jump ACCEPT

Ajouter une autre route par défaut avec une métrique plus élevée pointant vers une interface nulle. Lorsque le VPN n'est pas disponible, la deuxième route s'activera et bloquera le trafic.

Il ne s'agit pas d'une queston iptables - vous n'avez pas besoin d'iptables pour cela.

Il suffit de définir la route par défaut pour passer par le VPN, et c'est tout. Vous pouvez également ajouter une autre route par défaut avec une métrique plus faible à utiliser, lorsque le VPN est hors service.

Votre réseau local est directement connecté, il a donc la priorité sur la passerelle par défaut.