Простой Ethernet-туннель на Linux в четыре-шесть команд

Краткая шпаргалка:
HOST1: ip link add grelan type gretap  local <IP1> remote <IP2>
HOST1: ip link set grelan up
HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
HOST2: ip link add grelan type gretap local <IP2> remote <IP1>
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT


Четыре команды на туннель и две на firewall (не нужны если трафик между своими серверми уже разрешен)
Это всё что нужно, дальше длинное объяснение с подробностями.


Когда требуется объединить несколько компьютеров в псевдолокальную сеть через интернет часто это решается настройкой OpenVPN.

Решение хорошо работает, но не лишено недостатков:
1. Нужно ставить дополнительный софт и его настраивать. Причем с первого раза настраивается он не очень просто — надо посидеть и поразбираться.
2. Шифрование трафика происходит в пользовательском режиме и вносит дополнительные задержки, это не всегда важно но для IP-телефонии может быть заметно.
3. Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh), мне нужна просто удобная плоская адресация между несколькими компьютерами так как будто они объединены в локальную сеть.

В Linux GRE-туннели настраиваются до неприличия просто (если не нужно шифрование), из требований Linux и по публичному IP на каждый.
В интернете на эту тему информации как-то исчезающе мало — в основном объясняются IP (а не ethernet) туннели и сразу вкупе с шифрованием трафика (которое нужно не всегда). man ip тоже очень обширный и информацию по

Пусть у нас есть два хоста:
HOST1 с внешним адресом 1.2.3.4
HOST2 с внешним адресом 2.3.4.5

Хочется сделать между ними ethernet-сеть, ну и для примера поверх нее можно настроить IP-адреса 192.168.0.1 192.168.0.2, но можно и любые другие или IPv6 или что угодно еще — получится обычная сеть как через коммутатор.

Все команды выполняются от ROOT, после перезагрузки — теряются. Чтобы не терялись нужно прописать команды в скрипты автозагрузки или в конфиги (у каждого дистрибутива свои).

1. Добавить виртуальную сетевую карту-шлюз на HOST1:
HOST1: ip link add grelan type gretap local 1.2.3.4 remote 2.3.4.5

На HOST1 он будет выглядеть как обычная сетевая карта — можно назначать IP-адреса, запускать DHCP-сервер, включать в Bridge и т.п.

2. Включить добавленную карту
ip link set grelan up


2. Если запущен IP-tables — разрешаем GRE-трафик
HOST1: iptables -I INPUT -p gre -s 2.3.4.5 -j ACCEPT


3. Симметричная настройка на втором хосте:
HOST2: ip link add grelan type gretap local 2.3.4.5 remote 1.2.3.4
HOST2: ip link set grelan up
HOST2: iptables -I INPUT -p gre -s 1.2.3.4 -j ACCEPT


В этот момент ethernet-сеть уже работает. Для проверки этого можно настроить приватные IP-адреса на каждой стороне туннеля и пустить пинги.
HOST1: ip addr add 192.168.0.1/24
HOST2: ip addr add 192.168.0.2/24


можно пинговать.
root@ubuntu:~# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_req=1 ttl=64 time=2.45 ms
64 bytes from 192.168.0.1: icmp_req=2 ttl=64 time=1.19 ms
64 bytes from 192.168.0.1: icmp_req=3 ttl=64 time=2.45 ms


Для пингов возможно тоже придется добавить правила в iptables (или вообще выключить его на время экспериментов).

Туннель спокойно настраивается между разными версиями linux, пока писал этот пост один конец был на ubuntu, второй на centos, разницы в настройке нет абсолютно никакой.

