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

Итак, у нас есть статический публичный IP адрес, который приходит Ethernet шнуром в MikroTik RouterBOARD 750G r3 (hEX). Пробуем собрать вот такую конструкцию.


Настройку L2tp линка в рамках этой статьи я не описываю, а на схеме он нарисован только потому, что в ней упоминается.

1. Поднимаем VPS

Как вы уже догадались, нужна система, которая включена в интернет за пределами РФ. Большие деньги на это тратить не хотелось, и я остановился на Aruba Cloud. Здесь всего за 1 евро в месяц дается VM в локациях Италия, Чехия, Германия, Франция и Великобритания. Я свой выбор остановил на Чехии, потому что ping до наших ресурсов оказался на 20ms меньше, чем с Итальянского (50ms против 70ms). Ubuntu 16.04 LTS поднялась очень быстро. Войти в нее удалось раньше, чем «позеленел» статус в интерфейсе «облака».



Сервер устанавливается в минимальной конфигурации. Не помешает установить утилитку traceroute.

$ sudo apt install traceroute

2. Настраиваем GRE между MikroTik и Ubuntu

Выбор в пользу GRE был сделан по нескольким причинам:

• просто и понятно настраивается;
• легко траблешутится;
• маршрутизация проще некуда;
• элементарно отрисовывается график загрузки интерфейса в MikroTik.

Итак, на стороне Ubuntu описываем интерфейс tun1 в /etc/network/interfaces

$ sudo cat << EOF >> /etc/network/interfaces
 iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre local 80.211.x.x remote 188.x.x.x ttl 255
    up ifconfig tun1 multicast
    pointopoint 192.168.10.2
    post-down iptunnel del tun1
EOF

Здесь все просто:

• 80.211.x.x — адрес VM с Ubuntu в Чехии;
• 188.x.x.x — внешний адрес MikroTik;
• 192.168.10.1 — адрес на туннельном интерфейсе tun1 на стороне Ubuntu;
• 192.168.10.2 — адрес туннельного интерфейса на MikroTik;

Активацию этой части конфигурации я по-старинке делаю так:

$ sudo service networking restart

У нас получился вот такой интерфейс:

$ ifconfig tun1
tun1      Link encap:UNSPEC  HWaddr 10-D3-29-B2-00-00-B0-8A-00-00-00-00-00-00-00-00
          inet addr:192.168.10.1  P-t-P:192.168.10.2  Mask:255.255.255.255
          inet6 addr: fe80::200:5ffa:50d3:c9c2/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1476  Metric:1
          RX packets:379 errors:0 dropped:0 overruns:0 frame:0
          TX packets:322 errors:4 dropped:7 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:103387 (103.3 KB)  TX bytes:159422 (159.4 KB)

Со стороны MikroTik настройка тоже несложная. Я делал это из Web-интерфейса.



Обращаю внимание на то, что не сконфигурирован keepalive. Мне так и не удалось включить ответную часть на Ubuntu. Если не будет трафика, то интерфейс на MikroTik будет «уходить» из running и подниматься, только если пойдет трафик со стороны Ubuntu.

На этом этапе у нас должны подняться туннельные интерфейсы с двух сторон. Проверить это просто. Достаточно запустить ping c Ubuntu в сторону MikroTik.

$ ping 192.168.10.2
PING 192.168.10.2 (192.168.10.2) 56(84) bytes of data.
64 bytes from 192.168.10.2: icmp_seq=1 ttl=64 time=56.0 ms
64 bytes from 192.168.10.2: icmp_seq=2 ttl=64 time=59.9 ms
64 bytes from 192.168.10.2: icmp_seq=3 ttl=64 time=56.3 ms
64 bytes from 192.168.10.2: icmp_seq=4 ttl=64 time=56.1 ms
--- 192.168.10.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 56.091/57.137/59.936/1.618 ms
user@vps:~$ 

Настраиваем маршрутизацию в сторону абонентских сетей в туннельный интрефейс

Приватные IP адреса локальной сети, из которой осуществляется выход в интернет — 192.168.1.0/24. Сеть 192.168.6.0/24 — это сеть, выделенная для подключения к MikroTik по L2TP из «внешнего мира». Для того, чтобы работали компьютеры локальной сети и удаленные устройства, добавляем маршруты на обе сети в конец файла /etc/network/interfaces

$ sudo cat << EOF >> /etc/network/interfaces
#static route"
up ip ro add 192.168.1.0/24 via 192.168.10.2
up ip ro add 192.168.6.0/24 via 192.168.10.2
EOF

Еще раз просим систему обновить сетевые настройки

$ sudo service networking restart

Включаем ip_forward

$ sudo echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
$ sudo sysctl -p

Прописываем маскарадинг

$ sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 80.211.x.x -o eth0

Настаиваем маршрутизацию на MikroTik

Поскольку у меня не стоит задача «развернуть» весь трафик в интернет через другую страну, то в туннельный интерфейс я буду маршрутизировать только интересующие меня ресурсы. В качестве такого ресурса я выбрал Linkedin.

Итак, добавляем маршруты на MikroTik (через терминалку):

/ip route
add comment=linkedin distance=1 dst-address=91.225.248.0/22 gateway=gre-tunnel1
add comment=linkedin distance=1 dst-address=108.174.0.0/20 gateway=gre-tunnel1
add comment=linkedin distance=1 dst-address=185.63.144.0/22 gateway=gre-tunnel1

