Организация SSH Layer 3 туннеля

    В данном разделе опишу как использовать возможности OpenSSH для создания Layer 3 туннелей, применительно к OS Debian GNU/Linux (наверняка без особых проблем заработает и в Ubuntu).

    Примерно так выглядит схема, которую мы построим:

    ----------        /\_/-\/\/-\       -----------------
    | Клиент |~~~~~~~/ Интернет /~~~~~~~|    Сервер     |
    ----------       \_/-\/\_/\/      / -----------------
    ||\                           \          ||\
    || {tun0}                      {vlan8}   || {tun1}
    ||                                       ||
    \-================= tunnel ==============-/
    
        * vlan8 - 212.90.160.1/27
        * tun0 - 10.254.254.2/30
        * tun1 - 10.254.254.1/30


    Подготовительные работы на клиентской стороне.

    В нашей схеме будем использовать аутентификацию по ключу, для этого сначала сгенерируем сам ключ (тип ключа rsa, размер 4Кбита) и скопируем его в учётную запись root'а на сервере (на сервере, при этом, придётся на время открыть возможность логиниться root'ом — PermitRootLogin yes):

    # sudo ssh-keygen -t rsa -b 4096
    # ssh-copy-id -i .ssh/id_rsa.pub root@212.90.160.1


    На этом этапе мы уже будем иметь сохранённый ключ ssh в .ssh/known_hosts, дав ответ «yes» примерно на такой вопрос:

    The authenticity of host '212.90.160.1 (212.90.160.1)' can't be established.
    RSA key fingerprint is aa:fe:a0:38:7d:11:78:60:01:b0:80:78:90:ab:6a:d2.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added '212.90.160.1' (RSA) to the list of known hosts.


    и уже скопированный в .ssh/authorized_keys на стороне сервера ключ авторизации клиента.

    Далее прописываем на стороне клиента сам интерфейс в /etc/network/interfaces:

    auto tun0
    iface tun0 inet static
    pre-up ssh -S /var/run/ssh-myvpn-tunnel-control -M -f -w 0:1 212.90.160.1 true
    pre-up sleep 5
    post-up ip l s tun0 mtu 1300
    address 10.254.254.2
    netmask 255.255.255.252
    pointopoint 10.254.254.1
    post-down ssh -S /var/run/ssh-myvpn-tunnel-control -O exit 212.90.160.1


    На этом этапе прекратим работы с клиентом и приступим к серверу.

    Подготовительные работы на стороне сервера.

    На стороне сервера перво-наперво вносим следующие изменения в /etc/ssh/sshd_config:

    PermitTunnel point-to-point
    PermitRootLogin forced-commands-only


    Теперь отредактируем /root/.ssh/authorized_keys, добавив в него команду на организацию туннеля:

    tunnel="1",command="/sbin/ifdown tun1;/sbin/ifup tun1" ssh-rsa AAAA......X9vc= root@ipclub


    После этого отредактируем /etc/network/interfaces:

    auto vlan8
    iface vlan8 inet static
    address 212.90.160.1
    netmask 255.255.255.224
    network 212.90.160.0
    broadcast 212.90.160.31
    gateway 212.90.160.30
    vlan_raw_device eth0
    mtu 1400
    
    iface tun1 inet static
    address 10.254.254.1
    netmask 255.255.255.252
    pointopoint 10.254.254.2
    post-up ip l s tun0 mtu 1300


    Не забываем определить в /etc/sysctl.conf состояние net.ipv4.conf.default.forwarding:
    Код

    net.ipv4.conf.default.forwarding=1


    ну или перед использование туннеля:

    $ sudo sysctl net.ipv4.conf.default.forwarding=1


    Важно! Если не устанавливать net.ipv4.conf.default.forwarding в значение 1, то туннели подниматься не будут!

    Собственно на этом этапе все подготовительные работы закончены. Пробуем поднять наш туннель со стороны клиента:

    $ sudo ifup tun0
    $ ip a l dev tun0
    9: tun0:  mtu 1300 qdisc pfifo_fast qlen 500
    link/[65534]
    inet 10.254.254.2 peer 10.254.254.1/30 scope global tun0
    $ ping -c2 10.254.254.1
    PING 10.254.254.1 (10.254.254.1): 56 data bytes
    64 bytes from 10.254.254.1: icmp_seq=0 ttl=64 time=15.116 ms
    64 bytes from 10.254.254.1: icmp_seq=1 ttl=64 time=16.454 ms
    --- 10.254.254.1 ping statistics ---
    2 packets transmitted, 2 packets received, 0% packet loss
    round-trip min/avg/max/stddev = 15.116/15.785/16.454/0.669 ms


    И наблюдаем icmp трафик на стороне сервера:

    $ sudo tshark -tad -pni tun1
    Running as user "root" and group "root". This could be dangerous.
    Capturing on tun1
    2009-03-10 11:25:53.927598 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
    2009-03-10 11:25:53.927649 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply
    2009-03-10 11:25:54.567857 10.254.254.2 -> 10.254.254.1 ICMP Echo (ping) request
    2009-03-10 11:25:54.567910 10.254.254.1 -> 10.254.254.2 ICMP Echo (ping) reply


    Дальше можете работать с этими интерфейсами как с обычными eth, vlan, gre и т.д. Маршрутизировать трафик через них, настраивать правила фильтрации и т.д. и т.п. Полёт мысли ограничивается лишь фантазией wink.gif Однако не забываем, что туннель всё-таки построен на третьем уровне поэтому маркирование пакетов QoS вряд-ли даст тот результат который хотелось бы ожидать.

    Собственно на этом можно было бы и закончить, но хочется обратить внимание на один «скользкий» момент, для тех кто хочет поднимать несколько SSH Layer 3 туннелей.
    Клиент: pre-up ssh -S /var/run/ssh-myvpn-tunnel-control -M -f -w 0:1 212.90.160.1 true
    Сервер: tunnel=«1»,command="/sbin/ifdown tun1;/sbin/ifup tun1" ssh-rsa AAAA......X9vc= root@ipclub
    0 — это номер туннеля на стороне клиента
    1 — это номер туннеля на стороне сервера

    Вот, чуть не забыл.
    Есть ещё один неприятный момент. Соединение, периодически может «отваливаться». Посему неплохо будет озаботиться где нидудь в cron'е выполнить примерно такой сценарий, на стороне клиента:

    $ cat /etc/cron.d/tun0
    PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
    */5 *     * * *     root   fping -c4 10.254.254.1 || ( /sbin/ifdown tun0; sleep 5; /sbin/ifup tun0 )
    $ sudo /etc/init.d/cron restart
    Поделиться публикацией

    Комментарии 28

      0
      здорово!!! но громоздно — нельзя ли попроще без прописи интерфейсов конфигов итд?
        +1
        если проще и только для браузера то можно ssh -C user@host -D port и прокси прописать в браузере (сокс 127.0.0.1:port) боян конечно, но зато не так сложно :)
          0
          hamachi, remobo
          спасибо автору, теперь я знаю что они мне не нужны.
            0
            нужно, если у вас нет в наличии сервера с реальным IP-адресом.
              0
              есть роутер с линуксом и реальным ip
              я поэтому и сказал, что мне не нужны, а не нужны вовсе
          0
          Я правильно понимаю, что всё это можно организовать без логина под рутом, а через sudo?
          скажем заменить command="/sbin/ifdown tun1;/sbin/ifup tun1" на command=«sudo /path/to/some/script.sh» в котором уже делать всякие гадости от рута?

          п.с. к сожалению самому ковыряться в этом лень, а необходимость логиниться от рута кажется необоснованной.
            0
            Там ничего от юзерского рута не выполняется, кроме как при настройке. Никакиз костылей в виде судо не надо.
              0
              srsly?
              гугл кстати показал оригинал статьи и обсуждение на счёт того как люди пытаются обойти необходимость использовать логин через root'а
              www.debian-administration.org/articles/539#comment_20
            0
            очевидный минус VPN-over-SSH — это требование root-доступа к «серверу». Кроме того, UDP будет тормозить потому что идет по TCP-каналу. Если уж есть root-доступ, то эффективнее поднять openvpn по UPD. А если нет root-доступа, и UDP форвардить не обязательно — то лучше воспользоваться transocks_ev, с ним можно использовать любой «сервер» (=машина с обычным пользовательским аккаунтом, например на работе/в институте) для NAT своего TCP-трафика.
              0
              Это… а смысл?
                –1
                а без рута как вы собираетесь вносить изменения в таблицу маршрутизации?
                реализация интересна, но бестолкова… тот же ipsec давно поддерживается на уровне ядра, а если не требуется шифрование — тот же gre.
                  0
                  ммм, openvpn на мой взгляд проще и понятней, отказоустойчивость нативно реализована, автопроверка линка и прочие удобства. Но все равно спасибо, добавил в избранное, альтернативу никогда не помешает на заметке держать.
                    0
                    tun/tap как правило, нет на vps
                      0
                      tun/tap как правило подключают по запросу, где-то бесплатно, где-то за 3-5 баксов.
                        0
                        Гораздо чаще встречается проблема, когда доступ в Интернет только HTTP 80,443; никаких 22 портов (крупная корпоративная сеть, например). Тут openvpn замечательно помогает.
                      0
                      Мне кажется, или для всего этого есть OpenVPN?
                        0
                        для всего это есть два десятка технологий, а конкретно этот способ вполне может кому-то пригодиться ;)
                        0
                        Предлагаю версию для параноиков, в туннеле OpenVPN сделать ipsec канал, через который сделать вот это самое ssh-шаманство.
                          0
                          ipsec, gre… А если вам открыт только 22-ой порт на сервер, то что вы там городить то собрались? С таким апломбом, как-будто человек не в курсе технологий 10 летней давности. В одном месте использовал, так как настраивал VoIP, а из доступа как раз только ssh и был, с рутовым доступом к серверу, естественно.
                            0
                            чувак, прости, но как-то не вяжутся «вам открыт только 22й порт на сервер» и «из доступа только ссш с рутовыми правами» :)
                              –2
                              Я не «чувак», и на брудершафт с вами не употреблял, прошу учитывать. Все вяжется, если ты настраиваешь и обслуживаешь один сервис для компании, на отдельном сервере.
                            0
                            Опечатка там где «генерируем ключ», наверное все-таки 4 Кбайта
                              0
                              Точно 4 килобита.
                              en.wikipedia.org/wiki/RSA за эту версию и man ssh-keygen говорит про -b
                              Specifies the number of bits in the key to create.
                                0
                                4096 бит, в килобитах измеряется скорость соединения, все остальное в килобайтах
                                  0
                                  1. Хочется придираться — придирайтесь по делу (только вот зачем, на смысл ведь не влияет?). Правильно киби-, а не кило- (потому что в основании 2-ка, а не 10-ка). И как уже сказали бита, а не байта.
                                  2. Ваше последнее утверждение сродни следующему: «в сантиметрах — только деления на линейке, а все остальное измеряется в метрах». На самом же деле, ничего не мешает все измеряемое в байтах измерять и в битах, и наоборот.
                                  3. Если же Вы про традиции, намекая на боды (бит/с), в которых на самом деле измеряют только скорость, то в шифровании использование битов, а не байтов — не менее классический случай.
                              0
                              Круто. У меня в свое время не получилось, так как я хотел обойтись без логина рутом и без судо.
                                0
                                Спасибо, понравилось.
                                Сначала подумал громоздко, потом посмотрел на свою гору «простых» скриптов с пробросом портов на все случаи жизни и… в обще ваш способ наверное будет аккуратнее.
                                  0
                                  Для разовых/временных решений само то. Хотя временно обхожусь пробросом портов через SSH. А на постоянку делаю IPSEC.

                                  К тому же не люблю слоёных пирожков из протоколов (TCP-IP-PPP-SSH-TCP-IP). Хотел было сказать что нужно почитать «Why TCP Over TCP Is A Bad Idea». Но тут же нашёл вменяемое опровержение www.barabanov.ru/arts/tcp/Tcp_over_tcp_is_not_so_bad-web.pdf

                                  ИМХО, основной минус у таких тунелей — они не симметричны. Т.е. они должны быть всегда поднятыми, если со стороны сервера (SSH) создаются TCP соединения. В IPSEC же оба конца тунеля «равноправны».

                                  Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                  Самое читаемое