Выходим в интернет за пределами РФ: (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.

    $ 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, но это уже не интересно: такой опыт у меня уже был.
    Share post

    Similar posts

    Comments 50

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

      Лучше делать через Mangle и адресные листы. В Mangle на прероуте указываете метку маршрута, в Routes указываете интерфейс и метку. Если нужно, распишу подробнее.
      В итоге просто добавляете в адресные листы название ресурса, и он сразу ходит через указанный шлюз.
        0
        Х-м… пока не понял о чем речь. Можно подробнее?
          +1
          Это помечает соединение
          /ip firewall mangle add chain=prerouting src-address=192.168.0.0/24 dst-address-list=AnotherGWList action=mark-routing new-routing-mark=AnotherGWRoute

          Это маршрут для помеченных
          /ip route add distance=1 routing-mark=AnotherGWRoute gateway=*ваш_GW*

          Ну а это — ресурс, который нужно маршрутизировать через нужный шлюз.
          /ip firewall address-list add address=linkedin.com list=AnotherGWList

          Далее просто добавляете нужный ресурс в адресные листы с именем AnotherGWList.
            0
            Понял, спасибо! Попробую.
              0
              Через Mangle же можно более тонко настраивать заворот, к примеру только с определенного IP или мас-адреса. Увы, листов мас-адресов пока нет.
              0
              Вариант, не плох, но есть нюансы.
              А вдруг у ресурса есть поддомены, например, их тоже тогда надо все описать/вписать верно?
              Не проще ли из базы whois вытянуть список подсетей ресурса (если мы конечно говорим не про маленький сайт визитку) и завернуть их через нужный GW?
              Следующий нюанс, адрес резолвится в IP (а списки таки да, динамические, хранятся именно по IP) создаются или при добавлении ресурса или при первом старте микротика — те ситуация когда вдруг на ресурсе измениться IP может быть исправлена либо пересозданием записи в списке или перезагрузкой микротика, что тоже не по феншую.

              Вообщем, имхо, ваш вариант имеет место быть, но я бы честно говоря, несколько раз подумал прежде чем использовать именно его.
                0
                Я подумаю на предмет использования встроенного скриптинга в Микротик для автоматического обновления адресов в маршрутах.
                  +2
                  Я поступил проще:
                  / ip firewall filter add action=add-src-to-address-list address-list=toVPN address-list-timeout=3d chain=forward content="Location: http://адрес заглушки провайдера\?" in-interface=WAN protocol=tcp src-port=80
                  Дальше mangle и маршрут как описал AcidVenom.
                  При попытке открыть сайт отображается заглушка и ip сайта добавляется в address-list, при повторном открытии он уже открывается через туннель. Время жизни записи в моем случае 3 дня. Можно менять по желанию.
                    +2
                    Не сработает с https сайтами.
                  +1
                  Если хотите автоматизировать через whois — скрипты в помощь. Это опять же проще через адресные листы.
                  Адреса резолвятся в IP и живут по TTL, так что по феншую.
                  Once a domain is added to an address-list it is resolved by routeros and the resolved IP(s) is added to the same address-list as a dynamic entry with timeout value the TTL returned by the DNS protocol.
                  When the timeout (TTL) expires, routeros will re-resolve the domains again and if the IP is changed it will replace it in the address-list.
                    0
                    Вот за этот отсыл к мануал спасибо, сразу эту инфу не нашел — тогда да, вполне годное решение.
                    Но вопрос с сабдоменами все равно открыт получается.
                    У себя я решил этот вопрос заворотом подсетей а вот с вашим предложением даже не знаю как быть…
                      0
                      Дык можно точно так же в адресный листы указать подсеть с тем же именем. Вопрос именно в удобстве: не нужно каждый раз лазить в маршруты, мэнглы и т.д. Подкинул нужные IP или названия доменов и готово. И опять же видно весь список или списки.
                      А уж если у вас поднят OSPF и вы используете кучу маршрутов, то в них голова заболит разбираться.
                  0
                  Забыли маскарад на ВПН интерфейс сделать (если не настроено, или настроено на другой интерфейс, не пойдет трафик).

                  /ip firewall nat add chain=srcnat action=masquerade out-interface=*имя_ВПН_интерфейса*
                    0
                    Вы это лучше автору скажите, в статье этого пункта нет.
                      0
                      Не забыл. Я это и не планировал делать. Ubuntu тоже мой и через него пакеты от LAN проходят с неизменным src IP. Ну и пусть. Двойная трансляция мне нужна.
                        0
                        не нужна
                          0
                          Согласен. Пост читал вдоль. У меня частный случай, когда впн сервер не маскарадит.
                        0
                        Попробовал. Работает почему-то заметно медленнее. Предположу, что теряет первые пакеты и переписылает.
                    0
                    Я уже делал нечто подобное правда без GRE. Там же и про RoadWarriors написано (т.е. L2TP+IPSec). Единственный момент — на мой взгляд лучше использовать libreswan, т.к. у strongswan проблемы с apple-девайсами (причем на момет начала 2016 года проект был заморожен, и разработчик не спешил фиксить баги. libreswan это, собственно, форк strongswan).
                      0
                      Спасибо, поизучаю эту тему. Вопрос с Apple-девайсами у меня действительно остался открытым…
                        0
                        Если мне не изменяет память, то libreswan — форк Openswan, который, в свою очередь, форк FreeS/WAN.

                        StrongSwan — имеет корни от FreeS/WAN, но почти полностью переосмысленный.
                          0
                          Возможно, что и так, но главная моя мысль была в том, что когда я этой задачей занимался, strongswan почти не развивался, и в репах Debian 8 лежала битая версия (latest). Хорошо, если ситуация изменилась
                            0
                            На офицальном сайте стронгсвана последнее обновление датируется 14.08.2017.
                        –1
                        *просмотрел по диагонали*
                        эм… а не лучше ли будет OpenVPN с сертификатами заюзать?
                          0
                          Давайте определимся откуда и куда… Тема с OpenVPN для Apple-девайсов у меня пока не раскрыта. Что-то конкретное говорить про LAN2WAN через OpenVPN я пока тоже не готов. Может есть пример такой конфигурации?
                            0
                            да везде :)
                            у самого к продукции эпл неприязнь, но если погуглить, то можно такое найти
                            habrahabr.ru/post/168853
                            ну и
                            itunes.apple.com/ru/app/openvpn-connect/id590379981?mt=8
                            а пример конфигурации… если vps делаем ovpn сервером, на микротике просто добавляем интерфейс, ну и также например маршрутами необходимый трафик в него посылаем по адресу назначения…
                            просто gre… наблюдал уже, что некоторые провайдеры ни с того ни с сего резать начинают… imho openvpn более гибок, да и с сертификатами безопаснее, чем с psk…
                              0
                              Спасибо. Подумаю на тему OpenVPN на досуге.
                              Я не сталкивался с тем, чтобы провайдеры «резали» gre. Какого-то разумного объяснения тому, зачем им это делать не нахожу. В любом случае, у меня получился уже не GRE, а ESP. Вот его как раз могут начать «резать» по требованию властей…
                                +1
                                OpenVPN сильно медленнее ipsec в силу работы в userspace.
                                Ну и как упоминали ниже, микротики не умеют его через udp, что тоже накладывает ограничения в производительности. Ситуация такая уже много лет и меняться не собирается.
                                  0
                                  и чего вы за udp ухватились? :)
                                  а если почитать пост между строк, то видно, что автору 443/tcp будет лучшим вариантом :)
                                  хотя тут еще про sstp писали… не знаю — его еще не щупал.
                                  да и медленнее… у меня тут интернеты сильно медленнее столичных. и ничего — меня устраивает :)
                                  а в цифрах можно про медленнее? у меня конечно не hEX… но и аплинк всего 5120/896…
                                    0
                                    Полгода-год назад SSTP прокачивал до 3-5Мбит/с, L2TP+IPsec с тех пор стабильно прокачивает 25Мбит/с.
                                      0
                                      Ну… зависит от железки конечно. У меня 3011, который в разы быстрее хекса, и он не выжимает 100 мбит, ну в районе 50-70 где-то. Ipsec разгоняется до ~150.
                                      А зачем 443/tcp собственно? Если говорить про тотальную секьюрность и антицензуру, то надо смотреть в сторону udp2raw или govpn, но это уже не микротик будет.
                                +2
                                Микротик хреново с ними дружит.
                                  0
                                  ну у меня туннельчик до VPS настроен — вроде полгода пока — полет нормальный…
                                  на каком железе, какая версия и в чем хреновость заключается?
                                  +2
                                  Микротик не умеет UDP и LZO с OVPN, и разработчики это допиливать не собираются, официальная позиция — используйте SSTP…
                                    0
                                    У которого проблемы по производительности.
                                      0
                                      ну меня интересовал именно tcp на 443ий порт
                                      а сжатие… так ли оно необходимо? если учесть, что большинство по объему трафика плохо сжимается, ибо данные и так уже сжаты?
                                    0
                                    В планах настроить IKEv2 туннель с моих устройств (я использую технику Apple) непосредственно на сервер с использованием сертификатов.

                                    Предложил бы использовать для этой цели SSH. На стороне клиента делаем что-то вроде:
                                    ssh -w 0:0 root@server_ip
                                    Мне неизвестно о существовании аналога /etc/network/interfaces на OS X, так что видимо tun0 на стороне Apple придётся настраивать вручную (и маршрутизацию тоже). Но зато поддержка сертификатов и шифрования из коробки.
                                      0
                                      Если MacOS это может сработать, то в iOS скорее всего нет.
                                      В Apple-устройствах есть встроенные VPN клиенты. Подключение через них производится «в один клик».
                                        0
                                        SSH клиенты, даже бесплатные, для iOS есть, и они поддерживают как минимум проброс портов.
                                        Но в общем да, неаккуратненько. Тема интересная, подумаю тоже на досуге, как заставить заработать встроенный VPN клиент на iOS.
                                        0
                                        коллега уже описывал конфиги стронгсвана для яблок
                                        habrahabr.ru/post/250859
                                          +1
                                          Да, эта статья у меня есть в закладках, но это пока не заработало (бился над этим дня 3). Там есть лайфкак связанный xauth, который мне применять не хочется.
                                          Еще у меня и на Mасbook и на iPad стоят последние бетты. Может что с ними не так… Я на досуге еще раз поиграюсь.
                                        0
                                        Обращаю внимание на то, что не сконфигурирован keepalive. Мне так и не удалось включить ответную часть на Ubuntu. Если не будет трафика, то интерфейс на MikroTik будет «уходить» из running и подниматься, только если пойдет трафик со стороны Ubuntu.

                                        Попробуйте использовать netwatch, отправляя пинг на Ubuntu — это будет работать вместо keepalive
                                          0
                                          За 1 евро доступны VM только в Италии и Чехии :)
                                            0
                                            Спасибо, не знал. Меня пока устраивает Чехия. Дальше посмотрим…
                                            0
                                            Тоже пользуюсь связкой mikrotik + ubuntu сервер на VPS от Arubcloud для vpn. Только использую не тоннель сайт-ту-сайт, а l2tp+ipsec сервер (strongswan) на убунту, с ручным подключением.
                                            Но есть вопрос, может тут кто ответит, почему с клиента windows l2tp+ipsec, находящийся за NAT, я без проблем подключаюсь к удаленному l2tp ipsec серверу mikrotik, а чтобы подключиться к серверу l2tp+ipsec ubuntu, приходится править реестр windows, так как ошибка 809 (ms рекомендует, если клиент за NAT то внести изменения в реестр HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent\AssumeUDPEncapsulationContextOnSend )
                                            P.S. Пробовал разных провайдеров, со статикой. В роли шлюза и сервера использовал, mikrotik, ubuntu server, 10/14/16 версий. Алгоритм шифрования ipsec на убунте тот же, что и на mikrotik.
                                            При этом клиенты ios/android без проблем випиенятся за nat'ом той же сети, как к mikrotik, так и к ubuntu.
                                              0
                                              Пробую такую конфигурацию (с ubuntu 16.04) и… не работает. Пинговать машины друг друга пингуют (пришлось на микротике в явном виде прописать адрес на gre-интерфейс), добавляю машруты — пинг/трейсроут (с машины за микротиком) на добавленные адреса проходят а что то большее — нет и в логе ubuntu IPv4: martian source <ip_куда_обращаемся> from <публичный ip микротика>, on dev tun1
                                                0
                                                Спасибо! Добавил настройку IP адреса на интрефейсе MikroTik.
                                                Что касается маршрутизации и forwarding-а пакетов, то нужно tcpdump-ить трафик и смотреть что видно. В логах следов ping/traceroute ничего не будет.
                                                  0
                                                  У меня была проблема в том, что при добавления сайта в список, микротик брал его ip адреса из ДНС провайдера, а он отдавал свою заглушку. Поправил глобальный ДНС на 1.0.0.1 и все заработало. Но кроме linkedin.com. В чем с ним проблема так и не понял.
                                                    0
                                                    Разобрался — надо было еще добавить в список www.linkedin.com
                                                  0

                                                  У меня была проблема с MTU, в tcpdump-е было что-то вроде:


                                                  ICMP x.x.x.x unreachable - need to frag (mtu 1426), length 556

                                                  Пробовал устанавливать MTU на GRE-интерфейсе (и вообще где торько можно), не получалось.
                                                  Долго искал решение, помогло только добавление tcp-mss для интерфейсов GRE, например:


                                                  /ip firewall mangle
                                                  add action=change-mss chain=forward new-mss=1300 out-interface=gre passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1420-65535
                                                  add action=change-mss chain=forward new-mss=1300 in-interface=gre passthrough=yes protocol=tcp tcp-flags=syn tcp-mss=1420-65535

                                                  Only users with full accounts can post comments. Log in, please.