Многие компании переходят на использование облачных сервисов в своем бизнесе по всему миру, это и офисные приложения, сервисы BigData, чат/видео/аудио коммуникация с целью проведения митингов/обучения и многие другие. Однако ввиду массового перевода на удаленную работу сотрудников так или иначе требуется получать доступ к корпоративной сети (если конечно заказчик не полностью работает на облачной платформе), для того чтобы сделать доступ безопасным, как правило, используются сервисы типа Remote-Access VPN.
Классически такие сервисы могут либо полностью направлять весь трафик удаленного клиента в VPN туннель, либо выборочно направлять или исключать из туннеля трафик основываясь на IPv4/IPv6 подсетях.


Многие безопасники решат что наиболее оптимальным было бы использовать опцию полного туннелирования (tunnelall) трафика для полного контроля за всем трафиком пользователя в момент подключения к корпоративной сети и отсутствием возможности параллельного вывода данных через неконтролируемое интернет-соединение. Однако есть и другая чаша весов...


  • Как организовать файлообмен Box/Dropbox/SharePoint напрямую в облако со скоростью домашнего канала интернет, минуя медленный корпоративный VPN?
  • Как организовать соединение Webex/Skype напрямую с абонентом, не проводя его через HQ VPN-шлюз, создавая задержки связи и снижая качество связи?
  • Как заставить только определенные облачные сервисы работать вне VPN туннеля, чтобы пользователь их использовал напрямую через домашний интернет и контролировать остальные не доверенные службы централизованно?
  • Как эффективно снизить нагрузку на VPN-шлюз не проводя через него трафик доверенных облачных приложений?

С началом массового использования удаленного доступа у многих заказчиков началась перегрузка VPN-шлюзов, которые не были рассчитаны на такую волну использования при их проектировании и любой дополнительный трафик от клиентов может запросто перегрузить возможности перегруженного VPN-шлюза, таким образом, компании начинают селективно подходить к вопросу выбора направляемых сервисов в VPN. С другой стороны направляя весь трафик приложений в VPN, мы:


  • Туннелируем трафик уже доверенных приложений (например Office365, Webex и т.д.)
  • Создаем порой критические задержки у клиента при общении через сервисы совместного общения (Webex, Skype, Jabber и т.д.) использующие аудио/видео потоки критичные к задержкам и потерям.

Таким образом мы нагружаем VPN шлюз совершенно не нужным трафиком в ущерб общей производительности шлюза и качеству работы приложений.


Нам хочется исключить данные сервисы из туннелирования VPN, но тут встает делемма:


  • множество облачных сервисов может хоститься на одном и том же IP адресе и не получается селективно выбрать один сервис по IP;
  • IP адреса хостинга могут меняться если даже не каждый день, то иногда и несколько раз за день;

Нужен более гибкий способ динамического исключения из туннеля трафика данных приложений и для решения этой проблемы я бы хотел рассказать о функции Dynamic Split Tunneling, доступной в том виде о котором я буду рассказывать, начиная с версии Cisco AnyConnect 4.6 и шлюзом VPN мы используем Cisco ASA.


Функция Dynamic Split Tunneling предоставляет возможность динамически как добавлять, так и исключать из VPN-туннелирования определенный трафик, основываясь на домене принадлежности.


Как это работает.


Вы настраиваете на стороне Cisco ASA список доменов для включения/исключения туннелирования и назначаете этот список как аттрибут AnyConnect на интересующую Вас Group-Policy. После соединения, VPN клиент скачивает данную настройку и при получении обращения на домен из списка резолвит его (получает соответственно список IP адресов на запрашиваемый домен) и динамически переписывает таблицу маршрутизации хоста для включения/исключения трафика в туннель.


Как это настраивается


