¿Cómo permitir el acceso LAN local mientras está conectado a Cisco VPN?

¿Cómo puedo mantener el acceso LAN local mientras estoy conectado a Cisco VPN?

Cuando se conecta mediante Cisco VPN, el servidor tiene la capacidad de indicar al cliente que evite el acceso a la LAN local.

Suponiendo que esta opción del lado del servidor no se puede desactivar, ¿cómo puede permitir el acceso LAN local mientras está conectado con un cliente VPN de Cisco?

Solía ​​pensar que se trataba simplemente de agregar rutas que capturaban el tráfico LAN con una métrica más alta, por ejemplo:

  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

Y tratar de eliminar la 10.0.x.x -> 192.168.199.12ruta no tiene ningún efecto:

>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

Y aunque todavía podría ser simplemente un problema de enrutamiento, los intentos de agregar o eliminar rutas fallan.

¿A qué nivel está haciendo el controlador de cliente VPN de Cisco qué en la pila de redes que anula la capacidad de un administrador local para administrar su máquina?

El cliente VPN de Cisco no puede emplear magia. Todavía es un software que se ejecuta en mi computadora. ¿Qué mecanismo está usando para interferir con la red de mi máquina? ¿Qué sucede cuando llega un paquete IP / ICMP a la red? ¿En qué parte de la pila de redes se está comiendo el paquete?

Ver también

• Sin conexión a internet con Cisco VPN
• Cisco VPN Client interrumpe la conectividad a mi servidor LDAP
• Cisco VPN detiene la navegación de Windows 7
• ¿Cómo puedo prohibir la creación de una ruta en Windows XP al conectarme a Cisco VPN?
• Redirigir el tráfico local de LAN e Internet cuando está en VPN
• Cliente VPN "Permitir acceso LAN local"
• Permitir acceso LAN local para clientes VPN en el ejemplo de configuración del concentrador VPN 3000
• El acceso LAN desapareció cuando me conecto a VPN
• Documentación de Windows XP: ruta

Editar: cosas que aún no he probado:

>route delete 10.0.*

Actualización: dado que Cisco ha abandonado su antiguo cliente, a favor de AnyConnect (VPN basada en SSL SSL), esta pregunta, sin resolver, puede dejarse como una reliquia de la historia.

En el futuro, podemos intentar resolver el mismo problema con su nuevo cliente .

El problema con Anyconnect es que primero modifica la tabla de enrutamiento, luego la cuida y la arregla si la modifica manualmente. Encontré una solución para esto. Funciona con la versión 3.1.00495, 3.1.05152, 3.1.05170, y probablemente cualquier otra cosa en la familia 3.1. Puede funcionar con otras versiones, al menos una idea similar debería funcionar asumiendo que el código no se reescribe. Afortunadamente para nosotros, Cisco colocó la llamada de la niñera "el bebé está despierto" en una biblioteca compartida. Entonces, la idea es que evitemos la acción de vpnagentd a través de LD_PRELOAD.

1. Primero creamos un archivo 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;
   }
   

Nota: Este código solo funciona con Linux. Para aplicar esta solución a una máquina macOS, consulte la versión adaptada de macOS .

2. Luego compílalo así:

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

3. Instalar libhack.soen la ruta de la biblioteca de Cisco:

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

4. Derriba al agente:

   /etc/init.d/vpnagentd stop
   

5. Asegúrate de que realmente esté abajo

   ps auxw | grep vpnagentd
   

   Si no, kill -9solo para estar seguro.

6. Luego arregle /etc/init.d/vpnagentd agregando LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so dónde se invoca el vpnagentd para que se vea así:

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

7. Ahora inicie el agente:

   /etc/init.d/vpnagentd start
   

8. Arregle iptables, porque AnyConnect se mete con ellos:

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

   Es posible que desee hacer algo más avanzado aquí para permitir el acceso solo a ciertos hosts LAN.

9. Ahora arregle las rutas como desee, por ejemplo:

   route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
   

10. Comprueba si realmente están allí:

    route -n
    

Una versión anterior y más simple de este truco daba una función que solo "devuelve 0"; - ese póster señaló que "el único efecto secundario que he observado hasta ahora es que vpnagentd está utilizando el 100% de la CPU según lo informado por la parte superior, pero en general la CPU solo tiene un 3% de usuario y un 20% de sistema, y ​​el sistema responde perfectamente Lo alineé, parece estar haciendo dos selecciones en un bucle cuando el inactivo regresa de ambos rápidamente, pero nunca lee ni escribe: supongo que se suponía que la llamada que corté con LD_PRELOAD debía leerse. Podría haber una forma más limpia para hacerlo, pero hasta ahora es lo suficientemente bueno para mí. Si alguien tiene una mejor solución, por favor comparta ".

