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

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 при его использовании).

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/

Не открывается web-интерфейс HP 1910. Свитч не пингуется.

Если у вас достаточно крупная сеть и вы используете коммутаторы HP 1910, то вы тоже могли столкнуться с такой проблемой: в определенные моменты времени вы просто не можете открыть админку коммутатора и даже пинговать его не можете. Но при этом, с других компьютеров/серверов он вполне может открываться и пинговаться. И более того, если вы будете долго и упорно его пинговать — вам он тоже начнет отвечать! Причины этой, на первый взгляд непонятной проблемы, очень просты: у свичей HP 1910 очень маленькая ARP-таблица — 256 записей. Со временем, при работе в сети >256 хостов, она может заполниться на 100% и может случиться так, что ваш адрес туда не попадет.

Как это лечить:

  1. Для начала, необходимо все же попасть на свитч с какого-нибудь адреса (например, с DHCP-сервера — чаще всего запись о нем есть в ARP-таблице).
  2. Заходим в ARP-management и удаляем все динамические записи.
  3. Добавляем там же необходимые нам статические записи (например, IP-адрес и MAC того компьютера/сервера, с которого чаще всего осуществляется доступ к свичам). Полезно будет также добавить IP и MAC шлюза по умолчанию — это защитит от внезапного появления в сети еще одного шлюза (но в этом случае лучше еще и статическую запись MAC с привязкой к порту сделать).

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

Обновление прошивки HP 1910 через COM-порт

Иногда на коммутаторах HP 1910 бьются файлы прошивок. Чаще всего это, по всей видимости, происходит из-за износа флэш-памяти и в таких случаях программно ему уже не помочь. Но бывают случаи, когда он «просто почему-то побился» и коммутатор можно оживить путем форматирования флэш-памяти и заливки новой прошивки.

Для форматирования флэшки необходимо подключиться консольным кабелем, настроить соединение (38400, 8, 1, N) и нажать при загрузке Ctrl+B. Таким образом мы попадем в BootWare-меню. В нем необходимо нажать Ctrl+F и согласиться с форматирование флэшки. Желательно перед этим убедиться в наличии у вас свежей прошивки в виде файла *.bin :)

Далее перезагружаем коммутатор и снова входим в BootWare. На этот раз он сделает это сам — прошивки-то нет. В Bootware выбираем пункт 2 «Enter Serial SubMenu». Т.к. файл прошивки весит более 10 Мб — лучше переключить Serial-интерфейс на скорость 115200. Для этого жмём и снова 5 (пункт 115200). И тут настает время задуматься над тем, каким именно образом мы будем слать на него файл. Далеко не всё ПО умеет слать файлы в COM-сессию. Putty, например, такого не делает. Для этого придется найти старенький, но так необходимый HyperTerminal (последний раз он входил в комплект Windows XP). В нем создаем новое подключение, выбираем параметры 115200, 8, None, 1, None (см. скриншот).

Далее жмем «ОК» и подключаемся. Выходим на один уровень выше (пункт 0). И выбираем пункт 2 — Update Main Application File. Коммутатор переходит в режим приема файла, а мы нажимаем «Transfer»->»Send File», выбираем в окошке прошивку коммутатора и протокол Xmodem:

Отдыхаем минут 40 и по окончанию передачи на запрос коммутатора выдаем имя файла. После этого выходим на основной уровень меню, File Control (4), Display All Files (1). Проверяем, чтобы напротив нашего файла прошивки стоял флаг М.

После этого выходим в главное меню и загружаемся (1). Если флэшка умерла не совсем — коммутатор загрузится и будет работать еще долго.

Загрузка cisco 4000 в ROMMON.

В процессе различных экспериментов с версиями прошивок cisco ISR 4000 может возникнуть ситуация, когда девайс перестает реагировать на ваши действия (в т.ч. в консоли). Т.е. он вполне себе отображает процесс загрузки, на него можно даже по ssh зайти… Правда, после входа по ssh не появляется стандартного приглашения командной строки. Что делать и как жить дальше?

Все довольно просто. Надо подключиться консольным кабелем к циске, выключить ее секунд на 30, открыть com-порт, например, в PuTTY, включить девайс. После появления первых строк текста в консоли — надо нажать Break и дождаться прерывания процесса загрузки с появлением приглашения ROMMON. Выглядит это примерно так:

Initializing Hardware ...

System integrity status: 00000610
Rom image verified correctly


System Bootstrap, Version 15.4(3r)S5, RELEASE SOFTWARE
Copyright (c) 1994-2015 by cisco Systems, Inc.

Current image running: Boot ROM0

Last reset cause: PowerOn
Cisco ISR4331/K9 platform with 4194304 Kbytes of main memory


no valid BOOT image found
Final autoboot attempt from default boot device...
Warning: filesystem is not clean
Warning: filesystem is not clean
File size is 0x1bcc9bfc


monitor: command "boot" aborted due to user interrupt


rommon 1 >

Если нажатие кнопки Break не помогает, можете воспользоваться соответствующей командой из меню PuTTY (Special command -> Break)

После появления приглашения можно выполнить команду dir bootflash: для просмотра файлов прошивок на флэшке и загрузить нужный образ (тот, с которым все было хорошо) командами:

BOOT=bootflash:isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin

sync

confreg 0x2102

reset

В этом случае, isr4300-universalk9_npe.03.16.02.S.155-3.S2-ext.SPA.bin — это файл образа в памяти устройства.

Если при попытке просмотра файлов командой dir bootflash: у вас появляется сообщение «Please reset before continuing», то простой reset вам не поможет. Необходимо выполнить следующее:

confreg 0x0

reset

После этих двух команд, циска перезагрузится в ROMMON без дополнительных плясок. Ну а дальше выполняем те же пункты, которые указаны сверху, загружаемся и не забываем указать нужный образ для загрузки с последующим сохранением конфигурации :)