Часть первая. Вводная
Часть вторая. Настройка правил Firewall и NAT
Часть третья. Настройка DHCP
Часть четвертая. Настройка маршрутизации
Часть пятая. Настройка балансировщика нагрузки

Сегодня мы посмотрим на возможности настройки VPN, которые предлагает нам NSX Edge.

В целом мы можем разделить VPN-технологии на два ключевых вида:

  • Site-to-site VPN. Чаще всего используется IPSec для создания защищенного туннеля, например, между сетью главного офиса и сетью на удаленной площадке или в облаке.
  • Remote Access VPN. Используется для подключения отдельных пользователей к частным сетям организаций с помощью ПО VPN-клиента.

NSX Edge позволяет нам использовать оба варианта.
Настройку будем производить с помощью тестового стенда с двумя NSX Edge, Linux-сервера с установленным демоном racoon и ноутбука с Windows для тестирования Remote Access VPN.

IPsec


  1. В интерфейсе vCloud Director переходим в раздел Administration и выделяем vDC. На вкладке Edge Gateways выбираем нужный нам Edge, кликаем правой кнопкой и выбираем Edge Gateway Services.
  2. В интерфейсе NSX Edge переходим во вкладку VPN-IPsec VPN, далее – в раздел IPsec VPN Sites и жмем +, чтобы добавить новую площадку.

  3. Заполняем необходимые поля:
    • Enabled – активирует удаленную площадку.
    • PFS – гарантирует, что каждый новый криптографический ключ не связан с любым предыдущим ключом.
    • Local ID и Local Endpoint – внешний адрес NSX Edge.
    • Local Subnets – локальные сети, которые будут использовать IPsec VPN.
    • Peer ID и Peer Endpoint – адрес удаленной площадки.
    • Peer Subnets – сети, которые будут использовать IPsec VPN на удаленной стороне.
    • Encryption Algorithm – алгоритм шифрования туннеля.



    • Authentication – как мы будем аутентифицировать пир. Можно использовать Pre-Shared Key либо сертификат.
    • Pre-Shared Key – указываем ключ, который будет использоваться для аутентификации и должен совпадать с обеих сторон.
    • Diffie-Hellman Group – алгоритм обмена ключами.

    После заполнения необходимых полей нажимаем Keep.

  4. Готово.

  5. После добавления площадки переходим на вкладку Activation Status и активируем IPsec Service.

  6. После того, как настройки будут применены, переходим во вкладку Statistics —> IPsec VPN и проверяем статус туннеля. Видим, что туннель поднялся.

  7. Проверим статус туннеля из консоли Edge gateway:
    • show service ipsec – проверка состояния сервиса.

    • show service ipsec site – информация о состоянии сайта и согласованных параметрах.

    • show service ipsec sa – проверка статуса Security Association (SA).

  8. Проверка связности с удаленной площадкой:

    root@racoon:~# ifconfig eth0:1 | grep inet
            inet 10.255.255.1  netmask 255.255.255.0  broadcast 0.0.0.0
    
    root@racoon:~# ping -c1 -I 10.255.255.1 192.168.0.10 
    PING 192.168.0.10 (192.168.0.10) from 10.255.255.1 : 56(84) bytes of data.
    64 bytes from 192.168.0.10: icmp_seq=1 ttl=63 time=59.9 ms
    
    --- 192.168.0.10 ping statistics ---
    1 packets transmitted, 1 received, 0% packet loss, time 0ms
    rtt min/avg/max/mdev = 59.941/59.941/59.941/0.000 ms
    

    Конфигурационные файлы и дополнительные команды для диагностики со стороны удаленного Linux-сервера:
    root@racoon:~# cat /etc/racoon/racoon.conf 
    
    log debug;
    path pre_shared_key "/etc/racoon/psk.txt";
    path certificate "/etc/racoon/certs";
    
    listen {
      isakmp 80.211.43.73 [500];
       strict_address;
    }
    
    remote 185.148.83.16 {
            exchange_mode main,aggressive;
            proposal {
                     encryption_algorithm aes256;
                     hash_algorithm sha1;
                     authentication_method pre_shared_key;
                     dh_group modp1536;
             }
             generate_policy on;
    }
     
    sainfo address 10.255.255.0/24 any address 192.168.0.0/24 any {
             encryption_algorithm aes256;
             authentication_algorithm hmac_sha1;
             compression_algorithm deflate;
    }
    
    ===
    
    root@racoon:~# cat /etc/racoon/psk.txt
    185.148.83.16 testkey
    
    ===
    
    root@racoon:~# cat /etc/ipsec-tools.conf 
    #!/usr/sbin/setkey -f
    
    flush;
    spdflush;
    
    spdadd 192.168.0.0/24 10.255.255.0/24 any -P in ipsec
          esp/tunnel/185.148.83.16-80.211.43.73/require;
    
    spdadd 10.255.255.0/24 192.168.0.0/24 any -P out ipsec
          esp/tunnel/80.211.43.73-185.148.83.16/require;
    
    ===
    
    
    root@racoon:~# racoonctl show-sa isakmp
    Destination            Cookies                           Created
    185.148.83.16.500      2088977aceb1b512:a4c470cb8f9d57e9 2019-05-22 13:46:13 
    
    ===
    
    root@racoon:~# racoonctl show-sa esp
    80.211.43.73 185.148.83.16 
            esp mode=tunnel spi=1646662778(0x6226147a) reqid=0(0x00000000)
            E: aes-cbc  00064df4 454d14bc 9444b428 00e2296e c7bb1e03 06937597 1e522ce0 641e704d
            A: hmac-sha1  aa9e7cd7 51653621 67b3b2e9 64818de5 df848792
            seq=0x00000000 replay=4 flags=0x00000000 state=mature 
            created: May 22 13:46:13 2019   current: May 22 14:07:43 2019
            diff: 1290(s)   hard: 3600(s)   soft: 2880(s)
            last: May 22 13:46:13 2019      hard: 0(s)      soft: 0(s)
            current: 72240(bytes)   hard: 0(bytes)  soft: 0(bytes)
            allocated: 860  hard: 0 soft: 0
            sadb_seq=1 pid=7739 refcnt=0
    185.148.83.16 80.211.43.73 
            esp mode=tunnel spi=88535449(0x0546f199) reqid=0(0x00000000)
            E: aes-cbc  c812505a 9c30515e 9edc8c4a b3393125 ade4c320 9bde04f0 94e7ba9d 28e61044
            A: hmac-sha1  cd9d6f6e 06dbcd6d da4d14f8 6d1a6239 38589878
            seq=0x00000000 replay=4 flags=0x00000000 state=mature 
            created: May 22 13:46:13 2019   current: May 22 14:07:43 2019
            diff: 1290(s)   hard: 3600(s)   soft: 2880(s)
            last: May 22 13:46:13 2019      hard: 0(s)      soft: 0(s)
            current: 72240(bytes)   hard: 0(bytes)  soft: 0(bytes)
            allocated: 860  hard: 0 soft: 0
            sadb_seq=0 pid=7739 refcnt=0

  9. Все готово, site-to-site IPsec VPN настроен и работает.

    В этом примере мы использовали PSK для аутентификации пира, но возможен также вариант с аутентификацией по сертификатам. Для этого нужно перейти во вкладку Global Configuration, включить аутентификацию по сертификатам и выбрать сам сертификат.

    Кроме того, в настройках сайта необходимо будет поменять метод аутентификации.





    Отмечу, что количество IPsec-туннелей зависит от размера развернутого Edge Gateway (об этом читайте в нашей первой статье).


