Comment puis-je conserver un accès LAN local lorsque je suis connecté à un réseau privé virtuel Cisco?
Lors de la connexion via Cisco VPN, le serveur doit avoir la possibilité de demander au client d'empêcher l'accès au réseau local.
En supposant que cette option côté serveur ne puisse pas être désactivée, comment autoriser l'accès au réseau local tout en étant connecté à un client VPN Cisco?
J'avais l'habitude de penser que c'était simplement une question de routes ajoutées qui capturent le trafic LAN avec une métrique plus élevée, par exemple:
Network
Destination Netmask Gateway Interface Metric
10.0.0.0 255.255.0.0 10.0.0.3 10.0.0.3 20 <--Local LAN
10.0.0.0 255.255.0.0 192.168.199.1 192.168.199.12 1 <--VPN Link
Et essayer de supprimer la route 10.0.x.x -> 192.168.199.12
n’a aucun effet:
>route delete 10.0.0.0
>route delete 10.0.0.0 mask 255.255.0.0
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1 if 192.168.199.12
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1 if 0x3
Et même s'il peut s'agir simplement d'un problème de routage, les tentatives d'ajout ou de suppression de routes échouent.
À quel niveau le pilote client Cisco VPN fait-il quoi dans la pile réseau qui précède annule la capacité d'un administrateur local d'administrer son ordinateur?
Le client Cisco VPN ne peut pas utiliser la magie. C'est toujours un logiciel en cours d'exécution sur mon ordinateur. Quel mécanisme utilise-t-il pour interférer avec le réseau de ma machine? Que se passe-t-il lorsqu'un paquet IP/ICMP arrive sur le réseau? Où dans la pile réseau le paquet est-il mangé?
Edit: Ce que je n’ai pas encore essayé:
>route delete 10.0.*
Mise à jour: Étant donné que Cisco a abandonné son ancien client, en faveur de AnyConnect (VPN basé sur HTTP SSL), cette question, non résolue, peut être laissée comme une relique de l’histoire.
À l'avenir, nous pouvons essayer de résoudre le même problème avec leur nouveau client .
Le problème avec Anyconnect est qu’il modifie d’abord la table de routage, puis le garde et le corrige si vous le 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 tout autre élément 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 mis l'appel de la baby-sitter "bébé est réveillé" dans une bibliothèque partagée. L'idée est donc d'empêcher toute action de vpnagentd via LD_PRELOAD.
Nous créons d'abord 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;
}
Puis compilez-le comme ceci:
gcc -o libhack.so -shared -fPIC hack.c
Installez libhack.so
dans le chemin de la bibliothèque Cisco:
Sudo cp libhack.so /opt/Cisco/anyconnect/lib/
Faites descendre l'agent:
/etc/init.d/vpnagentd stop
Assurez-vous qu'il est vraiment en panne
ps auxw | grep vpnagentd
Sinon, kill -9
juste pour être sûr.
Ensuite, corrigez /etc/init.d/vpnagentd en ajoutant LD_PRELOAD=/opt/Cisco/anyconnect/lib/libhack.so
où le vpnagentd est appelé, pour que cela ressemble à ceci:
LD_PRELOAD=/opt/Cisco/anyconnect/lib/libhack.so /opt/Cisco/anyconnect/bin/vpnagentd
Maintenant démarrez l'agent:
/etc/init.d/vpnagentd start
Corrigez les iptables, parce qu'AnyConnect les a dérangés:
iptables-save | grep -v DROP | iptables-restore
Vous voudrez peut-être faire quelque chose de plus avancé ici pour permettre l'accès uniquement à certains hôtes de réseau local.
Maintenant, corrigez les itinéraires à votre guise, par exemple:
route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
Vérifiez pour voir s'ils sont vraiment là:
route -n
Une version antérieure plus simple de ce hack donnait une fonction qui ne faisait que "renvoyer 0;" - cette affiche a indiqué que "le seul effet secondaire que j’ai observé jusqu’à présent est que vpnagentd utilise 100% des processeurs comme indiqué par top, mais le processeur global n’est que de 3% utilisateur et 20% du système, et le système est parfaitement réactif Je l'ai tracé, il semble faire deux sélections dans une boucle lorsqu'il revient inactif des deux, mais il ne lit ni n'écrit jamais - je suppose que l'appel que j'ai coupé avec LD_PRELOAD était censé être lu. le faire, mais c’est assez bon pour moi jusqu’à présent. Si quelqu'un a une meilleure solution, partagez-le, s'il vous plaît. "
Le problème avec le piratage trivial est qu’il a causé à 100% tout le temps un seul cœur de cpu, ce qui a pour effet de réduire de un le nombre de threads de cpu de votre matériel, que votre connexion vpn soit active ou non. J'ai remarqué que les sélections effectuées par le code étaient sur un socket Netlink, qui envoie des données vpnagentd lorsque la table de routage change. vpnagentd n'arrête pas de noter qu'il y a un nouveau message sur le socket netlink et appelle le routeCallBackHandler pour le gérer, mais comme le piratage trivial n'efface pas le nouveau message, il continue à être appelé, encore et encore. le nouveau code fourni ci-dessus efface les données netlink afin que la boucle sans fin qui a causé le 100% du processeur ne se produise pas.
Si quelque chose ne fonctionne pas, faites gdb -p $(pidof vpnagentd)
, une fois attaché:
b socket
c
bt
et voyez dans quel appel vous vous trouvez. Puis, devinez lequel vous voulez supprimer, ajoutez-le à hack.c et recompilez.
Cela est TRÈS compliqué, mais si vous créez un VM minimal à l'aide de VMWare Player ou similaire, et exécutez le client VPN Cisco AnyConnect dans ce sens, il vous sera peut-être possible de configurer le routage à l'aide du réseau virtuel VMWare. adaptateurs, ou utilisez simplement le VM pour accéder à toutes les ressources requises via le VPN SSL Cisco et aux fichiers "glisser-déposer" de/vers votre ordinateur.
Shrew Soft VPN logiciel a fait le tour pour moi, aussi, comme Ian Boyd suggéré.
Il peut importer des profils de client VPN Cisco. J'ai utilisé le client VPN Cisco version 5.0.05.0290 et, après avoir installé le VPN Shrew (version 2.1.7) et importé le profil Cisco, j'ai pu accéder à un réseau local tout en étant connecté au VPN de l'entreprise sans configuration supplémentaire de la connexion VPN Shrew (ou Logiciel).
Merci à Sasha Pachev pour le joli bidouillage ci-dessus.
vpnagentd
perturbe également le résolveur en écrasant les modifications apportées à /etc/resolv.conf
. Je l'ai résolu en remportant finalement la course contre elle:
#!/bin/bash
dnsfix() {
[ -f /etc/resolv.conf.vpnbackup ] || echo "Not connected?" >&2 || return 0 # do nothing in case of failure
while ! diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup #>/dev/null
do
cat /etc/resolv.conf.vpnbackup >/etc/resolv.conf
done
chattr +i /etc/resolv.conf
diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null
}
while ! dnsfix
do
echo "Retrying..."
chattr -i /etc/resolv.conf
done
N'oubliez pas de chattr -i /etc/resolv.conf
lorsque vous vous déconnectez.
J'essaie de le résoudre en interceptant le rappel, comme pour la méthode de routage ci-dessus, mais je ne trouve pas encore le rappel ou la méthode correspondante.
Update1/2: Une strace
a révélé que vpnagentd
utilise l'API inotify
pour surveiller les modifications du fichier de résolution. A partir de là, c'était en descente. Voici le hack supplémentaire:
int _ZN18CFileSystemWatcher11AddNewWatchESsj(void *string, unsigned int integer)
{
return 0;
}
C'est un peu exagéré, d'accord, car cela désactive all la recherche de fichiers pour l'agent. Mais semble fonctionner correctement.
Le script vpn client wrapper ci-dessous intègre toutes les fonctionnalités (mis à jour pour inclure ce hack supplémentaire). chattr
n'est plus utilisé/nécessaire.
Mise à jour 3: paramètres d'utilisateur et de mot de passe fixes dans le script. Il utilise maintenant un fichier vpn.conf
avec le format décrit ci-dessous (et les autorisations uniquement root).
#!/bin/bash
# Change this as needed
CONF="/etc/vpnc/vpn.conf"
# vpn.conf format
#gateway <IP>
#username <username>
#password <password>
#delete_routes <"route spec"...> eg. "default gw 0.0.0.0 dev cscotun0"
#add_routes <"route spec"...> eg. "-net 192.168.10.0 netmask 255.255.255.0 dev cscotun0" "-Host 10.10.10.1 dev cscotun0"
ANYCONNECT="/opt/Cisco/anyconnect"
usage() {
echo "Usage: $0 {connect|disconnect|state|stats|hack}"
exit 1
}
CMD="$1"
[ -z "$CMD" ] && usage
ID=`id -u`
VPNC="$ANYCONNECT/bin/vpn"
dnsfix() {
[ -f /etc/resolv.conf.vpnbackup ] || echo "Not connected?" >&2 || return 0 # do nothing in case of failure
while ! diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null
do
cat /etc/resolv.conf.vpnbackup >/etc/resolv.conf
done
# chattr +i /etc/resolv.conf
diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null
}
case "$CMD" in
"connect")
[ $ID -ne 0 ] && echo "Needs root." && exit 1
Host=`grep ^gateway $CONF | awk '{print $2}'`
USER=`grep ^user $CONF | awk '{print $2}'`
PASS=`grep ^password $CONF | awk '{print $2}'`
OLDIFS=$IFS
IFS='"'
DEL_ROUTES=(`sed -n '/^delete_routes/{s/delete_routes[ \t\"]*//;s/\"[ \t]*\"/\"/g;p}' $CONF`)
ADD_ROUTES=(`sed -n '/^add_routes/{s/add_routes[ \t\"]*//;s/\"[ \t]*\"/\"/g;p}' $CONF`)
IFS=$OLDIFS
/usr/bin/expect <<EOF
set vpn_client "$VPNC";
set ip "$Host";
set user "$USER";
set pass "$PASS";
set timeout 5
spawn \$vpn_client connect \$ip
match_max 100000
expect {
timeout {
puts "timeout error\n"
spawn killall \$vpn_client
exit 1
}
">> The VPN client is not connected." { exit 0};
">> state: Disconnecting" { exit 0};
"Connect Anyway?"
}
sleep .1
send -- "y\r"
expect {
timeout {
puts "timeout error\n"
spawn killall \$vpn_client
exit 1
}
"Username:"
}
sleep .1
send -- "\$user\r"
expect {
timeout {
puts "timeout error\n"
spawn killall \$vpn_client
exit 1
}
"Password: "
}
send -- "\$pass\r";
expect eof
EOF
sleep 2
# iptables
iptables-save | grep -v DROP | iptables-restore
# routes
for ROUTE in "${DEL_ROUTES[@]}"
do
# echo route del $ROUTE
route del $ROUTE
done
for ROUTE in "${ADD_ROUTES[@]}"
do
# echo route add $ROUTE
route add $ROUTE
done
# dns
while ! dnsfix
do
echo "Try again..."
# chattr -i /etc/resolv.conf
done
echo "done."
;;
"disconnect")
# [ $ID -ne 0 ] && echo "Needs root." && exit 1
# dns
# chattr -i /etc/resolv.conf
$VPNC disconnect
;;
"state"|"stats")
$VPNC $CMD
;;
"hack")
[ $ID -ne 0 ] && echo "Needs root." && exit 1
/etc/init.d/vpnagentd stop
sleep 1
killall -9 vpnagentd 2>/dev/null
cat - >/tmp/hack.c <<EOF
#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;
}
int _ZN18CFileSystemWatcher11AddNewWatchESsj(void *string, unsigned int integer)
{
return 0;
}
EOF
gcc -o /tmp/libhack.so -shared -fPIC /tmp/hack.c
mv /tmp/libhack.so $ANYCONNECT
sed -i "s+^\([ \t]*\)$ANYCONNECT/bin/vpnagentd+\1LD_PRELOAD=$ANYCONNECT/lib/libhack.so $ANYCONNECT/bin/vpnagentd+" /etc/init.d/vpnagentd
rm -f /tmp/hack.c
/etc/init.d/vpnagentd start
echo "done."
;;
*)
usage
;;
esac
Mon entreprise utilise toujours ce vpn. Le client vpnc change simplement les paramètres iptables de cette façon:
# iptables-save # Généré par iptables-save v1.4.10 le dimanche 17 juin 14:12:20 2012 * filtre : INPUT DROP [0 : 0] : FORWARD ACCEPT [0: 0] : BAISSE DE SORTIE [0: 0] - A INPUT -s 123.244.255.254/32 -d 192.168.0.14/ 32 -j ACCEPTER - A INPUT -i tun0 -j ACCEPTER - A INPUT -i lo0 -j ACCEPTER - A INPUT -j DROP - A OUTPUT -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPTER - UNE SORTIE -o tun0 -j ACCEPT - Une SORTIE -o lo0 -j ACCEPTER -A SORTIE -j DROP COMMIT
Il filtre tout sauf pour le trafic VPN.
Obtenez simplement le filtre dans un fichier avec iptables-save, ajoutez les lignes d’accès INPUT et OUTPOUT qui correspondent à vos besoins et réappliquez le fichier avec iptables-restore.
par exemple pour accéder à un réseau local sur 192.168.0
# Généré par iptables-save v1.4.10 le dimanche 17 juin à 14:12:20 2012 * Filtre : INPUT DROP [0: 0] : FORWARD ACCEPT [0: 0] : BAISSE DE SORTIE [0: 0] - UNE ENTRÉE -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 dans - A INPUT -i tun0 -j ACCEPTER - A INPUT -i lo0 -j ACCEPTER - Une entrée - j DROP - Une sortie - 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPT - Une sortie - 192.168.0.14/32 -d 192.168.0.0/24 -j ACCEPTER la sortie locale - UNE SORTIE -o tun0 -j ACCEPTER - Une SORTIE -o lo0 -j ACCEPTER - A OUTPUT -j DROP COMMIT
Des nouvelles à ce sujet?
À quel niveau le pilote client Cisco VPN fait-il quoi dans la pile réseau qui précède annule la capacité d'un administrateur local d'administrer son ordinateur?
Je suis tout à fait d’accord et je me demandais la même chose.
Quoi qu’il en soit, c’est une application qui nécessite l’installation de privilèges d’administrateur et pendant son exécution, elle peut très bien filtrer ce que vous faites ...
Mes tentatives sur Windows échouent aussi:
route change 0.0.0.0 mask 0.0.0.0 192.168.1.1 metric 1
OK!
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.230 21 <-- LAN
0.0.0.0 0.0.0.0 192.168.120.1 192.168.120.3 2 <-- VPN
Haha. Aucune métrique en dessous de 20 ici semble-t-il.
Je ne sais pas si j'ai bien compris, mais je clarifie d'abord ma compréhension:
Vous avez un réseau local (par exemple, 10.0.0.0/16 et un serveur VPN Cisco distant (par exemple, 64.0.0.0/16). Vous souhaitez vous connecter au serveur VPN via le client Cisco VPN et vous avez besoin avoir accès au réseau local. Dans ce cas, vous souhaitez séparer l’ensemble de la connexion 10.0.xx/16 de la connexion VPN). L'itinéraire suivant doit être ajouté à un client Mac:
/sbin/route add -net 10.0 -interface en1
où en1 est l'interface par laquelle vous êtes connecté à votre réseau local. Je sais que vous pouvez ajouter la même chose sous Windows et Linux.
Puisque je ne peux pas ajouter de commentaires, je posterai ici. Je suis sous Windows.
La solution utilisant Virtual Machine et exécutant AnyConnect dans la VM, puis utilisant VM comme intermédiaire entre l’environnement de travail et le réseau de la société ne fonctionnera pas si votre service informatique "adoré" achemine 0.0 .0.0 via VPN, donc même votre réseau local (y compris celui-ci entre votre PC local et votre VM) est routé via le VPN (sic!).
J'ai essayé d'appliquer la solution publiée par @Sasha Pachev, mais j'ai fini par corriger le fichier .dll pour qu'il renvoie 0 au début de la fonction. Finalement, après quelques batailles avec la bibliothèque dynamique, j'ai pu modifier les tables de routage en fonction de mes besoins, mais apparemment cela ne suffit pas!
Même si mes règles semblent être correctes pour réaliser le tunneling fractionné, j'ai toujours un échec général. Avez-vous rencontré un problème similaire à celui que vous avez pu résoudre?
Voici comment se présente ma table de routage (après des modifications manuelles alors que VPN est activé)
mais le résultat de ping suit
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 comment se présente la table de routage lorsque le VPN est déconnecté (non modifié)
et voici à quoi la table ressemble lorsque le VPN est connecté (inchangé) dans ce cas, lorsque j'essaie d'envoyer une requête ping à 8.8.8.8
, le délai expire tout simplement (le pare-feu de la société ne permettant pas au trafic de sortir de l'intranet)
Pour ceux qui cherchent à garder le contrôle de leur table de routage lorsqu'ils utilisent un VPN SSL Cisco AnyConnect, consultez OpenConnect . Il prend en charge le VPN SSL de Cisco AnyConnect et ne tente pas de perturber ou de "sécuriser" les entrées de la table de routage. @Vadzim y fait allusion dans un commentaire ci-dessus .
Après avoir tout essayé, à l'exception de l'application d'un correctif au client AnyConnect Secure Mobility, j'ai réussi à le remplacer sous Windows avec OpenConnect GUI . Cela m'a permis de maintenir la connectivité avec les ressources locales (et de mettre à jour la table de routage).
J'utilise OpenConnect sur Windows, mais il prend également en charge Linux, BSD et macOS (entre autres)/ selon la page du projet .
Essayez de supprimer ces entrées avec la passerelle 10.64.202.13
. Vérifiez si ping 8.8.8.8
fonctionne puis rajoutez-les un par un et identifiez celle qui est à l'origine du problème.
Comment avez-vous patché la DLL? Je ne peux même pas modifier la table de routage car elle ajoute constamment le 0.0.0.0
avec la passerelle VPN.