Como permitir o acesso LAN local enquanto está ligado à Cisco VPN?

O problema com Anyconnect é que primeiro modifica a tabela de encaminhamento, depois toma conta dela e repara-a caso a modifique manualmente. Encontrei uma solução para isto. Funciona com as versões 3.1.00495, 3.1.05152, 3.1.05170, e provavelmente qualquer outra coisa na família 3.1. Pode funcionar com outras versões, pelo menos uma ideia semelhante deve funcionar, supondo que o código não seja reescrito. Felizmente para nós, Cisco pôs a babysitter “baby is awake” numa biblioteca partilhada. Portanto, a ideia é que impeçamos a acção da vpnagentd via LD_PRELOAD.

1. Primeiro criamos um ficheiro hack.c:

Nota: Este código funciona apenas com Linux. Para aplicar esta solução a uma máquina macOS, ver a versão adaptada a macOS .

1. Depois compilá-lo desta forma:

2. Instalar libhack.so& no caminho da biblioteca Cisco:

3. Traga o agente:

4. Certificar-se de que está realmente em baixo:

5. Depois fixar /etc/init.d/vpnagentd adicionando LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so onde o vpnagentd está a ser invocado para que se pareça com isto:

6. Agora iniciar o agente:

7. Arranjar iptables, porque AnyConnect mexe com eles:

8. Agora arranje as rotas como quiser, por exemplo:

9. Verifique se eles estão realmente lá:

Uma versão anterior, mais simples deste hack deu uma função que apenas “devolveu 0;” - esse cartaz observou que “O único efeito secundário que observei até agora é que vpnagentd está a usar 100% do CPU, como relatado pelo topo, mas o CPU em geral é apenas 3% de utilizador e 20% de sistema, e o sistema é perfeitamente responsivo. Apertei-o, parece estar a fazer duas selecções em loop quando ocioso regressa rapidamente de ambos, mas nunca lê nem escreve - suponho que a chamada que cortei com LD_PRELOAD deveria ter sido lida. Pode haver uma forma mais limpa de o fazer, mas é suficientemente boa para mim até agora. Se alguém tiver uma solução melhor, por favor partilhe”.

O problema com o hack trivial é que fez com que um único núcleo cpu fosse 100% o tempo todo, reduzindo efectivamente a sua contagem de fios cpu de hardware por um - quer a sua ligação vpn estivesse activa ou não. Notei que as selecções que o código estava a fazer estavam numa tomada netlink, que envia dados vpnagentd quando a tabela de roteamento muda. vpnagentd continua a notar que há uma nova mensagem na tomada netlink e chama o routeCallBackHandler para lidar com ela, mas uma vez que o hack trivial não limpa a nova mensagem, continua a ser chamado uma e outra vez. o novo código fornecido acima descarrega os dados da netlink para que o loop interminável que causou a 100% cpu não aconteça.

Se algo não funcionar, faça gdb -p $(pidof vpnagentd), uma vez anexado:

b socket
c
bt

e veja em que chamada se encontra. Depois adivinhe qual quer cortar, adicione-a ao hack.c e recompile.

Isto é MUITO complicado, mas se criar uma VM mínima utilizando o VMWare Player ou semelhante, e executar o cliente Cisco AnyConnect VPN nesse caso, poderá ser possível configurar o encaminhamento como quiser utilizando os adaptadores de rede virtuais VMWare, ou simplesmente utilizar a VM para aceder a quaisquer recursos através do Cisco SSL VPN e ficheiros “drag/drop” de/para a sua máquina real.

