Jak umożliwić dostęp do lokalnej sieci LAN podczas połączenia z Cisco VPN?

Problem z Anyconnect polega na tym, że najpierw modyfikuje tablicę routingu, a następnie niańczy ją i naprawia, jeśli zmodyfikujesz ją ręcznie. Znalazłem na to obejście. Działa z wersjami 3.1.00495, 3.1.05152, 3.1.05170 i prawdopodobnie wszystkim innym z rodziny 3.1. Może działać z innymi wersjami, przynajmniej podobny pomysł powinien zadziałać zakładając, że kod nie zostanie przepisany. Na szczęście dla nas Cisco umieściło wywołanie niańki “dziecko się obudziło” we współdzielonej bibliotece. Idea jest więc taka, że zapobiegamy działaniu vpnagentd poprzez LD_PRELOAD.

1. Najpierw tworzymy plik hack.c:

Uwaga: Ten kod działa tylko w systemie Linux. Aby zastosować to rozwiązanie na maszynie z systemem macOS, zobacz wersja dostosowana do macOS .

1. Następnie kompilujemy go w ten sposób:

2. Zainstaluj libhack.so w ścieżce biblioteki Cisco:

3. Uruchom agenta:

4. Upewnij się, że naprawdę jest wyłączony

5. Następnie popraw /etc/init.d/vpnagentd dodając LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so w miejscu gdzie wywoływany jest vpnagentd, tak aby wyglądało to tak:

6. Teraz uruchom agenta:

7. Napraw iptables, bo AnyConnect robi z nimi bałagan:

8. Teraz popraw trasy według własnego uznania, na przykład:

9. Sprawdź, czy rzeczywiście tam są:

Poprzednia, prostsza wersja tego hacka dawała funkcję, która wykonywała tylko “return 0;” - tamten plakat zauważył, że “Jedynym efektem ubocznym, jaki zaobserwowałem do tej pory, jest to, że vpnagentd używa 100% CPU, jak zgłasza top, ale ogólny CPU wynosi tylko 3% użytkownika i 20% systemu, a system jest doskonale responsywny. Sprawdziłem to, wydaje się, że wykonuje dwa selekty w pętli, gdy bezczynnie wraca z obu szybko, ale nigdy nie czyta ani nie zapisuje - przypuszczam, że wywołanie, które wyciąłem z LD_PRELOAD miało czytać. Być może istnieje czystszy sposób na zrobienie tego, ale jak na razie jest to dla mnie wystarczająco dobre. Jeśli ktoś ma lepsze rozwiązanie, proszę się podzielić.”

Problem z trywialnym hackiem polega na tym, że spowodował on, że pojedynczy rdzeń cpu był w 100% przez cały czas, skutecznie zmniejszając liczbę wątków twojego sprzętowego cpu o jeden - niezależnie od tego, czy twoje połączenie vpn było aktywne, czy nie. Zauważyłem, że selekty, które wykonywał kod, były na gnieździe netlink, które wysyła dane do vpnagentd, gdy zmienia się tabela routingu. vpnagentd ciągle zauważa, że jest nowa wiadomość na gnieździe netlink i wywołuje routeCallBackHandler, aby sobie z tym poradzić, ale ponieważ trywialny hack nie czyści nowej wiadomości, po prostu jest wywoływany ponownie i ponownie. nowy kod podany powyżej spłukuje dane netlink, więc niekończąca się pętla, która spowodowała 100% cpu, nie ma miejsca.

Jeśli coś nie działa, zrób gdb -p $(pidof vpnagentd), po dołączeniu:

b socket
c
bt

i zobacz, w którym wywołaniu jesteś. Następnie zgadnij, które z nich chcesz wyciąć, dodaj je do hack.c i przekompiluj.

Jest to BARDZO skomplikowane, ale jeśli utworzysz minimalną maszynę wirtualną za pomocą VMWare Player lub podobnego programu i uruchomisz w niej klienta Cisco AnyConnect VPN, może być możliwe skonfigurowanie routingu według własnego uznania za pomocą wirtualnych adapterów sieciowych VMWare lub po prostu użycie maszyny wirtualnej w celu uzyskania dostępu do dowolnych zasobów za pośrednictwem Cisco SSL VPN i “przeciągania/rozrzucania” plików do/z rzeczywistej maszyny.