El problema con el truco trivial es que causó que un solo núcleo de CPU fuera 100% todo el tiempo, reduciendo efectivamente el número de subprocesos de CPU del hardware en uno, ya sea que su conexión vpn estuviera activa o no. Noté que las selecciones que estaba haciendo el código estaban en un socket de enlace de red, que envía datos vpnagentd cuando cambia la tabla de enrutamiento. vpnagentd sigue notando que hay un nuevo mensaje en el socket de netlink y llama a routeCallBackHandler para tratarlo, pero como el truco trivial no borra el nuevo mensaje, simplemente sigue llamándolo una y otra vez. el nuevo código provisto anteriormente vacía los datos del enlace de red para que no ocurra el bucle sin fin que causó el 100% de la CPU.

Si algo no funciona, hazlo gdb -p $(pidof vpnagentd), una vez adjuntado:

b socket
c
bt

y vea en qué llamada está. Luego adivine cuál desea cortar, agréguelo a hack.c y vuelva a compilar.

Esto es MUY complicado, pero si crea una máquina virtual mínima con VMWare Player o similar, y ejecuta el cliente VPN Cisco AnyConnect en eso, podría ser posible configurar el enrutamiento como desee usando los adaptadores de red virtual VMWare, o simplemente usar el VM para acceder a los recursos necesarios a través de Cisco SSL VPN y "arrastrar / soltar" archivos a / desde su máquina real.

El software Shrew Soft VPN también me ayudó, como sugirió Ian Boyd .

Puede importar perfiles de cliente VPN de Cisco. Utilicé Cisco VPN Client versión 5.0.05.0290, y después de instalar Shrew VPN (versión 2.1.7) e importar el perfil de Cisco, pude acceder a la LAN local mientras estaba conectado a una VPN corporativa sin ninguna configuración adicional de conexión Shrew VPN (o software).

Gracias a Sasha Pachev por el buen truco de arriba.

vpnagentdtambién se mete con el solucionador al sobrescribir los cambios realizados en /etc/resolv.conf. Lo resolví ganando finalmente la carrera contra él:

#!/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

No te olvides de chattr -i /etc/resolv.confdesconectar.

Estoy tratando de resolverlo interceptando la devolución de llamada, como para el método de rutas anterior, pero todavía no puedo encontrar la devolución de llamada o el método correspondiente.

Actualización 1/2: se stracereveló que vpnagentdestá utilizando la inotifyAPI para monitorear los cambios en el archivo de resolución. A partir de ahí fue cuesta abajo. Aquí está el truco adicional:

int _ZN18CFileSystemWatcher11AddNewWatchESsj(void *string, unsigned int integer)
{
  return 0;
}

Eso es un poco exagerado, dado que deshabilita toda observación de archivos para el agente. Pero parece funcionar bien.

El script de envoltura de cliente vpn a continuación integra toda la funcionalidad (actualizada para incluir este truco adicional). chattrya no se usa / necesita.