SSL VPN


SSL VPN-Plus – один из вариантов Remote Access VPN. Он позволяет отдельным удаленным пользователям безопасно подключаться к частным сетям, находящимся за шлюзом NSX Edge. Зашифрованный туннель в случае SSL VPN-plus устанавливается между клиентом (Windows, Linux, Mac) и NSX Edge.

  1. Приступим к настройке. В панели управления сервисами Edge Gateway переходим во вкладку SSL VPN-Plus, затем к Server Settings. Выбираем адрес и порт, на котором сервер будет слушать входящие соединения, включаем логирование и выбираем необходимые алгоритмы шифрования.



    Здесь же можно изменить сертификат, который будет использовать сервер.

  2. После того как все готово, включаем сервер и не забываем сохранить настройки.

  3. Далее нам необходимо настроить пул адресов, которые мы будем выдавать клиентам при подключении. Эта сеть отделена от любой существующей подсети в вашей среде NSX, ее не нужно настраивать на других устройствах в физических сетях, за исключением маршрутов, которые на нее указывают.

    Переходим во вкладку IP Pools и жмем +.

  4. Выбираем адреса, маску подсети и шлюз. Здесь же можно изменить настройки для DNS и WINS серверов.

  5. Получившийся пул.

  6. Теперь добавим сети, доступ к которым будет у подключающихся к VPN пользователей. Перейдем во вкладку Private Networks и нажмем +.

  7. Заполняем:

    • Network — локальная сеть, к которой будет доступ у удаленных пользователей.
    • Send traffic, у него два варианта:
      — over tunnel – отправлять трафик к сети через туннель,
      — bypass tunnel – отправлять трафик к сети напрямую в обход туннеля.
    • Enable TCP Optimization – отмечаем, если выбрали вариант over tunnel. Когда оптимизация включена, можно указать номера портов, для которых необходимо оптимизировать трафик. Трафик для оставшихся портов этой конкретной сети не будет оптимизирован. Если номера портов не указаны, трафик для всех портов оптимизируется. Подробнее об этой функции читайте здесь.

  8. Далее переходим на вкладку Authentication и жмем +. Для аутентификации будем использовать локальный сервер на самом NSX Edge.

  9. Здесь мы можем выбрать политики для генерирования новых паролей и настроить опции по блокировке пользовательских аккаунтов (например, количество повторных попыток при неправильном вводе пароля).



  10. Так как мы используем локальную аутентификацию, необходимо создать пользователей.

  11. Помимо базовых вещей вроде имени и пароля, здесь можно, например, запретить пользователю изменять пароль или, наоборот, заставить его поменять пароль при следующем входе.

  12. После того, как все необходимые пользователи добавлены, перейдем на вкладку Installation Packages, нажмем + и создадим сам инсталлятор, который скачает для установки удаленный сотрудник.

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



    Ниже в этом окне можно указать параметры клиента для Windows. Выбираем:

    • start client on logon – VPN-клиент будет добавлен в автозагрузку на удаленной машине;
    • create desktop icon – создаст иконку VPN-клиента на рабочем столе;
    • server security certificate validation – будет валидировать сертификат сервера при подключении.
      Настройка сервера завершена.

  14. Теперь скачаем созданный нами в последнем шаге установочный пакет на удаленный ПК. При настройке сервера мы указывали его внешний адрес (185.148.83.16) и порт (445). Именно по этому адресу нам необходимо перейти в веб-браузере. В моем случае это 185.148.83.16:445.

    В окне авторизации необходимо ввести учетные данные пользователя, которого мы создали ранее.

  15. После авторизации перед нами появляется список созданных установочных пакетов, доступных для загрузки. Мы создали только один – его и скачаем.

  16. Кликаем по ссылке, начинается скачивание клиента.

  17. Распаковываем скачанный архив и запускаем инсталлятор.

  18. После установки запускаем клиент, в окне авторизации нажимаем Login.

  19. В окне проверки сертификата выбираем Yes.

  20. Вводим учетные данные для ранее созданного пользователя и видим, что подключение завершено успешно.



  21. Проверяем статистику VPN-клиента на локальном компьютере.



  22. В командной строке Windows (ipconfig /all) видим, что появился дополнительный виртуальный адаптер и связность с удаленной сетью есть, все работает:



  23. И напоследок – проверка из консоли Edge Gateway.