Shrew ](http://www.shrew.net “Free as of March 2013”) Soft VPN software did the trick for me, also, as Ian Boyd suggested.

Może ono importować profile klientów Cisco VPN. Używałem Cisco VPN Client w wersji 5.0.05.0290, a po zainstalowaniu Shrew VPN (wersja 2.1.7) i zaimportowaniu profilu Cisco, byłem w stanie uzyskać dostęp do lokalnej sieci LAN, będąc podłączonym do korporacyjnej sieci VPN bez żadnej dodatkowej konfiguracji połączenia Shrew VPN (lub oprogramowania).

Podziękowania dla Sasha Pachev za ładny hack powyżej.

vpnagentd również miesza z resolverem poprzez nadpisywanie zmian dokonanych w /etc/resolv.conf. Rozwiązałem to, ostatecznie wygrywając wyścig z nim:

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

Nie zapomnij o chattr -i /etc/resolv.conf podczas rozłączania.

Próbuję to rozwiązać, przechwytując wywołanie zwrotne, tak jak w przypadku metody tras powyżej, ale nie mogę jeszcze znaleźć odpowiedniego wywołania zwrotnego lub metody.

Aktualizacja1/2: A strace ujawnił, że vpnagentd używa API inotify do monitorowania zmian w pliku resolvera. Od tego momentu było już z górki. Oto dodatkowy hack:

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

To trochę overkill, przyznam, ponieważ wyłącza wszystkie obserwowanie plików dla agenta. Ale wydaje się, że działa OK.

Poniższy skrypt wrappera klienta vpn integruje całą funkcjonalność (zaktualizowany, aby uwzględnić ten dodatkowy hack). chattr nie jest już używany/potrzebny.

Aktualizacja 3: Poprawiono ustawienia nazwy użytkownika/hasła w skrypcie. Teraz używa on pliku vpn.conf w formacie opisanym poniżej (i z uprawnieniami tylko dla roota).

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

Moja firma wciąż używa tego vpn. Klient vpnc po prostu zmienia ustawienia iptables w ten sposób:

# 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

Filtruje wszystko oprócz ruchu vpn.

Po prostu zapisz filtr w pliku za pomocą iptables-save, dodaj linie dostępu INPUT i OUTPOUT, które odpowiadają twoim potrzebom i ponownie zastosuj plik za pomocą iptables-restore.

na przykład, aby uzyskać dostęp do sieci lokalnej 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
```.

Dla tych, którzy chcą zachować kontrolę nad swoją tablicą routingu podczas korzystania z Cisco AnyConnect SSL VPN, sprawdź OpenConnect . Obsługuje on Cisco AnyConnect SSL VPN i nie próbuje zakłócać lub “zabezpieczać” wpisów w tablicy routingu. @Vadzim ](https://superuser.com/users/110188/vadzim) nawiązuje do tego w komentarzu powyżej .

Po wypróbowaniu wszystkiego oprócz łatania AnyConnect Secure Mobility Client, udało mi się z powodzeniem zastąpić go w Windows przez OpenConnect GUI . Pozwoliło mi to na utrzymanie łączności z lokalnymi zasobami (i aktualizację tablicy routingu).

Używam OpenConnect na Windows, ale wspiera on również Linux, BSD i macOS (między innymi platformy) zgodnie ze stroną projektu .

Jakieś wieści na ten temat?

Na jakim poziomie sterownik klienta Cisco VPN robi co w stosie sieciowym, że przejmuje możliwość administrowania maszyną przez lokalnego administratora?

W pełni się zgadzam i zastanawiałem się nad tym samym.

Tak czy inaczej, jest to aplikacja, która wymaga uprawnień administratora do instalacji i podczas gdy działa, może równie dobrze filtrować to, co robisz…

Moje próby na Windowsie też zawodzą:

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. Wygląda na to, że nie ma tu metryki poniżej 20.

Ponieważ nie mogę dodawać komentarzy, napiszę tutaj. Pracuję na systemie Windows.

Rozwiązanie wykorzystujące maszynę wirtualną i uruchomienie AnyConnect wewnątrz maszyny wirtualnej, a następnie użycie maszyny wirtualnej jako pośrednika pomiędzy środowiskiem pracy a siecią firmową nie zadziała, jeśli Twój “ukochany” dział IT przekieruje 0.0.0.0 przez VPN, więc nawet Twoja sieć lokalna (w tym ta pomiędzy lokalnym komputerem a maszyną wirtualną) jest przekierowywana przez VPN(sic!).

Próbowałem zastosować rozwiązanie zamieszczone przez @Sasha Pachev, ale ostatecznie skończyło się na łataniu .dll tak, aby zwracał 0 na początku funkcji. Ostatecznie, po kilku zmaganiach z biblioteką dynamiczną, udało mi się zmodyfikować tabele routingu zgodnie z moimi potrzebami, ale najwyraźniej to nie wystarczy!

Mimo, że moje reguły wydają się być poprawne do osiągnięcia split tunnelingu, wciąż dostaję General Failure._Czy natknąłeś się na podobny problem i byłeś w stanie go rozwiązać? _

• Moja brama do Internetu to 192.168.163.2
• Moja brama do sieci firmowej to 10.64.202.1 (więc całą podsieć 10... *

Tak wygląda teraz moja tabela routingu (po ręcznych modyfikacjach, gdy VPN jest włączony)

a wyniki pingów są następujące

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.

Tylko dla odniesienia, poniżej jest jak wygląda tabela tras gdy VPN jest odłączony (bez zmian)

a tak wygląda tabela gdy VPN jest podłączony (bez zmian) w tym przypadku gdy próbuję pingować 8.8.8.8 dostaję po prostu timeout (ponieważ firmowy firewall nie pozwala na ruch poza intranet)

Nie wiem, czy dobrze to zrozumiałem, ale najpierw wyjaśnię moje rozumienie:

Masz lokalną sieć LAN (na przykład powiedzmy 10.0.0.0/16, oraz zdalny serwer Cisco VPN (na przykład 64.0.0.0/16). Chcesz połączyć się z serwerem VPN za pomocą klienta Cisco VPN, a mimo to musisz mieć dostęp do sieci LAN. W tym przypadku chcesz oddzielić cały 10.0.x.x/16 od połączenia VPN). W kliencie Mac należy dodać następującą trasę:

/sbin/route add -net 10.0 -interface en1

gdzie en1 to interfejs, przez który jesteśmy podłączeni do sieci LAN. Wiem, że to samo można dodać również w Windowsie i Linuksie.

Spróbuj usunąć te wpisy z gateway 10.64.202.13 zobacz czy ping 8.8.8.8 działa, a następnie dodaj je z powrotem jeden po drugim i zidentyfikuj, który z nich powoduje problemy.

Jak załatałeś DLL. Nie mogę nawet zmodyfikować tablicy routingu, ponieważ ciągle dodaje z powrotem wpisy 0.0.0.0 z bramą VPN.