12
Сен

Выходим в интернет по другому: (MikroTik<->Ubuntu) * GRE / IPsec

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


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

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

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

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

<code class="bash hljs">$ sudo apt install traceroute

 

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

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

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

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

<code class="bash hljs">$ sudo cat &lt;&lt; EOF &gt;&gt; /etc/network/interfaces
 iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre <span class="hljs-built_in">local</span> 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;

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

<code class="bash hljs">$ sudo service networking restart

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

<code class="bash hljs">$ 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.

<code class="bash hljs">$ 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
[email protected]:~$ 

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

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

<code class="bash hljs">$ sudo cat &lt;&lt; EOF &gt;&gt; /etc/network/interfaces
<span class="hljs-comment">#static route"</span>
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

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

<code class="bash hljs">$ sudo service networking restart

Включаем ip_forward

<code class="bash hljs">$ sudo <span class="hljs-built_in">echo</span> <span class="hljs-string">"net.ipv4.ip_forward = 1"</span> &gt;&gt; /etc/sysctl.conf
$ sudo sysctl -p

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

<code class="bash hljs">$ sudo iptables -t nat -A POSTROUTING -j SNAT --to-source 80.211.x.x -o eth0

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

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

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

<code class="dos hljs">/ip route
add comment=linkedin distance=<span class="hljs-number">1</span> dst-address=<span class="hljs-number">91</span>.<span class="hljs-number">225</span>.<span class="hljs-number">248</span>.<span class="hljs-number">0</span>/<span class="hljs-number">22</span> gateway=gre-tunnel1
add comment=linkedin distance=<span class="hljs-number">1</span> dst-address=<span class="hljs-number">108</span>.<span class="hljs-number">174</span>.<span class="hljs-number">0</span>.<span class="hljs-number">0</span>/<span class="hljs-number">20</span> gateway=gre-tunnel1
add comment=linkedin distance=<span class="hljs-number">1</span> dst-address=<span class="hljs-number">185</span>.<span class="hljs-number">63</span>.<span class="hljs-number">144</span>.<span class="hljs-number">0</span>/<span class="hljs-number">22</span> gateway=gre-tunnel1

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

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

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

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

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

<code class="bash hljs">$ apt install strongswan

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

<code class="bash hljs">$ cat &lt;&lt; EOF &gt; /etc/ipsec.conf 
<span class="hljs-comment"># ipsec.conf - strongSwan IPsec configuration file</span>

config setup
    charondebug=<span class="hljs-string">"ike 2, knl 2, cfg 2, net 2, esp 2, dmn 2,  mgr 2"</span>

conn %default
<span class="hljs-comment">#    keyexchange=ikev2</span>

conn mikrotik
    <span class="hljs-comment"># Try connect on daemon start</span>
    auto=start

    <span class="hljs-comment"># Authentication by PSK (see ipsec.secret)</span>
    authby=secret

    <span class="hljs-comment"># Disable compression</span>
    compress=no

    <span class="hljs-comment"># Re-dial setings</span>
    closeaction=clear
    dpddelay=30s
    dpdtimeout=150s
    dpdaction=restart

    <span class="hljs-comment"># ESP Authentication settings (Phase 2)</span>
    esp=aes128-sha1

    <span class="hljs-comment"># UDP redirects</span>
    forceencaps=no

    <span class="hljs-comment"># IKE Authentication and keyring settings (Phase 1)</span>
    ike=aes128-sha1-modp2048,aes256-sha1-modp2048
    ikelifetime=86400s
    keyingtries=%forever
    lifetime=3600s

    <span class="hljs-comment"># Internet Key Exchange (IKE) version</span>
    <span class="hljs-comment"># Default: Charon - ikev2, Pluto: ikev1</span>
    keyexchange=ikev1

    <span class="hljs-comment"># connection type</span>
    <span class="hljs-built_in">type</span>=transport

    <span class="hljs-comment"># Peers</span>
    left=188.x.x.x
    right=80.211.x.x

    <span class="hljs-comment"># Protocol type. May not work in numeric then need set 'gre'</span>
    leftprotoport=47
    rightprotoport=47
EOF 

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

<code class="bash hljs">$ <span class="hljs-built_in">echo</span> <span class="hljs-string">"80.211.x.x 188.x.x.x : PSK VeryBigSecret"</span> &gt;&gt; /etc/ipsec.secrets

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

<code class="bash hljs">$ ipsec restart

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

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

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

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

MikroTik

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

Ubuntu

<code class="bash hljs">$ 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 в описание интерфейса.

<code class="bash hljs">auto tun1
iface tun1 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    pre-up iptunnel add tun1 mode gre <span class="hljs-built_in">local</span> 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, но это уже не интересно: такой опыт у меня уже был.

Автор @