По-моему заголовок не соответствует содержанию: читая «Построение собственной коммуникационной сети» я предполагаю увидеть внутри что-то именно про сеть, т.е. какую-то базовую вещь, которой потом сможет пользоваться остальное ПО, т.е. в большинстве случаев это IP или Ethernet сеть, возможно какая-то другая но тоже базовая — которой потом сможет пользоваться какая-то программа которая ничего не знает про I2P. Тут получается очень специализированная вещь только для программы которая будет специально под этот протокол написана.
По сути:
Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов. А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
По опыту использования I2P у меня сложилось мнение о таких неудобствах:
1. Высокая латентность
2. Ограниченное использование существующего ПО — как я помню там или соединения точка-точка через socks-прокси или http через http-прокси, либо уже что-то специальное.
Отчасти можно побудить пингами и перестроением тоннелей, хотя я с таким на практике не сталкивался — спокойно бродил по внутренним сайтам без каких-то явно больших задержек.
Что хочется:
Вот хорошо бы решить эту задачу — т.е. построение сети общего назначения: собственный VPN (IP/Ethernet) или какая-то более широкая IP-сеть. Чтобы участники этой сети могли просто подключить в компьютер дополнительный сетевой адаптер и например там между собой смогли бы общаться Jabber-сервера по обычному протоколу, Seafile-хранилища, можно было бы стандартными средствами попинговать узел чтобы понять жив ли он или например выходить в интернет через какой-то шлюз без заворачивания трафика на http-прокси а просто обычной настройкой маршрутизации или подключением к какому-то VPN-серверу опять же обычными средствами.
При этом реализация на стороне клиента обеспечивала бы хождение трафика P2P без участия центральных серверов, а центральные сервера занимались бы распределением IP-адресов и указанием соответствия. Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую.
Полезность в том что можно быстро перенести виртуальную машину в другой дата-центр не меняя её настроек, настроек шлюзов и т.п. IP-адреса в моём случае статически связаны с MAC, так что такой конфликт может случиться только если виртуалка стартует в двух местах одновременно, но это должна решать уже не сеть.
Как альтернативу рассматривал варианты OSPF с маршрутами с точностью до IP-адреса, но по результатам изучения сети сложилось мнение что OSPF в этом контексте ведет себя плохо при росте количества маршрутов.
Еще одна альтернатива — закреплять сетки адресов за физическими сереверами, а при переезде виртуалки прописывать фиксированный маршрут только до неё, потом либо виртуалку на место возвращать либо IP-адрес у неё менять. Это облегчит работу OSPF, но усложнит поддержку.
Пока что самым правильным вариантом вижу большую сеть логически плоскую, физически — полносвязную через туннели.
Если сеть станет слишком большой — можно фильтровать часть ненужного широковещательного трафика или сделать еще одну сеть в соседнем vlan на тех же туннелях.
Пока из теории мне больше всего приглянулся vxlan — как я понял он умеет сам разбираться куда пакеты слать и сдать будет сразу правильно, а не по STP-дереву если просто GRE на бриджах сделать.
Еще вариант, который я рассматривал пока ragus про vxlan не подсказал: много GRE-туннелей и маршрутизация самостоятельно скриптами при изменении топологии.
Сейчас разбираюсь с vxlan. Если всё как я думаю это может быть надежнее NHRP, (т.к. будет отсутствовать центральная точка отказа, раздающая параметры доступа) и удобнее — т.к. vlan поддерживаются нативно, а DMVPN как я понимаю VLAN строить не умеет и всё равно это нужно будет делать отдельно, но в еще одном слое.
Да — и broadcast и arp-ответы нужные внедрить можно чтобы трафик через другой IP внутренней сети послать и т.п. В практических целях это потом конечно будет защищаться, сейчас я ищу именно методы организации сети поверх интернета, ipsec насколько я понимаю всегда можно будет добавить.
Нашел сравнение vxlan с gre, как я понял vxlan сам умеет разбираться с мультикастом.
Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.
Есть несколько серверов в разных дата-центрах, на них крутятся виртуальные машины, связь только через общий интернет. Нужно организовать между ними плоскую ethernet-сеть, желательно полносвязную. В идеале несколько независимых сетей (одну для виртуальных машин, другую для связи между собственно серверами, возможно какую-то для изолированной группы виртуальных машин). Сейчас для этого использую tinc — он со своей задачей справляется хорошо, но нагрузка еще маленькая.
В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.
Это как раз tap — L2 туннель, IPv4 настраивается как поверх обычной ethernet-сети и в данном случае нужен просто для наглядной проверки того что туннель работает.
1. Нет, не читал — статья не выдается при поиске ethernet tunnel и похожих, по которым я искал, читая статью не знаю как бы я мог её найти.
2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.
По сути:
Как я понял — основная причина построения сети — повышение стабильности за счет раннего обнаружения отказов промежуточных узлов. А чем эта система лучше, чем отправка сообщение alive при tcp-соединениях через socks-прокси для I2P или каких-то пингов на уровне собственного приложения поверх обычной I2P сети, без использования специальных серверов?
По опыту использования I2P у меня сложилось мнение о таких неудобствах:
1. Высокая латентность
2. Ограниченное использование существующего ПО — как я помню там или соединения точка-точка через socks-прокси или http через http-прокси, либо уже что-то специальное.
Отчасти можно побудить пингами и перестроением тоннелей, хотя я с таким на практике не сталкивался — спокойно бродил по внутренним сайтам без каких-то явно больших задержек.
Что хочется:
Вот хорошо бы решить эту задачу — т.е. построение сети общего назначения: собственный VPN (IP/Ethernet) или какая-то более широкая IP-сеть. Чтобы участники этой сети могли просто подключить в компьютер дополнительный сетевой адаптер и например там между собой смогли бы общаться Jabber-сервера по обычному протоколу, Seafile-хранилища, можно было бы стандартными средствами попинговать узел чтобы понять жив ли он или например выходить в интернет через какой-то шлюз без заворачивания трафика на http-прокси а просто обычной настройкой маршрутизации или подключением к какому-то VPN-серверу опять же обычными средствами.
При этом реализация на стороне клиента обеспечивала бы хождение трафика P2P без участия центральных серверов, а центральные сервера занимались бы распределением IP-адресов и указанием соответствия. Условно что сейчас IP 1.2.3.4 соответствует I2P адресу abcd и дальше обмен трафиком между ними идет уже напрямую.
Спасибо.
Как альтернативу рассматривал варианты OSPF с маршрутами с точностью до IP-адреса, но по результатам изучения сети сложилось мнение что OSPF в этом контексте ведет себя плохо при росте количества маршрутов.
Еще одна альтернатива — закреплять сетки адресов за физическими сереверами, а при переезде виртуалки прописывать фиксированный маршрут только до неё, потом либо виртуалку на место возвращать либо IP-адрес у неё менять. Это облегчит работу OSPF, но усложнит поддержку.
Пока что самым правильным вариантом вижу большую сеть логически плоскую, физически — полносвязную через туннели.
Если сеть станет слишком большой — можно фильтровать часть ненужного широковещательного трафика или сделать еще одну сеть в соседнем vlan на тех же туннелях.
Пока из теории мне больше всего приглянулся vxlan — как я понял он умеет сам разбираться куда пакеты слать и сдать будет сразу правильно, а не по STP-дереву если просто GRE на бриджах сделать.
Еще вариант, который я рассматривал пока ragus про vxlan не подсказал: много GRE-туннелей и маршрутизация самостоятельно скриптами при изменении топологии.
Есть какая-то программная реализация, кроме sourceforge.net/projects/opennhrp/?source=navbar (с последним коммитом 1.5 года назад и 70-ю скачиваниями)?
Сейчас разбираюсь с vxlan. Если всё как я думаю это может быть надежнее NHRP, (т.к. будет отсутствовать центральная точка отказа, раздающая параметры доступа) и удобнее — т.к. vlan поддерживаются нативно, а DMVPN как я понимаю VLAN строить не умеет и всё равно это нужно будет делать отдельно, но в еще одном слое.
Протокол интересный, нужно поискать как настраивается и попробовать. Если он еще сам умеет с маршрутами разбираться — это как раз то что нужно, а то я уже подумывал как к этому OSPF прикрутить с маршрутизацией на индивидуальные адреса или вообще просто скриптами статические маршруты прописывать.
В неспешном режиме изучаю варианты тунелей, реализованные в ядре — на случай когда нагрузка вырастет и tinc будет работать нестабильно и/или медленно, ну и так — для общего развития.
Сначала там был в обоих местах gretap, потом для наглядности решил названия поменять. В статье поменял правильно, а в шпаргалке ошибся местами.
2. Как я понял там маршрутизация на 3-м уровне (IP), мне нужна на втором. В частности на каждой машине в бридж с gre-туннелем могут включаться виртуальные машины, для которых всё выглядит как одна плоская локальная сеть. С mgre как я понял из статьи такого не получится. Надо поизучать умеет ли туннелироваться в этом режиме ethernet-трафик.