Hoe kan ik lokale LAN-toegang toestaan terwijl ik verbonden ben met Cisco VPN?

Het probleem met Anyconnect is dat het eerst de routeringstabel wijzigt, en dan pas oppast en het weer in orde maakt als je het handmatig wijzigt. Ik heb hier een workaround voor gevonden. Werkt met versie 3.1.00495, 3.1.05152, 3.1.05170, en waarschijnlijk met alle andere versies in de 3.1 familie. Misschien werkt het ook met andere versies, althans een soortgelijk idee zou moeten werken, ervan uitgaande dat de code niet herschreven wordt. Gelukkig voor ons heeft Cisco de babysitter “baby is wakker” oproep in een gedeelde bibliotheek gezet. Dus het idee is dat we voorkomen dat vpnagentd actie onderneemt via LD_PRELOAD.

1. Eerst maken we een bestand hack.c:

Note: Deze code werkt alleen met Linux. Voor het toepassen van deze oplossing op een macOS machine, zie de macOS aangepaste versie .

1. Dan compileer je het als volgt:

2. Installeer libhack.so in het Cisco-bibliotheekpad:

3. Haal de agent naar beneden:

4. Zorg ervoor dat hij echt down is

5. Herstel vervolgens /etc/init.d/vpnagentd door LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so toe te voegen op de plaats waar vpnagentd wordt aangeroepen, zodat het er als volgt uitziet:

6. Start nu de agent:

7. Repareer iptables, want AnyConnect knoeit daarmee:

8. Maak nu de routes zoals je wilt, bijvoorbeeld:

9. Controleer of ze er echt zijn:

Een vorige, eenvoudigere versie van deze hack gaf een functie die alleen “return 0;” deed - die poster merkte op dat “Het enige neveneffect dat ik tot nu toe heb waargenomen is dat vpnagentd 100% van de CPU gebruikt zoals gerapporteerd door top, maar de totale CPU is slechts 3% gebruiker en 20% systeem, en het systeem is perfect responsief. Ik heb het gestresst, het lijkt twee selects te doen in een lus wanneer het inactief is en snel van beide terugkeert, maar het leest of schrijft nooit - ik veronderstel dat de aanroep die ik eruit geknipt heb met LD_PRELOAD verondersteld werd te lezen. Er is misschien een schonere manier om het te doen, maar tot nu toe is het goed genoeg voor mij. Als iemand een betere oplossing heeft, deel die dan alsjeblieft.”

Het probleem met de triviale hack is dat het ervoor zorgde dat een enkele cpu core de hele tijd 100% was, waardoor je hardware cpu thread count effectief met een werd verminderd - of je vpn verbinding nu actief was of niet. Ik merkte dat de selecties die de code deed op een netlink socket waren, die vpnagentd gegevens stuurt wanneer de routeringstabel verandert. vpnagentd merkt steeds dat er een nieuw bericht op de netlink socket is en roept de routeCallBackHandler op om het af te handelen, maar omdat de triviale hack het nieuwe bericht niet wist, blijft het gewoon steeds opnieuw opgeroepen worden. de nieuwe code hierboven spoelt de netlink gegevens door, zodat de eindeloze lus die de 100% cpu veroorzaakte, niet gebeurt.

Als iets niet werkt, doe dan gdb -p $(pidof vpnagentd), eenmaal bevestigd:

b socket
c
bt

en kijk in welke oproep je zit. Raad dan welke je eruit wilt knippen, voeg het toe aan hack.c en hercompileer.

Dit is ZEER ingewikkeld, maar als u een minimale VM maakt met VMWare Player of iets dergelijks, en daarin de Cisco AnyConnect VPN-client uitvoert, is het wellicht mogelijk om de routering naar wens in te stellen met behulp van de virtuele VMWare-netwerkadapters, of gewoon de VM te gebruiken voor toegang tot de bronnen die nodig zijn via het Cisco SSL VPN en bestanden van/naar uw eigen machine te “slepen”.

Soft VPN software deed het ook voor mij, zoals Ian Boyd voorstelde.

Het kan Cisco VPN client profielen importeren. Ik heb Cisco VPN Client versie 5.0.05.0290, en na het installeren van de Shrew VPN (versie 2.1.7) en het importeren van Cisco profiel, was ik in staat om toegang te krijgen tot de lokale LAN, terwijl aangesloten op corporate VPN zonder enige extra configuratie van Shrew VPN-verbinding (of software).

Met dank aan Sasha Pachev voor de mooie hack hierboven.

vpnagentd knoeit ook met de resolver door de wijzigingen van /etc/resolv.conf te overschrijven. Ik heb het opgelost door uiteindelijk de race ertegen te winnen:

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

Vergeet niet om chattr -i /etc/resolv.conf te gebruiken bij het verbreken van de verbinding.

Ik probeer het op te lossen door de callback te onderscheppen, zoals bij de routes methode hierboven, maar kan de corresponderende callback of methode nog niet vinden.

Update1/2: Een strace onthulde dat vpnagentd de inotify API gebruikt om de resolver file veranderingen te monitoren. Vanaf daar ging het bergafwaarts. Hier is de extra hack:

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

Dat is een beetje overkill, toegegeven, omdat het alle bestandsbewaking voor de agent uitschakelt. Maar het lijkt goed te werken.

