Компы и автомобили (Posts about Mikrotik)

L2TP+IPSec

at-hacker — Thu, 10 Jul 2014 12:21:00 GMT

Решил наконец-то разобраться с этой мутной доселе темой — IPSec. И в частности — с её реализацией на FreeBSD.

Если не вдаваться в кровавые подробности, то в общих чертах дело обстоит так: L2TP настраивается как обычно, абсолютно без какой-либо оглядки на то, что должен быть ещё и IPSec. Я это делаю обычно на mpd5, путём небольшой правки дефолтного конфига, который идёт с mpd.

IPSec в данном случае логически представляет собой некую надстройку, в которой нужно указать, что «трафик, идущий с такого-то IP на такой-то по таким-то портам и такого-то протокола — требует шифрования (это так называемый „транспортный режим“ работы IPSec). В случае с L2TP эти параметры выставляются так: трафик с любого IP и любого порта, идущий на IP-адрес сервера и порт 1701 (стандартный порт L2TP) по протоколу UDP, потребно шифровать.

Во фре IPSec реализуется с помощью пакета ipsec-tools (он же racoon).

После установки ipsec-tools потребуются следующие модификации в /etc/rc.conf:

% cat /etc/rc.conf
...
ipsec_program="/sbin/setkey"
ipsec_file="/usr/local/etc/racoon/setkey.conf"
racoon_enable="YES"
racoon_flags="-l /var/log/racoon.log"
...

Далее идут конфиги самого racoon и утилиты setkey, а также список pre-shared key по-клиентно:

% cat /usr/local/etc/racoon/setkey.conf
flush;
spdflush;
spdadd 0.0.0.0/0[any] 192.168.2.2[1701] udp -P in  ipsec esp/transport//require;
spdadd 192.168.2.2[1701] 0.0.0.0/0[any] udp -P out ipsec esp/transport//require;

 % cat /usr/local/etc/racoon/racoon.conf
path    pre_shared_key "/usr/local/etc/racoon/psk.txt";
log     debug;
listen
{
        isakmp          192.168.2.2 [500];
        isakmp_natt     192.168.2.2 [4500];
        strict_address;
}

remote anonymous
{
        exchange_mode    main;
        passive          on;
        proposal_check   obey;
        support_proxy    on;
        nat_traversal    off;
        ike_frag         on;
        dpd_delay        20;

        proposal
        {
                encryption_algorithm  aes;
                hash_algorithm        sha1;
                authentication_method pre_shared_key;
                dh_group              modp1024;
        }

        proposal
        {
                encryption_algorithm  3des;
                hash_algorithm        sha1;
                authentication_method pre_shared_key;
                dh_group              modp1024;
        }
}

sainfo anonymous
{
        encryption_algorithm     aes,3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm    deflate;
        pfs_group                modp1024;
}

 # cat /usr/local/etc/racoon/psk.txt
192.168.2.4     Password
192.168.2.5     Password1
192.168.1.4     Password2

Клиентом выступает маршрутизатор Mikrotik. Там схема та же — настраивается как обычно L2TP-клиент, а затем топаем в раздел IP ==> IPSec и добавляем записи на вкладке Peers и Policies. Вкладка Peers:

Собственно, здесь я изменил только поля Address (в нём указываем IP VPN-сервера) и Secret (это и есть pre-shared key), а также поле Hash algorithm (по дефолту стоял md5). Остальные поля оставил как есть.

И добавляем запись в разделе Policies:

«Как вы понимаете из названия» (с), поля Src. address и SA src. address — это IP-адрес клиента, а Dst. address и SA dst. address — это адрес VPN-сервера.

MikroTik и OpenVPN

at-hacker — Tue, 11 Dec 2012 18:14:00 GMT

Есть у нас в офесе VPN. Точнее, между 40 офесами. По мере роста сети всплыла грабля — некоторые удалённые (и отсталые) провайдеры грешат packet reordering. Что напрочь сносит крышу модулю, ответственному за реализацию MPPC/MPPE в mpd5. Симптомы при этом такие — туннель визуально жив, и по нему спокойно ходят LCP-пакеты, но вот трафик уже не ходит. В логах mpd при этом наличествуют сообщения:

ng_mppc_decompress: too many (4094) packets dropped, disabling node

Если вы такие обнаружили — знайте, это вилы. Надо валить. Потому что не лечится никак. Хотя вот эксперимент показал, что с микротика на микротик такой же канал, с MPPC/MPPE держится нормально. Т. е. микротиковцы в RouterOS этот вопрос решили. Но ни фря, ни линукс в качестве VPN-сервера с packet reordering бороться не умеют. В связи с чем было принято волевое решение проблемных клиентов перевести на OpenVPN. По той же схеме — сервер на FreeBSD, клиенты — микротики RB750.

Спустя некоторое время вдумчивого курения манов и некоторого количества глупых вопросов в ru_root наступило просветление и я принялся ваять конфиги сервера и создавать сертификаты. Создав всё, начал терзать первого проблемного клиента, отключив L2TP-линк на нём и создав клиентский интерфейс OpenVPN. Ну, момент истины, нажимаю «Apply» в настройках openvpn-интерфейса на микротике, и... теряю связь с объектом вообще. А он километров за 600 от меня. наступило просветление и я принялся ваять конфиги сервера и создавать сертификаты. Создав всё, начал терзать первого проблемного клиента, отключив L2TP-линк на нём и создав клиентский интерфейс OpenVPN. Ну, момент истины, нажимаю «Apply» в настройках openvpn-интерфейса на микротике, и... теряю связь с объектом вообще. А он километров за 600 от меня.

Сначала грешил на то, что забыл убрать галку Add default route у openvpn-интерфейса. Проверил на тестовом роутере — ни фига, по умолчанию эта галка отсутствует. А шо же за ботва? Повторяю процедуру на тестовом роутере, подключившись к нему по локалке, и... теряю связь уже с тестовым роутером. Правда, как-то странно — winbox не отвалился, но списка интерфейсов получить не удаётся, выдаётся ошибка «out of index». Странно. Однако роутер частично подконтролен — его удаётся перезагружать. И если всё сделать очень быстро, то openvpn-интерфейс подняться ещё не успевает, и его можно отключить. Тогда роутер остаётся на связи и можно им рулить.

В общем, практика показала, что в RouterOS, зашитых в наших микротиках (v4.11) есть суровый баг. Который приводит к тому, что при поднятии openvpn-интерфейса у роутера сваливается WAN-интерфейс в несознанку, и тянет за собой что-то ещё. Только проапгрейдившись до версии 5.21 удалось нормально создать связь по OpenVPN с микротиком. И ещё одно западло в микротиках — они не умеют openvpn по UDP, только TCP. Что заметно снижает скорость, по сравнению с L2TP — так раза в полтора.