Архив рубрики: UNIX

Route-based IPSEC VPN между Ubuntu 18.04 (libreswan) и Cisco Router. Часть 2

В этой статье (часть первую можно прочитать здесь) я опишу процесс настройки Cisco роутера на примере Cisco ISR 4331 для целей создания нашего VPN-соединения. Как мы помним, конечная цель настройки — отправлять интересующий нас трафик через VPN-туннель.

Для примера, я опишу настройку Cisco для отправки всего трафика к определенным серверам через туннель (например, для обхода блокировок по стране). Начнем с создания object-group — так в дальнейшем будет проще добавлять новые адреса назначения и сразу добавим туда адрес сервера, к которому надо ходить через туннель:

object-group network TOVPN
 host 3.3.3.3

Далее создаем ip access-list, которым мы будем ловить интересующий нас трафик:

ip access-list extended TOVPN
 permit ip any object-group TOVPN

Переходим к непосредственной настройке VPN:

crypto keyring VPN
 pre-shared-key address 11.11.11.11 key %908A2R5vX9O694aoxh1

crypto isakmp profile VPN
 keyring VPN
 match identity address 11.11.11.11 255.255.255.255

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac
 mode tunnel

crypto ipsec profile VPN
 set transform-set ESP-AES256-SHA1

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

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

Далее необходимо создать виртуальный интерфейс, через который мы будем делать туннель.

interface Tunnel0
 ip address 172.16.0.21 255.255.255.252
 tunnel source 22.22.22.22
 tunnel mode ipsec ipv4
 tunnel destination 11.11.11.11
 tunnel protection ipsec profile VPN
 ip tcp adjust-mss 1300

Для корректной передачи данных по туннелю, чтобы в стандартный MTU пролазил пакет с «оберткой IPSEC» — нам необходимо ограничить размер MTU на интерфейсе. Делается это командой ip tcp adjust-mss MTU. В данном примере установлен MTU — 1300. Число 1300 не подбиралось экспериментальным путем, а было установлено таким, чтобы точно подходило в любых конфигурациях. На самом деле, вам, скорее всего, достаточно будет указать 1376. Если этого не сделать — обратный трафик будет проходить «частично». Если быть более точным — другой конец нашего туннеля при получении «ответных» пакетов (на наш трафик через туннель) «нормального» размера (т.е. 1476 байт) не сможет отправить их через туннель из-за превышения размера MTU. При этом мелкие пакеты будут бегать туда-сюда без особых проблем. Например, пинг и трэйсроут будут показывать наличие связи, а странички из интернета грузиться не будут.

Итак, туннель поднят, осталось отправить в него трафик. Для этого задействуем route-map:

route-map LOCAL permit 10
 match ip address TOVPN
 set interface Tunnel0

Не забываем применить этот route map к интерфейсу, к которому подключена локальная сеть.

Если все сделано по инструкции, но туннель не поднялся, проверяем:
— разрешен ли доступ снаружи к маршрутизатору по протоколам udp и gre;
— разрешен ли маршрутизатору доступ в сеть по протоколам udp и gre;

Если туннель поднялся, но трафик в него не ходит (или обратно не приходит):
— пробуем сделать ipsec restart на сервере с ubuntu;
— проверяем правила доступа с интерфейса Tunnel0 и на него (выбрана ли правильная зона для ZBFW при его использовании).

Подключение к VirtualBox через VNC

Когда-то давно к консоли виртуальной машины VirtualBox можно было легко и просто подключаться по VNC. Но с недавних времен, решением по умолчанию стало подключение по RDP. Сделано это было, наверняка, из лучших побуждений и соображений безопасности, но в один прекрасный момент, благодаря этому, сотни и тысячи мануалов в интернете по разворачиванию виртуальных машин через консоль утратили свою актуальность. После создания виртуальной машины по этим инструкциям вам не удастся подключиться к ним через VNC.

Но разработчики, все же, оставили возможность подключиться по VNC. Для этого необходимо выполнить в консоли:

 VBoxManage setproperty vrdeextpack VNC 

Эта настройка меняет способ подключения к виртуальным машинам для всего сервера на VNC.

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

 VBoxManage modifyvm "VM name" --vrdeproperty VNCPassword=secret

После этого вы сможете подключаться к своей машине через VNC, как и раньше. Если вам потребуется вернуться на настройку по умолчанию (с использованием RDP), выполните следующую команду:

 VBoxManage setproperty vrdeextpack "Oracle VM VirtualBox Extension Pack"

Аналог IncludeOptional в веб-сервере nginx