Повторяю — это туннель не дает никакой защиты от прослушивания/внедрения трафика.
Поделиться публикацией
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

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

    +7
    ifconfig не нужен:

    HOST1: ip link add gretap type grelan local <IP1> remote <IP2>
    HOST1: ip link set grelan up
    HOST1: iptables -I INPUT -p gre -s <IP2> -j ACCEPT
    HOST2: ip link add gretap type grelan local <IP2> remote <IP1>
    HOST2: ip link set grelan up
    HOST2: iptables -I INPUT -p gre -s <IP1> -j ACCEPT
    
    0
      0
      1. Нет, не читал — статья не выдается при поиске ethernet tunnel и похожих, по которым я искал, читая статью не знаю как бы я мог её найти.
      2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.
        +1
        а вам для каких целей всё это? почему не использовать какой-нибудь ipsec+vxlan?
          0
          Есть несколько серверов в разных дата-центрах, на них крутятся виртуальные машины, связь только через общий интернет. Нужно организовать между ними плоскую ethernet-сеть, желательно полносвязную. В идеале несколько независимых сетей (одну для виртуальных машин, другую для связи между собственно серверами, возможно какую-то для изолированной группы виртуальных машин). Сейчас для этого использую tinc — он со своей задачей справляется хорошо, но нагрузка еще маленькая.
          В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.
            +1
            я же говорю vxlan + ipsec. будет безопасно и удобно. разьве что чуть-чуть подумать насчёт мультикаста.
              0
              Нашел сравнение vxlan с gre, как я понял vxlan сам умеет разбираться с мультикастом.
              Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.
      +4
      зануда on
      Некоторые провайдеры и операторы блокируют GRE, в итоге ничего работать не будет.
      зануда off
        +1
        А еще он иногда не проходит через NAT, и вообще, как и любой прямой туннель, требует белых адресов на обоих сторонах.
          +1
          А ещё его можно завернуть в IPSEC и тогда он может даже через NAT проходить, если с NAT-T. И обычно IPSEC провайдеры не блокируют
        –1
        Для FreeBSD аналогично:

        ifconfig gre0 create <локальный IP туннеля> <удалённый IP туннеля> tunnel <IP локального хоста> <IP удалённого хоста>
        

        на другой стороне поменять местами адреса в обеих парах.

        Ещё можно gre0 заменять на gif0 — вместо GRE будет IP-IP инкапсуляция (к слову о провайдерах блокирующих GRE).
          +2
          >Для FreeBSD аналогично:

          плохо, когда люди не видят разницы между L2 & L3. вы этот gre0 попробуйте в бридж добавить.
          +2
          ip link add gretap type grelan

          Навреное всё таки наоборот — add grelan type gretap
            0
            спасибо, поправил.

            Сначала там был в обоих местах gretap, потом для наглядности решил названия поменять. В статье поменял правильно, а в шпаргалке ошибся местами.
            0
            Только это IP туллель (L3), а из названия z ожидал Ethernet L2.
              +2
              Это как раз tap — L2 туннель, IPv4 настраивается как поверх обычной ethernet-сети и в данном случае нужен просто для наглядной проверки того что туннель работает.
              +2
              такое ощущение, что автор прочитал ман, сделал для себя открытие про L2-туннельчики и поспешил поделиться )))

              хотя, я бы предпочёл l2tpv3 pseudowire. оно хотя бы умеет udp-encap и оверхед меньше, чем у gre.
                0
                Всё-таки GRE удобнее. Хотя l2tp v3 настраивается не сложнее.
                  0
                  кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.
                  т.е. если вы захотите 2 туннеля(например, пару vlan'ов прокинуть) — это будет боль.
                  да, можно тегированный трафик закинуть внутрь туннеля. но вот такой финт не все устройства могут понять.
                    0
                    кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.

                    с nat да, а с несколькими тоннелями — никакой боли, у GRE есть tunnel key, разным тоннелям — разные ключи, в топике просто про эту фичу ни слова не сказано. Это вам не ipip.

                    cisco:
                    XXXX(config-if)#tunnel key ?
                      <0-4294967295>  key
                    


                    linux:

                    более того, я так делал, правда, не с l2 gre как в топике, а с l3 gre
                      0
                      про tunnel key я знаю )) но вот в середине может быть какая-нибудь коробочка, которая об этом не знает :)
                      посмотрите на любимый многими pf в openbsd/freebsd. он про это вообще не в курсе =(

                      а с udp-encap можно туннельчик терминировать на коробке внутри серой сети.
                        0
                        а как насетапить udp-encap под линуксом?
              +1
              Вот этот момент раскройте пожалуйста:
              Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh)

              Вам как-то удалось настроить GRE поверх SSH? :)
                0
                Не — наоборот, у меня ssh-соединения внутри GRE-сети.
                  0
                  Теперь понятно. Но все равно туннель через интернет без шифрования это как-то боязно. Там бродкасты могут ходить всякие, в будущем появятся новые сервисы, да мало ли что.
                    0
                    Да — и broadcast и arp-ответы нужные внедрить можно чтобы трафик через другой IP внутренней сети послать и т.п. В практических целях это потом конечно будет защищаться, сейчас я ищу именно методы организации сети поверх интернета, ipsec насколько я понимаю всегда можно будет добавить.
                      0
                      Вопрос в тему (сам вообще не пробовал исследовать): NHRP с этим L2 GRE будет работать? Например, NHRP + L3 multipoint GRE в Cisco называется DMVPN; может, он и L2 умеет заодно — так ничего не надо изобретать тогда?
                        0
                        Посмотрел — идея хорошая, но аппаратные маршрутизаторы пока отсутствуют (используется инфраструктура ДЦ).

                        Есть какая-то программная реализация, кроме sourceforge.net/projects/opennhrp/?source=navbar (с последним коммитом 1.5 года назад и 70-ю скачиваниями)?

                        Сейчас разбираюсь с vxlan. Если всё как я думаю это может быть надежнее NHRP, (т.к. будет отсутствовать центральная точка отказа, раздающая параметры доступа) и удобнее — т.к. vlan поддерживаются нативно, а DMVPN как я понимаю VLAN строить не умеет и всё равно это нужно будет делать отдельно, но в еще одном слое.
                          0
                          OpenNHRP работает (хотя бы как-то). Его я пробовал. Он умеет DMVPN Phase 1. Циски сами уже научились делать гораздо больше.

                          DMVPN — это L3. А мы говорим про L2. Вопрос заключался в том, чтобы уметь всё то же, что умеет DMVPN, но на втором уровне, и можно ли для этого частично использовать уже имеющиеся наработки, типа протокола NHRP.
                            0
                            Впрочем, у меня возникли сомнения в большой полезности бриджевания сетей через интернет. В силу больших задержек передачи и низкой надёжности, такой ethernet-сегмент может работать плохо. Скажем, представьте себе как в одной из сетей работает DHCP-сервер, выдаёт клиенту адрес, а в другой сети у вас уже есть клиент с таким адресом. А не обнаружилось это потому, что ARP-пакет, использовавщийся для проверки, используется ли уже этот адрес, пропал по дороге.
                              0
                              Полезность в том что можно быстро перенести виртуальную машину в другой дата-центр не меняя её настроек, настроек шлюзов и т.п. IP-адреса в моём случае статически связаны с MAC, так что такой конфликт может случиться только если виртуалка стартует в двух местах одновременно, но это должна решать уже не сеть.

                              Как альтернативу рассматривал варианты OSPF с маршрутами с точностью до IP-адреса, но по результатам изучения сети сложилось мнение что OSPF в этом контексте ведет себя плохо при росте количества маршрутов.

                              Еще одна альтернатива — закреплять сетки адресов за физическими сереверами, а при переезде виртуалки прописывать фиксированный маршрут только до неё, потом либо виртуалку на место возвращать либо IP-адрес у неё менять. Это облегчит работу OSPF, но усложнит поддержку.

                              Пока что самым правильным вариантом вижу большую сеть логически плоскую, физически — полносвязную через туннели.
                              Если сеть станет слишком большой — можно фильтровать часть ненужного широковещательного трафика или сделать еще одну сеть в соседнем vlan на тех же туннелях.

                              Пока из теории мне больше всего приглянулся vxlan — как я понял он умеет сам разбираться куда пакеты слать и сдать будет сразу правильно, а не по STP-дереву если просто GRE на бриджах сделать.

                              Еще вариант, который я рассматривал пока ragus про vxlan не подсказал: много GRE-туннелей и маршрутизация самостоятельно скриптами при изменении топологии.

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

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