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

[karabanov]

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

[ValdikSS]

Deprecated Linux networking commands and their replacements

[rekby]

Проверил, шпаргалку в статье поправил.

Спасибо.

[merlin-vrn]

habrahabr.ru/post/48276/ читали?

[rekby]

1. Нет, не читал — статья не выдается при поиске ethernet tunnel и похожих, по которым я искал, читая статью не знаю как бы я мог её найти.
2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.

[ragus]

а вам для каких целей всё это? почему не использовать какой-нибудь ipsec+vxlan?

[rekby]

Есть несколько серверов в разных дата-центрах, на них крутятся виртуальные машины, связь только через общий интернет. Нужно организовать между ними плоскую ethernet-сеть, желательно полносвязную. В идеале несколько независимых сетей (одну для виртуальных машин, другую для связи между собственно серверами, возможно какую-то для изолированной группы виртуальных машин). Сейчас для этого использую tinc — он со своей задачей справляется хорошо, но нагрузка еще маленькая.
В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.

[ragus]

я же говорю vxlan + ipsec. будет безопасно и удобно. разьве что чуть-чуть подумать насчёт мультикаста.

[rekby]

Нашел сравнение vxlan с gre, как я понял vxlan сам умеет разбираться с мультикастом.
Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.

[TerAnYu]

зануда on
Некоторые провайдеры и операторы блокируют GRE, в итоге ничего работать не будет.
зануда off

[ValdikSS]

А еще он иногда не проходит через NAT, и вообще, как и любой прямой туннель, требует белых адресов на обоих сторонах.

[merlin-vrn]

А ещё его можно завернуть в IPSEC и тогда он может даже через NAT проходить, если с NAT-T. И обычно IPSEC провайдеры не блокируют

[AMDmi3]

Для FreeBSD аналогично:

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

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

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

[ragus]

>Для FreeBSD аналогично:

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

[blind_oracle]

ip link add gretap type grelan

Навреное всё таки наоборот — add grelan type gretap

[rekby]

спасибо, поправил.

Сначала там был в обоих местах gretap, потом для наглядности решил названия поменять. В статье поменял правильно, а в шпаргалке ошибся местами.

[dovecot]

Только это IP туллель (L3), а из названия z ожидал Ethernet L2.

[rekby]

Это как раз tap — L2 туннель, IPv4 настраивается как поверх обычной ethernet-сети и в данном случае нужен просто для наглядной проверки того что туннель работает.

[ragus]

такое ощущение, что автор прочитал ман, сделал для себя открытие про L2-туннельчики и поспешил поделиться )))

хотя, я бы предпочёл l2tpv3 pseudowire. оно хотя бы умеет udp-encap и оверхед меньше, чем у gre.

[merlin-vrn]

Всё-таки GRE удобнее. Хотя l2tp v3 настраивается не сложнее.

[ragus]

кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.
т.е. если вы захотите 2 туннеля(например, пару vlan'ов прокинуть) — это будет боль.
да, можно тегированный трафик закинуть внутрь туннеля. но вот такой финт не все устройства могут понять.

[merlin-vrn]

кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.

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

cisco:

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

linux:

более того, я так делал, правда, не с l2 gre как в топике, а с l3 gre

[ragus]

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

а с udp-encap можно туннельчик терминировать на коробке внутри серой сети.

[egorF]

а как насетапить udp-encap под линуксом?

[ragus]

вот как-то так

[egorF]

Спасибо большое, сейчас мне эта инфа очень в тему.

[ComodoHacker]

Вот этот момент раскройте пожалуйста:

Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh)

Вам как-то удалось настроить GRE поверх SSH? :)

[rekby]

Не — наоборот, у меня ssh-соединения внутри GRE-сети.

[ComodoHacker]

Теперь понятно. Но все равно туннель через интернет без шифрования это как-то боязно. Там бродкасты могут ходить всякие, в будущем появятся новые сервисы, да мало ли что.

[rekby]

Да — и broadcast и arp-ответы нужные внедрить можно чтобы трафик через другой IP внутренней сети послать и т.п. В практических целях это потом конечно будет защищаться, сейчас я ищу именно методы организации сети поверх интернета, ipsec насколько я понимаю всегда можно будет добавить.

[merlin-vrn]

Вопрос в тему (сам вообще не пробовал исследовать): NHRP с этим L2 GRE будет работать? Например, NHRP + L3 multipoint GRE в Cisco называется DMVPN; может, он и L2 умеет заодно — так ничего не надо изобретать тогда?

[rekby]

Посмотрел — идея хорошая, но аппаратные маршрутизаторы пока отсутствуют (используется инфраструктура ДЦ).

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

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

[merlin-vrn]

OpenNHRP работает (хотя бы как-то). Его я пробовал. Он умеет DMVPN Phase 1. Циски сами уже научились делать гораздо больше.

DMVPN — это L3. А мы говорим про L2. Вопрос заключался в том, чтобы уметь всё то же, что умеет DMVPN, но на втором уровне, и можно ли для этого частично использовать уже имеющиеся наработки, типа протокола NHRP.

[merlin-vrn]

Впрочем, у меня возникли сомнения в большой полезности бриджевания сетей через интернет. В силу больших задержек передачи и низкой надёжности, такой ethernet-сегмент может работать плохо. Скажем, представьте себе как в одной из сетей работает DHCP-сервер, выдаёт клиенту адрес, а в другой сети у вас уже есть клиент с таким адресом. А не обнаружилось это потому, что ARP-пакет, использовавщийся для проверки, используется ли уже этот адрес, пропал по дороге.

[rekby]

Полезность в том что можно быстро перенести виртуальную машину в другой дата-центр не меняя её настроек, настроек шлюзов и т.п. IP-адреса в моём случае статически связаны с MAC, так что такой конфликт может случиться только если виртуалка стартует в двух местах одновременно, но это должна решать уже не сеть.

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

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

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

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

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