L2 VPN


L2VPN понадобится в том случае, когда нужно объединить несколько географически
распределенных сетей в один broadcast-домен.

Это может быть полезно, например, при миграции виртуальной машины: при переезде ВМ на другую географическую площадку машина сохранит настройки IP-адресации и не потеряет связность с другими машинами, находящимися в одном L2-домене с ней.

В нашей тестовой среде соединим друг с другом две площадки, назовем их, соответственно, A и B. У нас есть два NSX и две одинаково созданные маршрутизируемые сети, привязанные к разным Edge. Машина A имеет адрес 10.10.10.250/24, машина B – 10.10.10.2/24.

  1. В vCloud Director переходим на вкладку Administration, заходим в нужный нам VDC, переходим на вкладку Org VDC Networks и добавляем две новые сети.

  2. Выбираем тип сети routed и привязываем эту сеть к нашему NSX. Ставим чекбокс Create as subinterface.

  3. В итоге у нас должно получиться две сети. В нашем примере они называются network-a и network-b с одинаковыми настройками gateway и одинаковой маской.



  4. Теперь перейдем в настройки первого NSX. Это будет NSX, к которому привязана сеть A. Он будет выступать в качестве сервера.

    Возвращаемся в интерфейс NSx Edge/ Переходим на вкладку VPN —> L2VPN. Включаем L2VPN, выбираем режим работы Server, в настройках Server Global указываем внешний IP-адрес NSX, на котором будет слушаться порт для туннеля. По умолчанию, сокет откроется на 443 порту, но его можно поменять. Не забываем выбрать настройки шифрования для будущего туннеля.

  5. Переходим во вкладку Server Sites и добавляем пир.

  6. Включаем пир, задаем имя, описание, если нужно, задаем имя пользователя и пароль. Эти данные нам понадобятся позже при настройке клиентского сайта.

    В Egress Optimization Gateway Address задаем адрес шлюза. Это нужно для того, чтобы не происходил конфликт IP-адресов, ведь шлюз у наших сетей имеет один и тот же адрес. После чего нажимаем на кнопку SELECT SUB-INTERFACES.

  7. Здесь выбираем нужный сабинтерфейс. Сохраняем настройки.

  8. Видим, что в настройках появился только что созданный клиентский сайт.

  9. Теперь перейдем к настройке NSX со стороны клиента.

    Заходим на NSX стороны B, переходим в VPN —> L2VPN, включаем L2VPN, устанавливаем L2VPN mode в клиентский режим работы. На вкладке Client Global задаем адрес и порт NSX A, который мы указывали ранее как Listening IP и Port на серверной стороне. Также необходимо выставить одинаковые настройки шифрования, чтобы они согласовались при поднятии туннеля.



    Проматываем ниже, выбираем сабинтерфейс, через который будет строиться туннель для L2VPN.
    В Egress Optimization Gateway Address задаем адрес шлюза. Задаем user-id и пароль. Выбираем сабинтерфейс и не забываем сохранить настройки.

  10. Собственно, это все. Настройки клиентской и серверной стороны практически идентичны, за исключением нескольких нюансов.
  11. Теперь можем посмотреть, что наш туннель заработал, перейдя в Statistics —> L2VPN на любом NSX.

  12. Если сейчас зайдем в консоль любого Edge Gateway, то увидим на каждом из них в arp-таблице адреса обеих VM.