Het onderstaande vpn client wrapper script integreert alle functionaliteit (bijgewerkt met deze extra hack). chattr wordt niet langer gebruikt/nodig.

Update 3: gebruikersnaam/wachtwoord instellingen in het script verbeterd. Het gebruikt nu een vpn.conf bestand met het formaat zoals hieronder beschreven (en root-only permissies).

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

Mijn bedrijf gebruikt nog steeds die vpn. De vpnc client verandert gewoon je iptables instellingen op die manier :

# 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

Het filtert alles behalve het vpn verkeer.

Zet het filter gewoon in een bestand met iptables-save, voeg INPUT en OUTPOUT toegangsregels toe die aan je behoeften voldoen en pas het bestand opnieuw toe met iptables-restore.

om bijvoorbeeld toegang te krijgen tot een lokaal netwerk op 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

Wie de controle over zijn routeringstabel wil behouden wanneer hij een Cisco AnyConnect SSL VPN gebruikt, kan eens kijken naar OpenConnect . OpenConnect ondersteunt de Cisco AnyConnect SSL VPN en doet geen pogingen om routing-tabelgegevens te verstoren of te ‘beveiligen’. @Vadzim ](https://superuser.com/users/110188/vadzim) zinspeelt hierop in een commentaar hierboven .

Na alles geprobeerd te hebben, behalve het patchen van de AnyConnect Secure Mobility Client, was ik in staat om deze op Windows met succes te vervangen door OpenConnect GUI . Dit stelde mij in staat om connectiviteit met lokale bronnen te behouden (en de routing tabel bij te werken).

Ik gebruik OpenConnect op Windows, maar het ondersteunt ook Linux, BSD, en macOS (onder andere platforms) volgens de project pagina .

Enig nieuws hierover?

Op welk niveau doet het stuurprogramma van de Cisco VPN-client wat in de netwerkstack dat het vermogen van een lokale beheerder om zijn machine te beheren tenietdoet?

Daar ben ik het helemaal mee eens en ik vroeg me hetzelfde af.

Hoe dan ook, het is een app die admin rechten vereist om te installeren en terwijl het draait kan het heel goed filteren wat je doet…

Mijn pogingen op Windows mislukken ook:

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. Geen metriek onder de 20 hier lijkt het.

Omdat ik geen commentaar kan toevoegen, zal ik het hier posten. Ik draai op Windows.

De oplossing om Virtual Machine te gebruiken en AnyConnect in de VM te draaien en dan VM te gebruiken als een mediator tussen je werkomgeving en het netwerk van het bedrijf zal niet werken als je “geliefde” IT afdeling 0.0.0.0 door VPN routeert waardoor zelfs je lokale netwerk (inclusief dit tussen je lokale PC en VM) door de VPN(sic!) wordt gerouteerd.

Ik heb geprobeerd de oplossing van @Sasha Pachev toe te passen, maar uiteindelijk heb ik .dll zo gepatcht dat het 0 retourneert aan het begin van de functie. Uiteindelijk, na wat vechten met de dynamische bibliotheek, was ik in staat om de routing tabellen aan te passen aan mijn behoeften, maar blijkbaar is dat niet genoeg!

Hoewel mijn regels correct lijken te zijn om gesplitste tunneling te bereiken, krijg ik nog steeds General Failure. _ Ben je een soortgelijk probleem tegengekomen en heb je het kunnen oplossen? _

• Mijn gateway naar het internet is 192.168.163.2
• Mijn gateway naar het bedrijfsnetwerk is 10.64.202.1 (dus het hele 10... * subnet behandel ik als “van het bedrijf”)

Zo ziet mijn routing tabel er nu uit (na handmatige aanpassingen terwijl VPN aan staat)

toch zijn de resultaten van ping als volgt

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.

Alleen voor de referentie, hieronder is hoe de route tabel eruit ziet wanneer VPN is losgekoppeld (ongewijzigd)

en dit is hoe de tabel eruit ziet wanneer VPN is aangesloten (ongewijzigd) in dat geval wanneer ik probeer 8.8.8.8 te pingen krijg ik gewoon timeout (aangezien de firewall van het bedrijf niet toestaat dat verkeer buiten het intranet gaat)

Ik weet niet of ik het goed begrepen heb, maar ik zal eerst mijn begrip verduidelijken:

Je hebt een lokaal LAN (bijvoorbeeld, zeg 10.0.0.0/16, en een remote Cisco VPN Server (bijvoorbeeld, 64.0.0.0/16). U wilt verbinding maken met de VPN-server via de Cisco VPN-client en toch moet u toegang hebben tot het LAN. In dit geval wilt u de gehele 10.0.x.x/16 van de VPN-verbinding scheiden). De volgende route moet worden toegevoegd in een Mac client:

/sbin/route add -net 10.0 -interface en1

waarbij en1 de interface is via welke je verbonden bent met je LAN. Ik weet dat je hetzelfde ook in Windows en Linux kunt toevoegen.

Probeer die entries met gateway 10.64.202.13 te verwijderen en kijk of ping 8.8.8.8 werkt, voeg ze dan één voor één terug toe en identificeer welke het probleem veroorzaakt.

Hoe heb je de DLL aangepast. Ik kan zelfs de routeringstabel niet aanpassen omdat het steeds de 0.0.0.0 met VPN gateway terug toevoegt.