Re: connexion vpn et iptables

François Patte <francois.patte@mi.parisdescartes.fr> wrote:

J'ai bien essayé d'autoriser le port 1194 (udp) dans les 2 sens et si je
ne mets que cette règle dans iptables, ça marche encore, mais l'ensemble
de règles en service par défaut bloque la connexion et je ne sais pas
pourquoi.

Je pense que la plupart des interventions du fil font sens: il faut
d'abord déterminer quel protocole de VPN et/ou quel fournisseur de VPN
sera imposé par votre institution, et si elle vous fournit des scripts
automatisés ou non.

Toutefois, pour répondre un peu plus concrètement à votre questions
intéressantes, il y a plusieurs aspects:

1) tout d'abord, le protocole de VPN doit pouvoir fonctionner par
   défaut, sans modifier le firewall:

   Etant donné que le client que vous lancez va intier un flux UDP
   vers l'extérieur (comme vous le dites, le port 1194/UDP est
   courant avec OpenVPN), il est très probable que même si le
   script de firewall de Linux qui est préconfiguré sur votre
   machine (par qui?  la distribution?) est très strict, il
   laissera le trafic passer, en particulier si vous ajoutez
   dans la config une sorte de `keep-alive' pour maintenir
   le flux régulièrement, par exemple avec OpenVPN:

      ping 10

   Sinon, vous aurez des sessions qui coincent après un
   `certain' temps (sans trafic).

   Un autre problème qui peut arriver est si le client est sur une
   liaison Internet dont l'adresse publique peut changer, dans ce cas,
   le serveur (qui lui est supposé avoir une adresse fixe et un firewall
   autorisant les flux entrants) devrait avoir l'option float.

2) ensuite, les datagrammes doivent pouvoir circuler de l'interface
   de VPN (tunnel) vers vos autres interfaces réseaux sans encombre:

   Là, par contre, la politique par défaut de votre préconfiguration
   de firewall pourrait être stricte.

   Dans ce cas, il faut réfléchir à ce qui est nécessaire (p.ex,
   utiliser le VPN uniquement pour sortir, mais ne pas autoriser
   de création de nouveaux flux UDP ou de connexions TCP par
   l'extérieur).

   Dans ce cas, vous pourriez faire quelque chose d'assez
   universel, mais pas forcément très sécurisé, comme:

      # autoriser la création de nouveaux flux ou connexions
      # depuis la machine locale, sortant par le VPN
      iptables -A OUTPUT \
               -o tun0 \
               -m state --state NEW,ESTABLISHED,RELATED \
               -j ACCEPT

      # n'accepter que les réponses directes, voire
      # liées (!)
      iptables -A INPUT \
               -i tun0 \
               -m state --state ESTABLISHED,RELATED \
               -j ACCEPT

      # on suppose une policy DROP sinon, et aussi qu'il
      # n'y a pas de règle DROP à la fin des tables
      # (sinon utiliser -I)

   Pour rendre cela plus générique par rapport aux noms des
   interfaces, notamment du VPN, cela peut se faire dans les
   scripts up/down d'OpenVPN.

3) NAT ou pas NAT:

   Si ce n'est que la machine locale qui produit des flux vers
   le VPN, alors l'adresse IP du tunnel de votre côté sera
   utilisée, on supposera alors que c'est le serveur de VPN
   qui l'a configurée et qu'elle est soit publique, soit que
   le serveur fait le NAT approprié.

   Sinon, le point 2 est à revoir (tables FORWARD) et du NAT
   peut être nécessaire.

4) il y a encore la question du routage:

   Voulez-vous que seul un sous-réseau routé spécifiquement passe
   par le VPN, ou tout le trafic?  Dans ce dernier cas, il y a le
   problème de la poule et de l'oeuf: changer la route par défaut
   vers l'interface du VPN nécessitera une règle plus précise
   pour pouvoir quand même atteindre le serveur de VPN par
   l'interface originale.

En bref, si je pense que c'est toujours intéressant d'expérimenter,
il faut toutefois avouer que c'est assez compliqué de se lancer
là-dedans, a fortiori si tout à coup l'institution choisit un autre
outil.