Современные панели управления для веб-серверов, призванные облегчить администрирование оных (либо используемые в целях продажи виртуального хостинга) все еще не позволяют гибко настраивать nginx для каждого аккаунта через веб-интерфейс. Оно и понятно. Возможных настроек существует просто огромное количество и делать для всего этого веб-интерфейс ради каких-то 0,5% пользователей, которым не хватает стандартных настроек — бессмысленно. В качестве лайфхака некоторые панели позволяют администраторам серверов вписывать для конкретных хостов настройки в отдельные файлы, которые обычно остаются пустыми, но при этом все равно создаются в файловой системе. Что делать, если кастомные настройки нужны, а плодить пустые файлы не хочется?

В веб-сервере Apache для этого существовала специальная директива IncludeOptional, которая попросту игнорировалась в случае, если такого файла не было в файловой системе, либо если использовались маски для файлов и ни один файл не попал под маску.

К счастью, разработчики веб-сервера nginx поступили дальновиднее и просто позволили включать директивой include файлы с маской. При этом, естественно, никаких ошибок при отсутствии файлов, попавших под маску тоже не генерируется. Но что делать, если вы хотите включить конкретный файл и не хотите «случайного» включения туда «левого» файла по маске? Использовать небольшую хитрость — задать имя файла в виде include /usr/local/etc/nginx/optional_config_file.con[f]. Т.е. мы якобы задаем маску, но под эту маску попадает только один файл. При этом, в случае отсутствия файла никаких ошибок не появится.

Route-based IPSEC VPN между Ubuntu 18.04 (libreswan) и Cisco Router

В корпоративном секторе, особенно в больших компаниях с более, чем одним офисом зачастую возникает необходимо в site-to-site VPN-соединениях. Конечно, большинство провайдеров предлагает вам «прямую связь» через их оборудование. Но как-то так сложилось, что надежность этого решения зависит только от самого провайдера и из-за некорректных действий одного-единственного админа может зависеть целостность вашей сети. Такие объединения сетей частенько выполняются просто на уровне отдельного тегированного VLAN. И если кто-то внезапно (вполне может быть по неосторожности) скрестит вашу сеть с другими или просто снимет теги на портах — вы рискуете получить в свою сеть трафик от многих клиентов провайдера, а они, в свою очередь, получат беспрепятственный доступ в вашу сеть. Именно по этой причине доверять стоит только собственноручно поднятому IPSEC VPN. Если что-то пойдет не так — VPN просто развалится и сети будут изолированы друг от друга.

В каких случаях Route-based VPN удобнее, чем обычный site-to-site? Например, если вы хотите предоставить N хостам из одной сети доступ к ресурсам в другой сети, но создавать для этого клиентские соединения неудобно. Также, если у вас много подсетей с одной из сторон (или с обеих) и вы не хотите плодить IPSEC SA (как произойдет в случае обычного Policy-based IPSEC VPN). Или, например, вы хотите пробросить весь трафик нескольких клиентов через роутер в другой стране. Во всех этих случаях полезно и удобно будет использовать Route-based VPN.

