Comment autoriser l'accès au réseau local tout en étant connecté à un VPN Cisco ?

Le problème avec Anyconnect est qu'il modifie d'abord la table de routage, puis la surveille et la répare si vous la modifiez manuellement. J'ai trouvé une solution de contournement pour cela. Fonctionne avec les versions 3.1.00495, 3.1.05152, 3.1.05170, et probablement toute autre version de la famille 3.1. Peut fonctionner avec d'autres versions, au moins une idée similaire devrait fonctionner en supposant que le code ne soit pas réécrit. Heureusement pour nous, Cisco a placé l'appel du baby-sitter "bébé est réveillé" dans une bibliothèque partagée. L'idée est donc d'empêcher l'action de vpnagentd via LD_PRELOAD.

1. Tout d'abord, nous créons un fichier hack.c :

   #include <sys/socket.h>
   #include <linux/netlink.h>
   
   int _ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEv()
   {
     int fd=50;          // max fd to try
     char buf[8192];
     struct sockaddr_nl sa;
     socklen_t len = sizeof(sa);
   
     while (fd) {
        if (!getsockname(fd, (struct sockaddr *)&sa, &len)) {
           if (sa.nl_family == AF_NETLINK) {
              ssize_t n = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
           }
        }
        fd--;
     }
     return 0;
   }

Note : Ce code ne fonctionne qu'avec Linux. Pour appliquer cette solution à une machine macOS, voir la version adaptée à macOS .

2. Puis compilez-le comme ceci :

   gcc -o libhack.so -shared -fPIC hack.c

3. Installer libhack.so dans le chemin de la bibliothèque de Cisco :

   sudo cp libhack.so  /opt/cisco/anyconnect/lib/

4. Faites tomber l'agent :

   /etc/init.d/vpnagentd stop

5. Assurez-vous qu'il est vraiment en panne

   ps auxw | grep vpnagentd

   Si non, kill -9 juste pour être sûr.

6. Si vous avez /etc/init.d/vpnagentd puis le corriger en ajoutant LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so où l'exécutable sous-jacent est invoqué pour que ça ressemble à ça :

   LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so /opt/cisco/anyconnect/bin/vpnagentd

   Les installations AnyConnect plus modernes évitent /etc/init.d/vpnagentd en faveur de /lib/systemd/system/vpnagentd.service dans ce cas, il vous faut quelque chose comme :

   sudo mv /opt/cisco/anyconnect/bin/vpnagentd /opt/cisco/anyconnect/bin/vpnagentd.orig &&
   { echo '#!/bin/bash' &&
     echo "LD_PRELOAD=$HOME/vpn/libhack.so exec /opt/cisco/anyconnect/bin/vpnagentd.orig"
   } | sudo tee /opt/cisco/anyconnect/bin/vpnagentd &&
   sudo chmod +x /opt/cisco/anyconnect/bin/vpnagentd

7. Maintenant, démarrez l'agent :

   /etc/init.d/vpnagentd start

8. Corrigez les iptables, car AnyConnect s'en mêle :

   iptables-save | grep -v DROP | iptables-restore

   Vous pouvez faire quelque chose de plus avancé ici pour autoriser l'accès uniquement à certains hôtes du réseau local.

9. Maintenant, arrangez les routes comme vous le souhaitez, par exemple :

   route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0

10. Vérifiez s'ils sont vraiment là :

    route -n

Une version précédente, plus simple, de ce hack donnait une fonction qui ne faisait que "return 0 ;" - ce poster notait que "Le seul effet secondaire que j'ai observé jusqu'à présent est que vpnagentd utilise 100% du CPU comme indiqué par top, mais le CPU global n'est que de 3% pour l'utilisateur et 20% pour le système, et le système est parfaitement réactif. Je l'ai stratifié, il semble faire deux sélections dans une boucle quand il est inactif et revient rapidement des deux, mais il ne lit ni n'écrit jamais - je suppose que l'appel que j'ai coupé avec LD_PRELOAD était censé lire. Il pourrait y avoir une façon plus propre de le faire, mais c'est suffisant pour moi jusqu'à présent. Si quelqu'un a une meilleure solution, merci de la partager."

Le problème de ce hack trivial est qu'il fait qu'un seul coeur de processeur est à 100% tout le temps, ce qui réduit effectivement le nombre de threads de votre processeur matériel d'une unité - que votre connexion vpn soit active ou non. J'ai remarqué que les sélections que le code faisait étaient sur un socket netlink, qui envoie des données à vpnagentd quand la table de routage change. vpnagentd continue à remarquer qu'il y a un nouveau message sur le socket netlink et appelle le routeCallBackHandler pour le traiter, mais comme le hack trivial ne nettoie pas le nouveau message, il continue à être appelé encore et encore. le nouveau code fourni ci-dessus nettoie les données netlink de sorte que la boucle sans fin qui a causé le 100% cpu ne se produit pas.

Si quelque chose ne fonctionne pas, faites gdb -p $(pidof vpnagentd) une fois attaché :

b socket
c
bt

et voir dans quel appel vous vous trouvez. Ensuite, devinez simplement celui que vous voulez couper, ajoutez-le à hack.c et recompilez.