(http://www.shrew.net “Free as of March 2013”) Soft VPN software fez o truque por mim, também, como Ian Boyd sugeriu.

Pode importar perfis de clientes Cisco VPN. Utilizei Cisco VPN Client versão 5.0.05.0290, e depois de instalar o Shrew VPN (versão 2.1.7) e importar o perfil Cisco, consegui aceder à LAN local enquanto ligado à VPN corporativa sem qualquer configuração adicional de ligação (ou software) Shrew VPN.

Graças a Sasha Pachev pelo simpático hack acima.

vpnagentd também mexe com o resolvedor, substituindo as alterações feitas a /etc/resolv.conf. Resolvi-o ao eventualmente ganhar a corrida contra ele:

#!/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ão se esqueça de chattr -i /etc/resolv.conf ao desconectar.

Estou a tentar resolvê-lo interceptando a chamada de retorno, como para o método de rotas acima, mas ainda não consigo encontrar a correspondente chamada de retorno ou método.

Actualização1/2: A strace revelou que vpnagentd está a usar o inotify API para monitorizar as alterações do ficheiro resolver. A partir daí, foi a descer a colina. Aqui está o hack adicional:

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

Isso é um pouco exagerado, garantido, pois desactiva todos os ficheiros a vigiar para o agente. Mas parece funcionar bem.

O script vpn client wrapper abaixo integra todas as funcionalidades (actualizado para incluir este hack adicional). chattr já não é utilizado/necessário.

Actualização 3: Definições fixas de username/password no script. Agora utiliza um ficheiro vpn.conf com o formato descrito abaixo (e permissões apenas de raiz).

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

A minha empresa ainda utiliza esse vpn. O cliente vpnc simplesmente muda as suas configurações iptables dessa forma:

# 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

Filtra tudo excepto o tráfego vpn.

Basta obter o filtro num ficheiro com iptables-save, adicionar linhas de acesso INPUT e OUTPOUT que correspondam às suas necessidades e reaplicar o ficheiro com iptables-restore.

por exemplo, para aceder a uma rede local em 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

Para aqueles que procuram manter o controlo da sua tabela de encaminhamento quando utilizam uma VPN Cisco AnyConnect SSL, ver OpenConnect . Ambos suportam a Cisco AnyConnect SSL VPN e não tentam perturbar ou ‘proteger’ as entradas da tabela de encaminhamento. @Vadzim faz alusão a isto num comentário acima .

Depois de tentar tudo menos remendar o AnyConnect Secure Mobility Client, fui capaz de o substituir com sucesso no Windows por OpenConnect GUI . Isto permitiu-me manter a conectividade com recursos locais (e actualizar a tabela de encaminhamento).

Utilizo o OpenConnect no Windows mas também suporta Linux, BSD, e macOS (entre outras plataformas) de acordo com a página do projecto .

Alguma novidade sobre isto?

A que nível está o driver do cliente Cisco VPN a fazer o quê na pilha de rede que se sobrepõe à capacidade de um administrador local para administrar a sua máquina?

& Eu concordo plenamente e estava a pensar na mesma coisa.

De qualquer modo, é uma aplicação que requer privilégios de administrador para ser instalada e enquanto é executada pode muito bem filtrar o que se faz…

As minhas tentativas no Windows também falham:

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. Não há aqui nenhuma métrica abaixo de 20, ao que parece.

Uma vez que não posso acrescentar comentários, vou postar aqui. Estou a correr no Windows.

A solução usando Máquina Virtual e executar AnyConnect dentro da VM e depois usar a VM como mediador entre o seu ambiente de trabalho e a rede da empresa não funcionará se o seu departamento de TI “amado” encaminhar 0.0.0.0 através de VPN, assim mesmo a sua rede local (incluindo esta entre o seu PC local e a VM) é encaminhada através da VPN(sic!).

Tentei aplicar a solução postada por @Sasha Pachev mas acabei por remendar .dll de modo a que devolvesse 0 no início da função. Eventualmente, após alguma luta com a biblioteca dinâmica, consegui modificar as tabelas de encaminhamento de acordo com as minhas necessidades, mas aparentemente isso não é suficiente!

Mesmo que as minhas regras pareçam correctas para conseguir dividir túneis, continuo a ter Falha Geral.Conseguiram resolver um problema semelhante?

• O meu portal para a Internet é 192.168.163.2
• O meu portal para a rede da empresa é 10.64.202.1 (portanto todo 10..._. * sub-rede que trato como “comapny’s”)

É assim que a minha tabela de encaminhamento se parece agora (após modificações manuais enquanto a VPN está ligada)

ainda assim o resultado do ping segue

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.

apenas para a referência, Abaixo está como se parece a tabela de rotas quando a VPN está desligada (inalterada)

e é assim que a tabela se parece quando a VPN está ligada (inalterada) nesse caso quando estou a tentar pingar 8.8.8.8 simplesmente fico sem tempo (uma vez que a firewall da empresa não permite que o tráfego saia da intranet)

Não sei se o entendi bem, mas primeiro esclareço a minha compreensão:

Você tem uma LAN local (por exemplo, digamos 10.0.0.0/16, e um servidor Cisco VPN remoto (por exemplo, 64.0.0.0/16). Pretende ligar-se ao servidor VPN através do cliente Cisco VPN e, no entanto, precisa de ter acesso à LAN. Neste caso, pretende separar o conjunto 10.0.x.x/16 da ligação VPN). A seguinte rota deve ser adicionada num cliente Mac:

/sbin/route add -net 10.0 -interface en1

onde en1 é a interface através da qual está ligado à sua LAN. Sei que também pode adicionar a mesma coisa no Windows e Linux.

Tentar remover essas entradas com gateway 10.64.202.13 ver se o ping 8.8.8.8 funciona e depois adicioná-las uma a uma e identificar qual delas está a causar o problema.

Como é que se corrigiu a DLL. Não posso sequer modificar a tabela de encaminhamento porque continua a adicionar a 0.0.0.0 com a gateway VPN de volta.