Итак, начнем с оборудования. В моем случае это был Cisco Router серии ASR с одной стороны и сервер с Ubuntu 18.04 с другой. Цель — пустить трафик N клиентов в интернет через удаленный сервер. Начнем с Ubuntu:

  1.  Установим libreswan.
    apt-get install libreswan
  2. Разрешим форвардинг пакетов и отключим редиректы.
    echo "net.ipv4.ip_forward = 1" | tee -a /etc/sysctl.conf
    echo "net.ipv4.conf.all.accept_redirects = 0" | tee -a /etc/sysctl.conf
    echo "net.ipv4.conf.all.send_redirects = 0" | tee -a /etc/sysctl.conf
    for vpn in /proc/sys/net/ipv4/conf/*; do echo 0 > $vpn/accept_redirects; echo 0 > $vpn/send_redirects; done
  3. Применим настройки.
    sysctl -p
  4. Создадим в /etc/ipsec.d/ файл с конфигурацией нашего VPN и поместим в него следующий контент:
    nano /etc/ipsec.d/route-based-ipsec-vpn.conf
    
    config setup
        protostack=netkey
    conn vpn
        authby=secret
        pfs=no
        rekey=yes
        keyingtries=3
        type=tunnel
        auto=start
        ike=aes256-sha1;modp1536
        phase2alg=aes256-sha1;modp1536
        left=11.11.11.11
        right=22.22.22.22
        leftsubnet=0.0.0.0/0
        rightsubnet=0.0.0.0/0
        mark=5/0xffffffff
        vti-interface=vti01
        vti-routing=no

    Если один из ваших роутеров находится за NAT (например left), вам необходимо заменить в директиве left адрес на внутренний адрес интерфейса (left=10.0.0.1) и добавить директиву leftid с реальным адресом (leftid=11.11.11.11).  И, конечно, пробросить порты UDP 500, 1701 и 4500 на этот роутер. В противном случае туннель не поднимется.

    Краткие пояснения по конфигурационному файлу:
    authby=secret — авторизация по паролю, а не по сертификатам;
    vti-interface=vti01 — интерфейс, который будет создан автоматически при создании туннеля;
    vti-routing=no — не создавать маршруты на интерфейс туннеля автоматически.

  5. Далее необходимо придумать сгенерировать стойкий пароль на много символов (все равно вам его запоминать не надо) и внести его в файл.
    nano /etc/ipsec.d/route-based-ipsec-vpn.secrets
    
    11.11.11.11 22.22.22.22: PSK "%908A2R5vX9O694aoxh1"
  6. Делаем ipsec restart и ipsec verify. После ipsec verify у нас должно появиться что-то типа этого:
    Verifying installed system and configuration files
    
    Version check and ipsec on-path                         [OK]
    Libreswan 3.23 (netkey) on 4.15.0-1021-aws
    Checking for IPsec support in kernel                    [OK]
     NETKEY: Testing XFRM related proc values
             ICMP default/send_redirects                    [OK]
             ICMP default/accept_redirects                  [OK]
             XFRM larval drop                               [OK]
    Pluto ipsec.conf syntax                                 [OK]
    Two or more interfaces found, checking IP forwarding    [OK]
    Checking rp_filter                                      [ENABLED]
     /proc/sys/net/ipv4/conf/all/rp_filter                  [ENABLED]
     /proc/sys/net/ipv4/conf/default/rp_filter              [ENABLED]
     /proc/sys/net/ipv4/conf/eth0/rp_filter                 [ENABLED]
     /proc/sys/net/ipv4/conf/ip_vti0/rp_filter              [ENABLED]
      rp_filter is not fully aware of IPsec and should be disabled
    Checking that pluto is running                          [OK]
     Pluto listening for IKE on udp 500                     [OK]
     Pluto listening for IKE/NAT-T on udp 4500              [OK]
     Pluto ipsec.secret syntax                              [OK]
    Checking 'ip' command                                   [OK]
    Checking 'iptables' command                             [OK]
    Checking 'prelink' command does not interfere with FIPS [OK]
    Checking for obsolete ipsec.conf options                [OK]
    

    Если failed нигде не написано — можно жить.

  7. Заставляем трафик прятаться за айпишник нашего интерфейса при выходе наружу (в данном примере внешний интерфейс — eth0) при помощи iptables:
    iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
  8. Прописываем маршруты в нашу удаленную сеть (предположим, что на другом конце есть сети 192.168.0.0/24 и 192.168.10.0/24).
    ip route add 192.168.0.0/24 dev vti01
    ip route add 192.168.10.0/24 dev vti01
  9. На этом этапе настройка Ubuntu закончена и мы переходим к настройке Cisco ASR. Продолжение следует (линк на него будет в конце этой статьи).

При написании этого материала помог личный опыт, статья https://libreswan.org/wiki/Route-based_VPN_using_VTI и гугл.

UPD: Для автоматического прописывания маршрутов можно воспользоваться конфигурацией netplan. Для этого необходимо внести изменения в файл /etc/netplan/50-cloud-init.yaml:

        vti01:
dhcp4: no
addresses: [172.16.0.22/30]
routes:
- to: 192.168.0.0/24
via: 172.16.0.22
- to: 192.168.10.0/24
via: 172.16.0.22

Не забудьте применить изменения командой netplan apply

В этом случае интерфейсу vti01 назначается ip-адрес и через него прописываются маршруты в наши подсети.

Вторая часть статьи с настройкой туннеля ждет вас здесь: https://kulmaks.by/route-based-ipsec-vpn-%d0%bc%d0%b5%d0%b6%d0%b4%d1%83-ubuntu-18-04-libreswan-%d0%b8-cisco-router-%d1%87%d0%b0%d1%81%d1%82%d1%8c-2/

Логирование всех запросов к mysql

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

Для этого необходимо подключиться к нашему серверу и:

  1. Создать файл лога и выдать на него права для пользователя, под которым работает mysql.
  2. Подключиться к mysql-серверу с правами root и выполнить:
    SET GLOBAL log_output = "FILE";
    
    SET GLOBAL general_log_file = "/path/to/your/logfile.log";
    
    SET GLOBAL general_log = 'ON';
  3. С этого момента в лог попадают абсолютно все запросы. Проверяем необходимый нам функционал.
  4. Если сервер довольно загружен — не забываем сразу выключить логирование:
    SET GLOBAL general_log = 'OFF';
  5. Открываем лог-файл и ищем там наши запросы.