Actualización 3: Se corrigió la configuración de nombre de usuario / contraseña en el script. Ahora usa un vpn.confarchivo con el formato que se describe a continuación (y permisos de solo 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

Mi compañía todavía usa esa VPN. El cliente vpnc simplemente cambia la configuración de iptables de esa manera:

# iptables-save
# Generado por iptables-save v1.4.10 el dom 17 de junio 14:12:20 2012
*filtrar
: GOTA DE ENTRADA [0: 0]
: ADELANTE ADELANTE [0: 0]
: GOTA DE SALIDA [0: 0]
-A ENTRADA -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACEPTAR 
-A ENTRADA -i tun0 -j ACEPTAR 
-A ENTRADA -i lo0 -j ACEPTAR
-A ENTRADA -j GOTA 
-A SALIDA -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACEPTAR 
-A SALIDA -o tun0 -j ACEPTAR 
-A SALIDA -o lo0 -j ACEPTAR 
-A SALIDA -j GOTA 
COMETER

Filtra todo excepto el tráfico vpn.

Simplemente coloque el filtro en un archivo con iptables-save, agregue líneas de acceso INPUT y OUTPOUT que coincidan con sus necesidades y vuelva a aplicar el archivo con iptables-restore.

por ejemplo para acceder a una red local en 192.168.0

# Generado por iptables-save v1.4.10 el dom 17 de junio 14:12:20 2012
*filtrar
: GOTA DE ENTRADA [0: 0]
: ADELANTE ADELANTE [0: 0]
: GOTA DE SALIDA [0: 0]
-A ENTRADA -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACEPTAR 
-A ENTRADA -s 192.168.0.0/24 -d 192.168.0.14/32 -j ACEPTAR #local en
-A ENTRADA -i tun0 -j ACEPTAR 
-A ENTRADA -i lo0 -j ACEPTAR 
-A ENTRADA -j GOTA 
-A SALIDA -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACEPTAR 
-A SALIDA -s 192.168.0.14/32 -d 192.168.0.0/24 -j ACEPTAR # salida local
-A SALIDA -o tun0 -j ACEPTAR 
-A SALIDA -o lo0 -j ACEPTAR 
-A SALIDA -j GOTA 
COMETER

¿Alguna noticia sobre esto?

¿A qué nivel está haciendo el controlador de cliente VPN de Cisco qué en la pila de redes que anula la capacidad de un administrador local para administrar su máquina?

Estoy totalmente de acuerdo y me preguntaba sobre lo mismo.

De todos modos, es una aplicación que requiere privilegios de administrador para instalar y, mientras se ejecuta, puede muy bien filtrar lo que haces ...

Mis intentos en Windows también fallan:

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

Jaja. Ninguna métrica por debajo de 20 aquí parece.

No sé si lo he entendido bien, pero primero aclaro mi comprensión:

Tiene una LAN local (por ejemplo, digamos 10.0.0.0/16, y un servidor VPN de Cisco remoto (por ejemplo, 64.0.0.0/16). Desea conectarse al servidor VPN a través del cliente VPN de Cisco y, sin embargo, necesita tener acceso a la LAN. En este caso, desea separar todo el 10.0.xx / 16 de la conexión VPN). Se debe agregar la siguiente ruta en un cliente Mac:

/sbin/route add -net 10.0 -interface en1

donde en1 es la interfaz a través de la cual está conectado a su LAN. Sé que también puedes agregar lo mismo en Windows y Linux.

Como no puedo agregar comentarios, publicaré aquí. Estoy corriendo en Windows.

La solución que usa Virtual Machine y ejecuta AnyConnect dentro de la VM y luego usa VM como mediador entre su entorno de trabajo y la red de la compañía no funcionará si su departamento de TI "amado" enruta 0.0.0.0 a través de VPN, incluso su red local (incluyendo esto entre su PC local y VM) se enruta a través de la VPN (sic!).

Traté de aplicar la solución publicada por @Sasha Pachev pero finalmente terminé parcheando .dll para que devuelva 0 al comienzo de la función. Finalmente, después de una pelea con la biblioteca dinámica, pude modificar las tablas de enrutamiento de acuerdo con mis necesidades, ¡pero aparentemente eso no es suficiente!

A pesar de que mis reglas parecen ser correctas para lograr un túnel dividido, sigo teniendo una falla general. ¿Te encontraste con un problema similar al que pudiste resolver?

• Mi puerta de acceso a internet es 192.168.163.2
• El portal de acceso a la red de la empresa es 10.64.202.1 (por lo tanto toda 10. . . * Subred me trato como "comapny de")

Así es como se ve mi tabla de enrutamiento ahora (después de modificaciones manuales mientras VPN está activada)

sin embargo, el resultado del ping sigue

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.

Solo como referencia, a continuación se muestra cómo se ve la tabla de rutas cuando la VPN está desconectada (sin alterar)

y así es como se ve la tabla cuando la VPN está conectada (sin modificaciones) en ese caso, cuando intento hacer ping 8.8.8.8, simplemente obtengo un tiempo de espera (ya que el firewall de la compañía no permite que el tráfico salga de la intranet)

Para aquellos que buscan mantener el control de su tabla de enrutamiento cuando utilizan una VPN SSL de Cisco AnyConnect, consulte OpenConnect . Ambos son compatibles con Cisco AnyConnect SSL VPN y no intenta interrumpir o 'asegurar' las entradas de la tabla de enrutamiento. @Vadzim alude a esto en un comentario anterior .

Después de probar todo menos parchear el Cliente AnyConnect Secure Mobility, pude reemplazarlo con éxito en Windows con OpenConnect GUI . Esto me permitió mantener la conectividad a los recursos locales (y actualizar la tabla de enrutamiento).

Uso OpenConnect en Windows pero también es compatible con Linux, BSD y macOS (entre otras plataformas) de acuerdo con la página del proyecto .

Intente eliminar esas entradas con la puerta de enlace para 10.64.202.13ver si el ping 8.8.8.8funciona y luego agregarlas una por una e identificar cuál está causando el problema.

¿Cómo parcheaste la DLL? Ni siquiera puedo modificar la tabla de enrutamiento porque sigue agregando la 0.0.0.0puerta de enlace VPN nuevamente.