Как разрешить доступ локальной сети при подключении к Cisco VPN?

Как я могу поддерживать доступ к локальной сети при подключении к Cisco VPN?

При подключении с использованием Cisco VPN сервер должен указывать клиенту, чтобы он запрещал доступ к локальной сети.

Предполагая, что этот параметр на стороне сервера нельзя отключить, как разрешить доступ к локальной сети, когда он подключен к клиенту Cisco VPN?

Раньше я думал, что это просто вопрос добавления маршрутов, которые захватывают трафик локальной сети с более высокой метрикой, например:

  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

И попытка удалить 10.0.x.x -> 192.168.199.12маршрут не имеет никакого эффекта:

>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

И хотя это все еще может быть просто проблемой маршрутизации, попытки добавить или удалить маршруты терпят неудачу.

На каком уровне драйвер клиента Cisco VPN делает то, что в сетевом стеке, которое принимает, переопределяет способность локального администратора управлять своей машиной?

Клиент Cisco VPN не может использовать магию. Это все еще программное обеспечение, работающее на моем компьютере. Какой механизм он использует для вмешательства в сеть моей машины? Что происходит, когда в сеть поступает пакет IP / ICMP? Где в сетевом стеке пакет съедается?

Смотрите также

• Нет интернет-соединения с Cisco VPN
• Cisco VPN Client прерывает соединение с моим сервером LDAP
• Cisco VPN останавливает просмотр Windows 7
• Как я могу запретить создание маршрута в Windows XP при подключении к Cisco VPN?
• Перераспределение локальной сети и интернет-трафика в VPN
• VPN-клиент «Разрешить доступ к локальной сети»
• Разрешить локальный доступ к локальной сети для клиентов VPN в примере конфигурации концентратора VPN 3000
• Доступ к локальной сети пропал при подключении к VPN
• Документация Windows XP: Маршрут

Изменить: вещи, которые я еще не пробовал:

>route delete 10.0.*

Обновление: поскольку Cisco отказалась от своего старого клиента в пользу AnyConnect (VPN на основе HTTP SSL), этот вопрос, нерешенный, можно оставить как пережиток истории.

В дальнейшем мы можем попытаться решить ту же проблему со своим новым клиентом .

Проблема с Anyconnect заключается в том, что он сначала изменяет таблицу маршрутизации, затем присматривает за ней и исправляет ее, если вы измените ее вручную. Я нашел обходной путь для этого. Работает с версиями 3.1.00495, 3.1.05152, 3.1.05170 и, вероятно, с чем-либо еще в семействе 3.1. Может работать с другими версиями, по крайней мере, аналогичная идея должна работать при условии, что код не будет переписан. К счастью для нас, компания Cisco поместила вызов няни «бодрствующий ребенок» в общую библиотеку. Таким образом, идея заключается в том, что мы предотвращаем действия vpnagentd через LD_PRELOAD.

1. Сначала мы создаем файл 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;
   }
   

Примечание. Этот код работает только в Linux. Для применения этого решения на машине MacOS, см. Адаптированную версию MacOS .

2. Затем скомпилируйте это так:

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

3. Установите libhack.soв путь к библиотеке Cisco:

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

4. Сбить агента:

   /etc/init.d/vpnagentd stop
   

5. Убедитесь, что это действительно вниз

   ps auxw | grep vpnagentd
   

   Если нет, kill -9просто чтобы быть уверенным.

6. Затем исправьте /etc/init.d/vpnagentd, добавив, LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so где вызывается vpnagentd, чтобы он выглядел так:

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

7. Теперь запустите агент:

   /etc/init.d/vpnagentd start
   

8. Исправьте iptables, потому что AnyConnect портит их:

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

   Вы можете сделать что-то более продвинутое здесь, чтобы разрешить доступ только к определенным узлам локальной сети.

9. Теперь исправьте маршруты по своему усмотрению, например:

   route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
   

10. Проверьте, действительно ли они там:

    route -n
    

Предыдущая, более простая версия этого хака дала функцию, которая только «возвращала 0;» - на этом постере отмечалось, что «единственный побочный эффект, который я наблюдал до сих пор, заключается в том, что vpnagentd использует 100% ЦП, о чем сообщает top, но в целом ЦП составляет всего 3% пользователей и 20% системы, а система прекрасно реагирует». Я ограничил это, кажется, что он делает два выбора в цикле, когда простаивает, возвращаясь из обоих быстро, но он никогда не читает и не записывает - я предполагаю, что вызов, который я вырезал с помощью LD_PRELOAD, должен был прочитать. Возможно, есть более чистый способ сделать это, но для меня это пока хорошо. Если у кого-то есть лучшее решение, поделитесь ».

