Comments 35
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
habrahabr.ru/post/48276/ читали?
1. Нет, не читал — статья не выдается при поиске ethernet tunnel и похожих, по которым я искал, читая статью не знаю как бы я мог её найти.
2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.
2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.
а вам для каких целей всё это? почему не использовать какой-нибудь ipsec+vxlan?
Есть несколько серверов в разных дата-центрах, на них крутятся виртуальные машины, связь только через общий интернет. Нужно организовать между ними плоскую ethernet-сеть, желательно полносвязную. В идеале несколько независимых сетей (одну для виртуальных машин, другую для связи между собственно серверами, возможно какую-то для изолированной группы виртуальных машин). Сейчас для этого использую tinc — он со своей задачей справляется хорошо, но нагрузка еще маленькая.
В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.
В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.
я же говорю vxlan + ipsec. будет безопасно и удобно. разьве что чуть-чуть подумать насчёт мультикаста.
Нашел сравнение vxlan с gre, как я понял vxlan сам умеет разбираться с мультикастом.
Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.
Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.
зануда on
Некоторые провайдеры и операторы блокируют GRE, в итоге ничего работать не будет.
зануда off
Некоторые провайдеры и операторы блокируют GRE, в итоге ничего работать не будет.
зануда off
Для FreeBSD аналогично:
на другой стороне поменять местами адреса в обеих парах.
Ещё можно gre0 заменять на gif0 — вместо GRE будет IP-IP инкапсуляция (к слову о провайдерах блокирующих GRE).
ifconfig gre0 create <локальный IP туннеля> <удалённый IP туннеля> tunnel <IP локального хоста> <IP удалённого хоста>
на другой стороне поменять местами адреса в обеих парах.
Ещё можно gre0 заменять на gif0 — вместо GRE будет IP-IP инкапсуляция (к слову о провайдерах блокирующих GRE).
ip link add gretap type grelan
Навреное всё таки наоборот — add grelan type gretap
Только это IP туллель (L3), а из названия z ожидал Ethernet L2.
такое ощущение, что автор прочитал ман, сделал для себя открытие про L2-туннельчики и поспешил поделиться )))
хотя, я бы предпочёл l2tpv3 pseudowire. оно хотя бы умеет udp-encap и оверхед меньше, чем у gre.
хотя, я бы предпочёл l2tpv3 pseudowire. оно хотя бы умеет udp-encap и оверхед меньше, чем у gre.
Всё-таки GRE удобнее. Хотя l2tp v3 настраивается не сложнее.
кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.
т.е. если вы захотите 2 туннеля(например, пару vlan'ов прокинуть) — это будет боль.
да, можно тегированный трафик закинуть внутрь туннеля. но вот такой финт не все устройства могут понять.
т.е. если вы захотите 2 туннеля(например, пару vlan'ов прокинуть) — это будет боль.
да, можно тегированный трафик закинуть внутрь туннеля. но вот такой финт не все устройства могут понять.
кому как… основные минусы — это проблемы с nat и боль, если надо несколько туннелей на 1 адрес.
с nat да, а с несколькими тоннелями — никакой боли, у GRE есть tunnel key, разным тоннелям — разные ключи, в топике просто про эту фичу ни слова не сказано. Это вам не ipip.
cisco:
XXXX(config-if)#tunnel key ? <0-4294967295> key
linux:
более того, я так делал, правда, не с l2 gre как в топике, а с l3 gre
про tunnel key я знаю )) но вот в середине может быть какая-нибудь коробочка, которая об этом не знает :)
посмотрите на любимый многими pf в openbsd/freebsd. он про это вообще не в курсе =(
а с udp-encap можно туннельчик терминировать на коробке внутри серой сети.
посмотрите на любимый многими pf в openbsd/freebsd. он про это вообще не в курсе =(
а с udp-encap можно туннельчик терминировать на коробке внутри серой сети.
Вот этот момент раскройте пожалуйста:
Вам как-то удалось настроить GRE поверх SSH? :)
Шифрование не всегда нужно. Например в моем случае все соединения и так защищенные (ssh)
Вам как-то удалось настроить GRE поверх SSH? :)
Не — наоборот, у меня ssh-соединения внутри GRE-сети.
Теперь понятно. Но все равно туннель через интернет без шифрования это как-то боязно. Там бродкасты могут ходить всякие, в будущем появятся новые сервисы, да мало ли что.
Да — и broadcast и arp-ответы нужные внедрить можно чтобы трафик через другой IP внутренней сети послать и т.п. В практических целях это потом конечно будет защищаться, сейчас я ищу именно методы организации сети поверх интернета, ipsec насколько я понимаю всегда можно будет добавить.
Вопрос в тему (сам вообще не пробовал исследовать): NHRP с этим L2 GRE будет работать? Например, NHRP + L3 multipoint GRE в Cisco называется DMVPN; может, он и L2 умеет заодно — так ничего не надо изобретать тогда?
Посмотрел — идея хорошая, но аппаратные маршрутизаторы пока отсутствуют (используется инфраструктура ДЦ).
Есть какая-то программная реализация, кроме sourceforge.net/projects/opennhrp/?source=navbar (с последним коммитом 1.5 года назад и 70-ю скачиваниями)?
Сейчас разбираюсь с vxlan. Если всё как я думаю это может быть надежнее NHRP, (т.к. будет отсутствовать центральная точка отказа, раздающая параметры доступа) и удобнее — т.к. vlan поддерживаются нативно, а DMVPN как я понимаю VLAN строить не умеет и всё равно это нужно будет делать отдельно, но в еще одном слое.
Есть какая-то программная реализация, кроме sourceforge.net/projects/opennhrp/?source=navbar (с последним коммитом 1.5 года назад и 70-ю скачиваниями)?
Сейчас разбираюсь с vxlan. Если всё как я думаю это может быть надежнее NHRP, (т.к. будет отсутствовать центральная точка отказа, раздающая параметры доступа) и удобнее — т.к. vlan поддерживаются нативно, а DMVPN как я понимаю VLAN строить не умеет и всё равно это нужно будет делать отдельно, но в еще одном слое.
OpenNHRP работает (хотя бы как-то). Его я пробовал. Он умеет DMVPN Phase 1. Циски сами уже научились делать гораздо больше.
DMVPN — это L3. А мы говорим про L2. Вопрос заключался в том, чтобы уметь всё то же, что умеет DMVPN, но на втором уровне, и можно ли для этого частично использовать уже имеющиеся наработки, типа протокола NHRP.
DMVPN — это L3. А мы говорим про L2. Вопрос заключался в том, чтобы уметь всё то же, что умеет DMVPN, но на втором уровне, и можно ли для этого частично использовать уже имеющиеся наработки, типа протокола NHRP.
Впрочем, у меня возникли сомнения в большой полезности бриджевания сетей через интернет. В силу больших задержек передачи и низкой надёжности, такой ethernet-сегмент может работать плохо. Скажем, представьте себе как в одной из сетей работает DHCP-сервер, выдаёт клиенту адрес, а в другой сети у вас уже есть клиент с таким адресом. А не обнаружилось это потому, что ARP-пакет, использовавщийся для проверки, используется ли уже этот адрес, пропал по дороге.
Полезность в том что можно быстро перенести виртуальную машину в другой дата-центр не меняя её настроек, настроек шлюзов и т.п. IP-адреса в моём случае статически связаны с MAC, так что такой конфликт может случиться только если виртуалка стартует в двух местах одновременно, но это должна решать уже не сеть.
Как альтернативу рассматривал варианты OSPF с маршрутами с точностью до IP-адреса, но по результатам изучения сети сложилось мнение что OSPF в этом контексте ведет себя плохо при росте количества маршрутов.
Еще одна альтернатива — закреплять сетки адресов за физическими сереверами, а при переезде виртуалки прописывать фиксированный маршрут только до неё, потом либо виртуалку на место возвращать либо IP-адрес у неё менять. Это облегчит работу OSPF, но усложнит поддержку.
Пока что самым правильным вариантом вижу большую сеть логически плоскую, физически — полносвязную через туннели.
Если сеть станет слишком большой — можно фильтровать часть ненужного широковещательного трафика или сделать еще одну сеть в соседнем vlan на тех же туннелях.
Пока из теории мне больше всего приглянулся vxlan — как я понял он умеет сам разбираться куда пакеты слать и сдать будет сразу правильно, а не по STP-дереву если просто GRE на бриджах сделать.
Еще вариант, который я рассматривал пока ragus про vxlan не подсказал: много GRE-туннелей и маршрутизация самостоятельно скриптами при изменении топологии.
Как альтернативу рассматривал варианты OSPF с маршрутами с точностью до IP-адреса, но по результатам изучения сети сложилось мнение что OSPF в этом контексте ведет себя плохо при росте количества маршрутов.
Еще одна альтернатива — закреплять сетки адресов за физическими сереверами, а при переезде виртуалки прописывать фиксированный маршрут только до неё, потом либо виртуалку на место возвращать либо IP-адрес у неё менять. Это облегчит работу OSPF, но усложнит поддержку.
Пока что самым правильным вариантом вижу большую сеть логически плоскую, физически — полносвязную через туннели.
Если сеть станет слишком большой — можно фильтровать часть ненужного широковещательного трафика или сделать еще одну сеть в соседнем vlan на тех же туннелях.
Пока из теории мне больше всего приглянулся vxlan — как я понял он умеет сам разбираться куда пакеты слать и сдать будет сразу правильно, а не по STP-дереву если просто GRE на бриджах сделать.
Еще вариант, который я рассматривал пока ragus про vxlan не подсказал: много GRE-туннелей и маршрутизация самостоятельно скриптами при изменении топологии.
Sign up to leave a comment.
Простой Ethernet-туннель на Linux в четыре-шесть команд