Come consentire l'accesso alla LAN locale mentre si è connessi alla VPN Cisco?

Come posso mantenere l'accesso LAN locale mentre sono connesso a Cisco VPN?

Durante la connessione tramite Cisco VPN, il server deve essere in grado di indicare al client di impedire l'accesso alla LAN locale.

Supponendo che questa opzione lato server non possa essere disattivata, come si può consentire l'accesso alla LAN locale mentre si è connessi con un client VPN Cisco?

Pensavo che fosse semplicemente una questione di percorsi aggiunti a catturare il traffico LAN con una metrica più alta, ad esempio:

  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

E provare a eliminare il 10.0.x.x -> 192.168.199.12percorso non ha alcun effetto:

>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

E mentre potrebbe ancora essere semplicemente un problema di routing, i tentativi di aggiungere o eliminare le route falliscono.

A quale livello il driver client Cisco VPN sta facendo cosa nello stack di rete che sostituisce la capacità di un amministratore locale di amministrare la propria macchina?

Il client Cisco VPN non può utilizzare la magia. È ancora software in esecuzione sul mio computer. Quale meccanismo utilizza per interferire con la rete della mia macchina? Cosa succede quando un pacchetto IP / ICMP arriva sulla rete? In quale parte dello stack di rete viene mangiato il pacchetto?

Guarda anche

• Nessuna connessione Internet con Cisco VPN
• Cisco VPN Client interrompe la connettività al mio server LDAP
• Cisco VPN interrompe la navigazione in Windows 7
• Come posso vietare la creazione di un percorso in Windows XP al momento della connessione a Cisco VPN?
• Reindirizzamento del traffico LAN e Internet locale quando si è in VPN
• Client VPN "Consenti accesso LAN locale"
• Consenti accesso LAN locale per client VPN sull'esempio di configurazione del concentratore VPN 3000
• Accesso LAN scomparso quando mi collego alla VPN
• Documentazione di Windows XP: route

Modifica: cose che non ho ancora provato:

>route delete 10.0.*

Aggiornamento: poiché Cisco ha abbandonato il suo vecchio client, a favore di AnyConnect (VPN basata su HTTP SSL), questa domanda, irrisolta, può essere lasciata come una reliquia della storia.

Andando avanti, possiamo provare a risolvere lo stesso problema con il loro nuovo cliente .

Il problema con Anyconnect è che prima modifica la tabella di routing, quindi la baby sitter e la risolve se si modifica manualmente. Ho trovato una soluzione per questo. Funziona con la versione 3.1.00495, 3.1.05152, 3.1.05170 e probabilmente qualsiasi altra cosa nella famiglia 3.1. Può funzionare con altre versioni, almeno un'idea simile dovrebbe funzionare supponendo che il codice non venga riscritto. Fortunatamente per noi Cisco ha messo la baby-sitter "baby is wake" in una libreria condivisa. Quindi l'idea è che impediamo l'azione di vpnagentd tramite LD_PRELOAD.

1. Per prima cosa creiamo un file 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: questo codice funziona solo con Linux. Per applicare questa soluzione a una macchina macOS, consultare la versione adattata di macOS .

2. Quindi compilalo in questo modo:

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

3. Installa libhack.sonel percorso della libreria Cisco:

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

4. Abbattere l'agente:

   /etc/init.d/vpnagentd stop
   

5. Assicurati che sia davvero giù

   ps auxw | grep vpnagentd
   

   In caso contrario, kill -9per essere sicuro.

6. Quindi correggi /etc/init.d/vpnagentd aggiungendo LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so dove viene invocato vpnagentd in modo che assomigli a questo:

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

7. Ora avvia l'agente:

   /etc/init.d/vpnagentd start
   

8. Correggi iptables, perché AnyConnect fa un casino con loro:

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

   Potresti voler fare qualcosa di più avanzato qui per consentire l'accesso solo a determinati host LAN.

9. Ora correggi i percorsi come preferisci, ad esempio:

   route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
   

10. Controlla se sono davvero lì:

    route -n
    

Una versione precedente e più semplice di questo hack forniva una funzione che faceva solo "return 0;" - quel poster notava che "L'unico effetto collaterale che ho osservato finora è che vpnagentd sta usando il 100% della CPU come riportato dall'alto, ma la CPU complessiva è solo il 3% di utenti e il 20% di sistema, e il sistema è perfettamente reattivo L'ho tracciato, sembra che stia facendo due selezioni in un ciclo quando il minimo ritorna da entrambi rapidamente, ma non legge né scrive mai - suppongo che la chiamata che ho tagliato con LD_PRELOAD avrebbe dovuto leggere. Potrebbe esserci un modo più pulito per farlo, ma è abbastanza buono per me finora. Se qualcuno ha una soluzione migliore, per favore condividi ".