Проблема с тривиальным взломом состоит в том, что он заставляет одно ядро ​​процессора постоянно работать на 100%, эффективно уменьшая количество потоков аппаратного процессора на одно - было ли ваше соединение vpn активным или нет. Я заметил, что выборки, которые делал код, находились в сокете netlink, который отправляет данные vpnagentd при изменении таблицы маршрутизации. vpnagentd продолжает замечать, что в сокете netlink есть новое сообщение и вызывает routeCallBackHandler, чтобы разобраться с ним, но, поскольку тривиальный хак не очищает новое сообщение, он просто продолжает вызываться снова и снова. новый код, приведенный выше, сбрасывает данные netlink, поэтому бесконечный цикл, который привел к 100% -ному процессору, не происходит.

Если что-то не работает, сделайте gdb -p $(pidof vpnagentd), как только приложите:

b socket
c
bt

и посмотрите, в каком вызове вы находитесь. Затем просто догадайтесь, какой из них вы хотите вырезать, добавьте его в hack.c и перекомпилируйте.

Это ОЧЕНЬ запутанно, но если вы создаете минимальную виртуальную машину с помощью VMWare Player или аналогичного устройства и запускаете в ней клиент Cisco AnyConnect VPN, возможно, можно настроить маршрутизацию по своему усмотрению с использованием виртуальных сетевых адаптеров VMWare или просто использовать ВМ для доступа к любым ресурсам, необходимым через Cisco SSL VPN и «перетаскивание» файлов на / с вашей реальной машины.

Программное обеспечение Shrew Soft VPN также помогло мне, как предположил Иан Бойд .

Он может импортировать профили клиента Cisco VPN. Я использовал Cisco VPN Client версии 5.0.05.0290, и после установки Shrew VPN (версия 2.1.7) и импорта профиля Cisco я смог получить доступ к локальной локальной сети при подключении к корпоративной VPN без какой-либо дополнительной настройки подключения Shrew VPN (или программное обеспечение).

Спасибо Саше Пачеву за хороший взлом выше.

vpnagentdтакже портит распознаватель, перезаписывая изменения, внесенные в /etc/resolv.conf. Я решил это, в конечном итоге выиграв гонку против него:

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

Не забудьте chattr -i /etc/resolv.confпри отключении.

Я пытаюсь решить эту проблему путем перехвата обратного вызова, как для метода маршрутов, описанного выше, но пока не могу найти соответствующий обратный вызов или метод.

Обновление 1/2: straceобнаружение, vpnagentdиспользующее inotifyAPI для отслеживания изменений файла распознавателя. С этого момента это было вниз по склону. Вот дополнительный хак:

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

Это немного излишне, так как отключает просмотр всех файлов для агента. Но, похоже, работает хорошо.

Скрипт оболочки клиента vpn, представленный ниже, объединяет все функции (обновлен, чтобы включить этот дополнительный хак). chattrбольше не используется / нужен.