C'est TRÈS compliqué, mais si vous créez une VM minimale à l'aide de VMWare Player ou d'un logiciel similaire, et que vous exécutez le client VPN Cisco AnyConnect dans cette VM, il est possible de configurer le routage comme vous le souhaitez en utilisant les adaptateurs de réseau virtuel VMWare, ou simplement d'utiliser la VM pour accéder à toutes les ressources nécessaires via le VPN SSL Cisco et de "glisser/déposer" des fichiers vers/depuis votre machine réelle.

Musaraigne Le logiciel Soft VPN a fait l'affaire pour moi, aussi, comme Ian Boyd suggéré.

Il peut importer des profils de clients VPN Cisco. J'ai utilisé le Client VPN Cisco version 5.0.05.0290, et après avoir installé le Shrew VPN (version 2.1.7) et importé le profil Cisco, j'ai pu accéder au LAN local tout en étant connecté au VPN d'entreprise sans aucune configuration supplémentaire de la connexion Shrew VPN (ou du logiciel).

Mon entreprise utilise toujours ce vpn. Le client vpnc change simplement vos paramètres iptables de cette façon :

\# iptables-save
# Generated by iptables-save v1.4.10 on Sun Jun 17 14:12:20 2012
\*filter
:INPUT DROP \[0:0\]
:FORWARD ACCEPT \[0:0\]
:OUTPUT DROP \[0:0\]
-A INPUT -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACCEPT 
-A INPUT -i tun0 -j ACCEPT 
-A INPUT -i lo0 -j ACCEPT
-A INPUT -j DROP 
-A OUTPUT -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPT 
-A OUTPUT -o tun0 -j ACCEPT 
-A OUTPUT -o lo0 -j ACCEPT 
-A OUTPUT -j DROP 
COMMIT

Il filtre tout sauf le trafic du réseau privé virtuel.

Il suffit de récupérer le filtre dans un fichier avec iptables-save, d'ajouter les lignes d'accès INPUT et OUTPOUT qui correspondent à vos besoins et de réappliquer le fichier avec iptables-restore.

par exemple pour accéder à un réseau local sur 192.168.0

\# Generated by iptables-save v1.4.10 on Sun Jun 17 14:12:20 2012
\*filter
:INPUT DROP \[0:0\]
:FORWARD ACCEPT \[0:0\]
:OUTPUT DROP \[0:0\]
-A INPUT -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACCEPT 
-A INPUT -s 192.168.0.0/24 -d 192.168.0.14/32 -j ACCEPT      #local in
-A INPUT -i tun0 -j ACCEPT 
-A INPUT -i lo0 -j ACCEPT 
-A INPUT -j DROP 
-A OUTPUT -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPT 
-A OUTPUT -s 192.168.0.14/32 -d 192.168.0.0/24 -j ACCEPT     #local out
-A OUTPUT -o tun0 -j ACCEPT 
-A OUTPUT -o lo0 -j ACCEPT 
-A OUTPUT -j DROP 
COMMIT

Comme je ne peux pas ajouter de commentaires, je vais poster ici. Je fonctionne sous Windows.

La solution qui consiste à utiliser une machine virtuelle et à exécuter AnyConnect à l'intérieur de la VM, puis à utiliser la VM comme médiateur entre votre environnement de travail et le réseau de l'entreprise, ne fonctionnera pas si votre "cher" service informatique achemine l'adresse 0.0.0.0 par le VPN, de sorte que même votre réseau local (y compris entre votre PC local et la VM) est acheminé par le VPN (sic !).

J'ai essayé d'appliquer la solution postée par @Sasha Pachev mais finalement j'ai fini par Parcheando .dll de sorte qu'il retourne 0 au début de la fonction. Finalement après quelques combats avec la bibliothèque dynamique, j'ai pu modifier les tables de routage en fonction de mes besoins mais apparemment ce n'est pas suffisant !

Bien que mes règles semblent correctes pour obtenir un tunnelage divisé, j'obtiens toujours un échec général. Avez-vous rencontré un problème similaire et avez-vous réussi à le résoudre ?

• Ma passerelle vers Internet est 192.168.163.2.
• Ma passerelle vers le réseau de l'entreprise est 10.64.202.1 (donc tout le 10. . .* sous-réseau que je traite comme "société")

Voici à quoi ressemble ma table de routage maintenant (après des modifications manuelles alors que le VPN est activé)

mais le résultat du ping est le suivant

C:\Users\Mike>ping -n 1 10.64.10.11
Reply from 10.64.10.11: bytes=32 time=162ms TTL=127

C:\Users\Mike>ping -n 1 8.8.8.8
PING: transmit failed. General failure.

C:\Users\Mike>ping -n 1 192.168.163.2
General failure.

Juste pour la référence, voici à quoi ressemble la table de route lorsque le VPN est déconnecté (non modifié).

et voici à quoi ressemble la table lorsque le VPN est connecté (non modifié) dans ce cas, lorsque j'essaie de faire un ping 8.8.8.8 J'obtiens simplement un dépassement de délai (puisque le pare-feu de l'entreprise ne permet pas au trafic de sortir de l'intranet).