Пример настройки AnyConnect VPN на Cisco ASA Вы можете прочитать в моей статье Развертывание ASA VPN Load-Balancing кластера


  1. Задаем атрибут AnyConnect, который будет использовать для исключения трафика:
    !
    ASA(config)# webvpn
    ASA(config-webvpn)# anyconnect-custom-attr dynamic-split-exclude-domains description dynamic-split-exclude-domains
    !
  2. Настраиваем списки доменов для нужного нам сценария фильтрации, я привел пример нескольких списков опираясь на документацию производителей для сервисов (MS Skype for Business, MS Exchange Online, MS Sharepoint Online, MS O365, Cisco AMP for Endpoints, Cisco Webex) (в одной Group-Policy можно использовать только один список! Один список не может превышать 510 символов):



    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains SKYPE skype.com, lync.com, teams.microsoft.com, skypeforbusiness.com
    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains EXCHANGE-ONLINE outlook.office.com, outlook.office365.com, smtp.office365.com, outlook.com, office.com
    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains SHAREPOINT-ONLINE sharepoint.com
    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains O365 online.office.com, officeapps.live.com, msappproxy.net, msftidentity.com, account.activedirectory.windowsazure.com, windows.net, microsoftonline.com, autologon.microsoftazuread-sso.com, microsoftonline-p.net, graph.microsoft.com, graph.windows.net, login.microsoft.com, login.windows.net, office.com, cloudappsecurity.com, admin.microsoft.com
    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains CISCO-AMP amp.cisco.com, amp.sourcefire.com, panacea.threatgrid.com, panacea.threatgrid.eu
    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains CISCO-WEBEX wbx2.com, webex.com, ciscospark.com, webexcontent.com, activate.cisco.com, webapps.cisco.com, accompany.com, huron-dev.com, sparkpostmail1.com, giphy.com, safebrowsing.googleapis.com, walkme.com, s3.walkmeusercontent.com, speech.googleapis.com, texttospeech.googleapis.com, crashlytics.com, eum-appdynamics.com, amplitiude.com, segment.com, segment.io
    !

    Я для примера буду использовать список для Webex, AMP и Skype


    !
    ASA(config)# anyconnect-custom-data dynamic-split-exclude-domains CLOUD-SERVICES webex.com, wbx2.com, webexcontent.com, amp.cisco.com, amp.sourcefire.com, panacea.threatgrid.com, panacea.threatgrid.eu, skype.com, lync.com, teams.microsoft.com, skypeforbusiness.com
    !

    Хочу отдельно отметить, что для сервисов, использующих динамические имена для доменов нижнего уровня, можно просто добавить в список домен верхнего уровня. К примеру, если в списке фигурирует webex.com, то и cisco.webex.com также подпадет в фильтр.


  3. Назначаем настроенный список на интересующую нас Group-Policy:
    !
    ASA(config)# group-policy ASHES-VPN attributes
    ASA(config-group-policy)# anyconnect-custom dynamic-split-exclude-domains value CLOUD-SERVICES
    !
  4. Соединяемся через VPN, клиент скачивает новую настройку и вуаля, мы аккуратно вывели облачные сервисы из под VPN!


    • Посмотрим как изменится таблица маршрутизации хоста после подключения VPN и попытки обращения к сервису в исключении:

      Посмотрим как отработает фильтр по домену верхнего уровня webex.com при запросе на cisco.webex.com:
    • Посмотрим как изменится трассировка для исключенного сервиса в сравнении с остальным, идущими в tunelall политику:


UPDATE: Коллеги совместно со специалистами Microsoft выпустили скрипт, который генерирует готовую конфигурацию для исключения из туннеля сервисов Webex и Office365, материал по ссылке.


Резюмируя хочется отдельно отметить, что за простые четыре (три) шага удаленные сотрудники используют Office365 напрямую из облака, Skype и Webex вызовы идут напрямую без задержек и Вы резко снизили нагрузку на VPN-шлюз исключив из туннеля доверенные облачные приложения. Помимо этого данная технология дает возможность и динамически включать туннелирование по тому же принципу, но об этом можно почитать в более подробной инструкции.


Всем крепкого здоровья!


P.S. На задержки не обращайте внимания, я сижу через спутниковый интернет на "удаленке" =)

Комментарии (1)