Il problema con il banale hack è che ha causato un singolo core della CPU pari al 100% in ogni momento, riducendo efficacemente il conteggio dei thread della CPU hardware di uno - indipendentemente dal fatto che la connessione VPN fosse attiva o meno. Ho notato che le selezioni che il codice stava facendo erano su un socket netlink, che invia i dati vpnagentd quando cambia la tabella di routing. vpnagentd continua a notare che c'è un nuovo messaggio sul socket netlink e chiama routeCallBackHandler per gestirlo, ma dal momento che l'hack banale non cancella il nuovo messaggio, continua a essere chiamato ancora e ancora. il nuovo codice fornito sopra cancella i dati di netlink in modo che il ciclo infinito che ha causato il 100% della CPU non si verifichi.

Se qualcosa non funziona, esegui gdb -p $(pidof vpnagentd)una volta allegato:

b socket
c
bt

e vedi in quale chiamata ti trovi. Quindi indovina quale vuoi tagliare, aggiungila a hack.c e ricompila.

Questo è MOLTO contorto, ma se si crea una VM minima utilizzando VMWare Player o simile e si esegue il client Cisco AnyConnect VPN, potrebbe essere possibile impostare il routing come desiderato utilizzando gli adattatori di rete virtuale VMWare o semplicemente utilizzare il VM per l'accesso a qualsiasi risorsa sia richiesta tramite la VPN SSL Cisco e file "trascina / rilascia" sul / dalla tua macchina reale.

Anche il software Shrew Soft VPN mi ha aiutato, come suggerito da Ian Boyd .

Può importare profili client Cisco VPN. Ho utilizzato Cisco VPN Client versione 5.0.05.0290 e dopo aver installato Shrew VPN (versione 2.1.7) e importato il profilo Cisco, sono stato in grado di accedere alla LAN locale mentre ero connesso alla VPN aziendale senza alcuna configurazione aggiuntiva della connessione Shrew VPN (o Software).

Grazie a Sasha Pachev per il bel trucco sopra.

vpnagentdfa anche casino con il resolver sovrascrivendo le modifiche apportate a /etc/resolv.conf. L'ho risolto alla fine vincendo la gara contro di essa:

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

Non dimenticare di chattr -i /etc/resolv.confdisconnetterti.

Sto cercando di risolverlo intercettando il callback, come per il metodo di route sopra, ma non riesco ancora a trovare il callback o il metodo corrispondente.

Aggiornamento 1/2: è stato stracerivelato che vpnagentdsta utilizzando l' inotifyAPI per monitorare le modifiche al file del resolver. Da lì in poi fu in discesa. Ecco l'hack aggiuntivo:

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

Questo è un po 'eccessivo, garantito, poiché disabilita tutti i file che guardano per l'agente. Ma sembra funzionare bene.

Lo script di wrapper client VPN sottostante integra tutte le funzionalità (aggiornate per includere questo hack aggiuntivo). chattrnon è più utilizzato / necessario.