На этом про VPN на NSX Edge у меня все. Спрашивайте, если что-то осталось непонятным. Также это последняя часть из серии статей по работе с NSX Edge. Надеемся, они были полезны :)

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


  1. amarao
    30.05.2019 10:43

    А почему вы предлагаете доверять кривому самодельному SSL-сертификату, у которого даже имя не совпадает с именем сервера, вместо использования let's encrypt?


    1. dataline Автор
      30.05.2019 11:13

      Мы не предлагаем)
      Это тестовая среда, и цель данной статьи — показать возможности NSX в части настройки VPN'ов. Поэтому мы использовали самоподписанный сертификат, который сгенерировали прямо на эдже.
      Так-то вы правы, в продуктиве нужно использовать нормальный сертификат, тот же let's encrypt.


      1. amarao
        30.05.2019 11:15

        А вот вопрос-то интеграции с let's encrypt и не показан… certbot и всё такое.


    1. eugene-p
      30.05.2019 14:33

      от того что имя не совпадает, трафик меньше шифроваться не станет


      1. amarao
        30.05.2019 16:59

        Да ладно! Простейший mitm-прокси, который каждому из участников показывает недоверенный неверный сертификат, а сам не только читает, но и пишет на своё усмотрение.


        Смысл шифрования, если вы не знаете, кто вам трафик шифрует?