Обновление 3: исправлены настройки имени пользователя / пароля в скрипте. Теперь он использует vpn.confфайл с форматом, описанным ниже (и правами только для 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

Моя компания до сих пор использует этот VPN. Клиент vpnc просто меняет настройки iptables таким образом:

# iptables-save
# Сгенерировано iptables-save v1.4.10 в Вс 17 июня 14:12:20 2012
*фильтр
: INPUT DROP [0: 0]
: ВПЕРЕД ПРИНЯТЬ [0: 0]
: OUTPUT DROP [0: 0]
-A ВВОД -s 123.244.255.254/32 -d 192.168.0.14/32 -j ПРИНЯТЬ 
-A ВХОД -i tun0 -j ПРИНЯТЬ 
-A ВВОД -i lo0 -j ПРИНЯТЬ
-A INPUT -j DROP 
-A ВЫХОД -s 192.168.0.14/32 -d 123.244.255.254/32 -j ПРИНЯТЬ 
-A ВЫХОД -o tun0 -j ПРИНЯТЬ 
-A ВЫХОД -o lo0 -j ПРИНЯТЬ 
-A ВЫХОД -j DROP 
COMMIT

Он фильтрует все, кроме трафика VPN.

Просто добавьте фильтр в файл с помощью iptables-save, добавьте строки доступа INPUT и OUTPOUT, соответствующие вашим потребностям, и повторно примените файл с помощью iptables-restore.

например, для доступа к локальной сети на 192.168.0

# Сгенерировано iptables-save v1.4.10 в Вс 17 июня 14:12:20 2012
*фильтр
: INPUT DROP [0: 0]
: ВПЕРЕД ПРИНЯТЬ [0: 0]
: OUTPUT DROP [0: 0]
-A ВВОД -s 123.244.255.254/32 -d 192.168.0.14/32 -j ПРИНЯТЬ 
-A INPUT -s 192.168.0.0/24 -d 192.168.0.14/32 -j ПРИНЯТЬ #local in
-A ВХОД -i tun0 -j ПРИНЯТЬ 
-A ВВОД -i lo0 -j ПРИНЯТЬ 
-A INPUT -j DROP 
-A ВЫХОД -s 192.168.0.14/32 -d 123.244.255.254/32 -j ПРИНЯТЬ 
-A ВЫХОД -s 192.168.0.14/32 -d 192.168.0.0/24 -j ПРИНЯТЬ #local out
-A ВЫХОД -o tun0 -j ПРИНЯТЬ 
-A ВЫХОД -o lo0 -j ПРИНЯТЬ 
-A ВЫХОД -j DROP 
COMMIT

Есть новости по этому поводу?

На каком уровне драйвер клиента Cisco VPN делает то, что в сетевом стеке, которое принимает, переопределяет способность локального администратора управлять своей машиной?

Я полностью согласен и задавался вопросом об одном и том же.

В любом случае, это приложение, для установки которого требуются права администратора, и во время работы оно может очень хорошо фильтровать то, что вы делаете ...

Мои попытки на Windows тоже терпят неудачу:

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

Ха-ха. Нет метрики ниже 20 здесь, кажется.

Я не знаю, правильно ли я понял, но сначала я уточню свое понимание:

У вас есть локальная локальная сеть (например, 10.0.0.0/16, и удаленный сервер Cisco VPN (например, 64.0.0.0/16). Вы хотите подключиться к серверу VPN через клиент Cisco VPN, и все же вам нужно чтобы иметь доступ к локальной сети. В этом случае вы хотите отделить все 10.0.xx / 16 от VPN-подключения). В клиенте Mac должен быть добавлен следующий маршрут:

/sbin/route add -net 10.0 -interface en1

где en1 - интерфейс, через который вы подключены к локальной сети. Я знаю, что вы можете добавить то же самое в Windows и Linux.

Поскольку я не могу добавлять комментарии, я опубликую здесь. Я работаю на Windows.

Решение, использующее виртуальную машину и запускающее AnyConnect внутри виртуальной машины, а затем использующее виртуальную машину в качестве посредника между вашей рабочей средой и сетью компании, не будет работать, если ваш «любимый» ИТ-отдел маршрутизирует 0.0.0.0 через VPN, то есть даже в вашу локальную сеть (включая эту). между вашим локальным ПК и виртуальной машиной) маршрутизируется через VPN (так!).

Я попытался применить решение, опубликованное @Sasha Pachev, но в итоге я исправил .dll так, что он возвращает 0 в начале функции. В конце концов, после некоторой борьбы с динамической библиотекой, я смог изменить таблицы маршрутизации в соответствии со своими потребностями, но, видимо, этого недостаточно!

Несмотря на то, что мои правила кажутся правильными для достижения разделенного туннелирования, я все равно получаю общий отказ. Сталкивались ли вы с подобной проблемой, как смогли ее решить?

• Мой шлюз в интернет 192.168.163.2
• Мой выход в сеть компании является 10.64.202.1 (таким образом , вся 10. . . * Подсеть Лечу , как «Comapny в»)

Вот так теперь выглядит моя таблица маршрутизации (после ручных изменений при включенном VPN)

пока результат пинга следующий

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.

Просто для справки, ниже, как выглядит таблица маршрутов, когда VPN отключен (без изменений)

и вот так выглядит таблица, когда VPN подключена (не изменена) в том случае, когда я пытаюсь пропинговать, 8.8.8.8я просто получаю тайм-аут (поскольку брандмауэр компании не позволяет трафику выходить за пределы интрасети)

Для тех, кто хочет сохранить контроль над своей таблицей маршрутизации при использовании SSL AnyConnect SSL VPN, проверьте OpenConnect . Он поддерживает Cisco AnyConnect SSL VPN и не пытается нарушать или «защищать» записи таблицы маршрутизации. @Vadzim ссылается на это в комментарии выше .

Попробовав все, кроме исправления клиента AnyConnect Secure Mobility, я смог успешно заменить его в Windows на OpenConnect GUI . Это позволило мне поддерживать подключение к локальным ресурсам (и обновлять таблицу маршрутизации).

Я использую OpenConnect в Windows, но он также поддерживает Linux, BSD и macOS (среди других платформ) в соответствии со страницей проекта .

Попробуйте удалить эти записи с помощью шлюза, 10.64.202.13посмотрите, 8.8.8.8работает ли ping, затем добавьте их один за другим и определите, какая из них вызывает проблему.

Как вы исправили DLL. Я даже не могу изменить таблицу маршрутизации, потому что она продолжает добавлять 0.0.0.0шлюз с VPN обратно.