Как стать автором
Обновить

Выходим в интернет за пределами РФ: (MikroTik<->Ubuntu) * GRE / IPsec

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

Итак, у нас есть статический публичный 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.

Устанавливаем IP адрес на туннельный интерфейс на стороне MikroTik 192.168.10.2

image

На этом этапе у нас должны подняться туннельные интерфейсы с двух сторон. Проверить это просто. Достаточно запустить 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

Прописываем SNAT.
Для статического внешнего IP он должен работать быстрее чем MASQUERADE за счет того, что не нужно каждый раз выяснять IP адрес интерфейса.

$ 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-modp2048,aes256-sha1-modp2048

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

UPD 1: настройки iptables

Устанавливаем пакет netfilter-persistent

$ sudo apt install netfilter-persistent

Я писал правила командами, а потом записал их в /etc/iptables/rules.v4 командой iptables-save > /etc/iptables/rules.v4

В итоге, у меня получился вот такой набор:

$ cat /etc/iptables/rules.v4
# Generated by iptables-save v1.6.0 on Thu Sep 14 20:36:19 2017
*nat
:PREROUTING ACCEPT [17:3042]
:INPUT ACCEPT [2:92]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j SNAT --to-source 80.211.x.x
COMMIT
# Completed on Thu Sep 14 20:36:19 2017
# Generated by iptables-save v1.6.0 on Thu Sep 14 20:36:19 2017
*filter
:INPUT DROP [29:4527]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -p icmp -j ACCEPT
# TCP/4022 - это нестандартный порт для ssh (я всегда меняю порт, чтобы было меньше port-scan-а)
# !!! если ssh на стандартном порту, замена может нарушить вход на сервер
-A INPUT -p tcp -m tcp --dport 4022 -j ACCEPT
-A INPUT -p udp -m udp --dport 500 -j ACCEPT
-A INPUT -p gre -j ACCEPT
-A INPUT -p esp -j ACCEPT
# Forwarding
-A FORWARD -j ACCEPT
COMMIT
# Completed on Thu Sep 14 20:36:19 2017

В /etc/rc.local я добавил активацию правил при старте машины (другим способом мне это сделать пока не удалось).

$ echo "iptables-restore < /etc/iptables/rules.v4" >> /etc/rc.local

После перезагрузки сервера проверяем, что все правила на месте.

$ iptables -L -n -v
Chain INPUT (policy DROP 185 packets, 28847 bytes)
 pkts bytes target     prot opt in     out     source               destination
    4   344 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
   32   896 ACCEPT     icmp --  *      *       0.0.0.0/0            0.0.0.0/0
  948 66063 ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3022
  172 21504 ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:500
 2864  454K ACCEPT     47   --  *      *       0.0.0.0/0            0.0.0.0/0
 2864  582K ACCEPT     esp  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
 4572 3303K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 1820 packets, 2974K bytes)
 pkts bytes target     prot opt in     out     source               destination
 4797 6544K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED


UPD 2: рекомендую отключить MikroTik Neighbor discovery на интерфейсе gre-tunnel1.
Если этого не сделать, то при вышеописанных настройках iptables будут отбрасываться пакеты на UDP/5678.

Sep 15 19:25:33 vps kernel: [42049.805599] IN=tun1 OUT= MAC= SRC=192.168.10.2 DST=255.255.255.255 LEN=133 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=36233 DPT=5678 LEN=113

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

Публикации

Истории

Работа

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн
Геймтон «DatsEdenSpace» от DatsTeam
Дата 5 – 6 апреля
Время 17:00 – 20:00
Место
Онлайн