Aggiornamento 3: corrette le impostazioni nome utente / password nello script. Ora utilizza un vpn.conffile con il formato descritto di seguito (e autorizzazioni 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

La mia azienda usa ancora quel VPN. Il client vpnc modifica semplicemente le impostazioni di iptables in questo modo:

# iptables-save
# Generato da iptables-save v1.4.10 il dom 17 giu 14:12:20 2012
*filtro
: 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 ACCETTA 
-A INPUT -i tun0 -j ACCETTA 
-A INGRESSO -i lo0 -j ACCETTA
-A INPUT -j DROP 
-A USCITA -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCETTA 
-A USCITA -o tun0 -j ACCETTA 
-A USCITA -o lo0 -j ACCETTA 
-A USCITA -j DROP 
COMMETTERE

Filtra tutto ad eccezione del traffico VPN.

Ottieni semplicemente il filtro in un file con iptables-save, aggiungi le linee di accesso INPUT e OUTPOUT che soddisfano le tue esigenze e riapplica il file con iptables-restore.

ad esempio per accedere a una rete locale su 192.168.0

# Generato da iptables-save v1.4.10 il dom 17 giu 14:12:20 2012
*filtro
: 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 ACCETTA 
-A INPUT -s 192.168.0.0/24 -d 192.168.0.14/32 -j ACCEPT #local in
-A INPUT -i tun0 -j ACCETTA 
-A INGRESSO -i lo0 -j ACCETTA 
-A INPUT -j DROP 
-A USCITA -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCETTA 
-A USCITA -s 192.168.0.14/32 -d 192.168.0.0/24 -j ACCEPT #local out
-A USCITA -o tun0 -j ACCETTA 
-A USCITA -o lo0 -j ACCETTA 
-A USCITA -j DROP 
COMMETTERE

Qualche novità al riguardo?

A quale livello il driver client Cisco VPN sta facendo cosa nello stack di rete che sostituisce la capacità di un amministratore locale di amministrare la propria macchina?

Sono pienamente d'accordo e mi chiedevo la stessa cosa.

Ad ogni modo, è un'app che richiede i privilegi di amministratore per l'installazione e durante l'esecuzione può benissimo filtrare ciò che fai ...

Anche i miei tentativi su Windows falliscono:

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. Nessuna metrica inferiore a 20 qui sembra.

Non so se l'ho capito bene, ma prima chiarisco la mia comprensione:

Hai una LAN locale (ad esempio, 10.0.0.0/16 e un server VPN Cisco remoto (ad esempio, 64.0.0.0/16). Desideri connetterti al server VPN tramite il client VPN Cisco e tuttavia è necessario per avere l'accesso alla LAN. In questo caso si desidera separare l'intero 10.0.xx / 16 dalla connessione VPN). La seguente route deve essere aggiunta in un client Mac:

/sbin/route add -net 10.0 -interface en1

dove en1 è l'interfaccia attraverso la quale si è connessi alla propria LAN. So che puoi aggiungere la stessa cosa anche in Windows e Linux.

Dal momento che non posso aggiungere commenti, posterò qui. Sto correndo su Windows.

La soluzione che utilizza Virtual Machine ed esegue AnyConnect all'interno della VM e quindi utilizza VM come mediatore tra il tuo ambiente di lavoro e la rete aziendale non funzionerà se il tuo dipartimento IT "amato" instrada 0.0.0.0 tramite VPN e quindi anche la tua rete locale (incluso questo tra PC locale e VM) viene instradato tramite VPN (sic!).

Ho provato ad applicare la soluzione pubblicata da @Sasha Pachev ma alla fine ho finito per patchare .dll in modo che restituisca 0 all'inizio della funzione. Alla fine, dopo qualche combattimento con la libreria dinamica, sono stato in grado di modificare le tabelle di routing in base alle mie esigenze, ma a quanto pare non è abbastanza!

Anche se le mie regole sembrano essere corrette per ottenere il tunneling diviso, ottengo comunque un fallimento generale. Ti sei imbattuto in un problema simile a quello che hai potuto risolvere?

• Il mio gateway per Internet è 192.168.163.2
• La mia porta di accesso della rete della società è 10.64.202.1 (quindi tutto il 10. . . * Sottorete tratto come "comapny di")

Ecco come appare la mia tabella di routing ora (dopo le modifiche manuali mentre la VPN è attiva)

ma il risultato del ping sta seguendo

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 per riferimento, di seguito è riportato l'aspetto della tabella di route quando la VPN è disconnessa (inalterata)

e questo è come appare la tabella quando la VPN è connessa (inalterata) in quel caso quando sto cercando di eseguire il ping 8.8.8.8ottengo semplicemente il timeout (poiché il firewall dell'azienda non consente al traffico di uscire dall'intranet)

Per coloro che desiderano mantenere il controllo della propria tabella di routing durante l'utilizzo di una VPN SSL Cisco AnyConnect, consultare OpenConnect . Supporta entrambi VPN VPN Cisco AnyConnect e non tenta di interrompere o "proteggere" le voci della tabella di routing. @Vadzim allude a questo in un commento sopra .

Dopo aver provato tutto tranne aver patchato AnyConnect Secure Mobility Client, sono stato in grado di sostituirlo con successo su Windows con OpenConnect GUI . Ciò mi ha permesso di mantenere la connettività alle risorse locali (e aggiornare la tabella di routing).

Uso OpenConnect su Windows ma supporta anche Linux, BSD e macOS (tra le altre piattaforme) secondo la pagina del progetto .

Prova a rimuovere quelle voci con gateway per 10.64.202.13vedere se il ping 8.8.8.8funziona, quindi aggiungile una ad una e identifica quale causa il problema.

Come hai patchato la DLL. Non riesco nemmeno a modificare la tabella di routing perché continua ad aggiungere 0.0.0.0nuovamente il gateway VPN.