К этому моменту у меня начал открываться заветный ресурс и на этом можно было бы и закончить, поскольку, даже несмотря на то что GRE трафик не шифрован и его прекрасно видно в Wireshark, далеко не все провайдеры DPI-ят трафик (а если и DPI-ят, то точно не заглядывают внутрь туннелей для отслеживания трафика от запрещенных ресурсов), да и АПК «Ревизор» не интересуется тем, какой реально абонентами потребляется трафик.

На дальнейшие эксперименты меня натолкнул тот факт, что в настройках GRE интерфейса MikroTik есть опция IPsec Secret. Неужели действительно все так просто?!

3. Зашифровываем туннель

В качестве шифровальщика на стороне Ubuntu я выбрал strongSwan. Пример конфигурации я взял из материала Configure GRE over IPSec secured private channel, но сразу не заработало и пришлось внести некоторые правки.

Устанаваливаем

$ apt install strongswan

Вносим в основной конфигурационный файл strongSwan вот это:

$ cat << EOF > /etc/ipsec.conf 
# ipsec.conf - strongSwan IPsec configuration file

config setup
    charondebug="ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2"

conn %default
#    keyexchange=ikev2

conn mikrotik
    # Try connect on daemon start
    auto=start

    # Authentication by PSK (see ipsec.secret)
    authby=secret

    # Disable compression
    compress=no

    # Re-dial setings
    closeaction=clear
    dpddelay=30s
    dpdtimeout=150s
    dpdaction=restart

    # ESP Authentication settings (Phase 2)
    esp=aes128-sha1

    # UDP redirects
    forceencaps=no

    # IKE Authentication and keyring settings (Phase 1)
    ike=aes128-sha1-modp2048,aes256-sha1-modp2048
    ikelifetime=86400s
    keyingtries=%forever
    lifetime=3600s

    # Internet Key Exchange (IKE) version
    # Default: Charon - ikev2, Pluto: ikev1
    keyexchange=ikev1

    # connection type
    type=transport

    # Peers
    left=188.x.x.x
    right=80.211.x.x

    # Protocol type. May not work in numeric then need set 'gre'
    leftprotoport=47
    rightprotoport=47
EOF 

Прописываем pre-shared-key (PSK) в /etc/ipsec.secrets

$ echo "80.211.x.x 188.x.x.x : PSK VeryBigSecret" >> /etc/ipsec.secrets

Перезапускаем strongSwan

$ ipsec restart

На этом настройка Ubuntu практически завершена. Приступаем к настройке MikroTik.

Я выставил вот такие настройки дефалтового proposal



Настало время вписать в поле IPsec Secret тот же PSK, что был указан в /etc/ipsec.secrets на сервере (VeryBigSecret).

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

MikroTik



Если «провалиться» глубже, то должно быть вот так:



Ubuntu

$ ipsec status
Security Associations (1 up, 0 connecting):
        mikrotik[2]: ESTABLISHED 60 minutes ago, 80.211.x.x[80.211.x.x]...188.x.x.x[188.x.x.x]
        mikrotik{2}:  INSTALLED, TRANSPORT, reqid 1, ESP SPIs: cc075de3_i 07620dfa_o
        mikrotik{2}:   80.211.x.x/32[gre] === 188.x.x.x/32[gre]

Теперь GRE (protocol 47) между MikroTik и Ubuntu шифруется IPseс (ESP). Анализ pcap файла, снятого tcpdump-ом, это подтвердил.



Вроде бы, все работает и заветный ресурс открывается. Однако после того, как я направил в туннель еще несколько ресурсов, оказалось, что не все так хорошо, как казалось изначально. Удалось выяснить, что перестали проходить пакеты большого размера (вернее, они перестали правильно фрагментироваться).

Решение нашлось быстро. Оказалось, что достаточно уменьшить MTU до 1435 на обоих концах туннеля.

MikroTik



Ubuntu — добавляем mtu 1435 в описание интерфейса.

auto tun1
iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre local 80.211.x.x remote 188.x.x.x ttl 255
    up ifconfig tun1 multicast
    pointopoint 192.168.10.2
    mtu 1435
    post-down iptunnel del tun1

Диагностика установления IPsec соединения не тривиальна. На Ubuntu логи читаются значительно проще, чем на MikroTik. По умолчанию на MikroTik выключено логирование IPsec. Включается просто, но проводить анализ проще через терминалку.

Мне удалось добиться скорости скачивания 25 Мбит/с и отдачи 50 Мбит/с. На мой взгляд, этого вполне хватает для комфортной работы с ресурсом. Почему не разгоняется больше — это пока загадка. Загрузка процессоров на обоих концах туннеля не высока. Основная версия — это ограничение скорости на стороне облака. Как-нибудь на досуге погоняю файлы между серверами без шифрования.

P.S.: В планах настроить IKEv2 туннель с моих устройств (я использую технику Apple) непосредственно на сервер с использованием сертификатов. Пока мне не удалось это сделать. Apple-девайсы почему-то не отвечают на запросы установления защищенного соединения со стороны сервера. Можно, конечно, сделать L2tp, но это уже не интересно: такой опыт у меня уже был.

Original source: habrahabr.ru (comments, light).