The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Ethernet поверх UDP туннеля. На три и более точек. (tunnel ethernet udp freebsd netgraph)


<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>
Ключевые слова: tunnel, ethernet, udp, freebsd, netgraph,  (найти похожие документы)
From: Alexisss <alexiss-xz@yandex.ru.> Newsgroups: mail Date: Mon, 25 Apr 2006 14:31:37 +0000 (UTC) Subject: Ethernet поверх UDP туннеля. На три и более точек. Готовое решение для обьединения трех отдельных локалок с разными провайдерами в единую сеть. Эта задачка достаточно просто решается с помощью NEТGRAPH Исходные данные: 1. есть три офиса в каждом из офисов локалка 192.168.210.0/24 2. каждая локалка ходит в интернет через nat+ipfw FreeBSD 4.3 3. в каждом из офисов свой провайдер. Задача: 1. сделать, чтобы все клиенты локалок могли пользоваться сетевыми дисками и принтерами независимо от того в каком из офисов они находятся. Решение: 1. вкрутил в каждый из шлюзовых компов по еще одной сетевухе (кроме двух уже имеющихся) fxp0 - подключена к провайдеру rl0 - gateway для локальных компов rl1 - без адреса подключена к свичу офисной локалки. 2. Перекомпилил кернел с опциями options NETGRAPH options NETGRAPH_SOCKET options NETGRAPH_ECHO 3. Настроил NETGRAPH в главном офисе (будет выполнять функции сервера ethernet тунелей поверх UDP) запускающий скриптик: #!/bin/sh #Загружаю драйвера узлов моста и сетевухи /sbin/kldload ng_ether /sbin/kldload ng_bridge # создаю узел типа ng_bridge и подключаю хук link0 к хуку lower сетевухи (lower - физ уровень передачи данных) /usr/sbin/ngctl mkpeer rl1: bridge lower link0 # обзываю созданный узел multi_link /usr/sbin/ngctl name rl1:lower multi_link # создаю узел тип:ksocket, транспорт:UDP и цепляю его хук на link1 моста /usr/sbin/ngctl mkpeer multi_link: ksocket link1 inet/dgram/udp # обзываю созданный узел lnk1 /usr/sbin/ngctl name multi_link:link1 lnk1 # создаю сокет на IP выданном провайдером /usr/sbin/ngctl msg lnk1: bind inet/81.111.111.31:2515 # соединяюсь с сокетом (созданным ниже) во втором офисе /usr/sbin/ngctl msg lnk1: connect inet/194.186.121.99:2515 # создаю узел тип:ksocket, транспорт:UDP и цепляю его хук на link2 моста /usr/sbin/ngctl mkpeer multi_link: ksocket link2 inet/dgram/udp # обзываю созданный узел lnk2 /usr/sbin/ngctl name multi_link:link2 lnk2 # создаю сокет на IP выданном провайдером но уже с другим портом /usr/sbin/ngctl msg lnk2: bind inet/81.111.111.31:2516 # соединяюсь с сокетом (созданным ниже) во втором офисе /usr/sbin/ngctl msg lnk2: connect inet/61.16.121.100:2516 # Поднимаю интефейс ifconfig rl1 up # Ввожу интерфейс в promission mode /usr/sbin/ngctl msg rl1: setpromisc 1 # отключаю перезапись src адреса в заголовке пакета при прохождении интерфейса /usr/sbin/ngctl msg rl1: setautosrc 0 4. Настраиваю NETGRAPH во втором и третьем офисе здесь запускающие скрипты будут анологичны #!/bin/sh # загрузка драйвера ng_ether kldload ng_ether # создаю узел тип:ksocket hook:сеть физ уровень транспорт:UDP ngctl mkpeer rl1: ksocket lower inet/dgram/udp # создаю сокет на внешнем IP ngctl msg rl1:lower bind inet/194.186.121.99:2515 # подключаюсь к сокету на сервере (см п.3) ngctl msg rl1:lower connect inet/81.111.111.31:2515 # Поднимаем интерфейс без ip ifconfig rl1 up # Ввожу интерфейс в promission mode ngctl msg rl1: setpromisc 1 # отключаю перезапись src адреса в заголовке пакета при прохождении интерфейса ngctl msg rl1: setautosrc 0 в третем офисе все аналогично: #!/bin/sh # загрузка драйвера ng_ether kldload ng_ether # создаю узел тип:ksocket hook:сеть физ уровень транспорт:UDP ngctl mkpeer rl1: ksocket lower inet/dgram/udp # создаю сокет на внешнем IP ngctl msg rl1:lower bind inet/61.16.121.100:2516 # подключаюсь ко второму сокету на сервере (см п.3) ngctl msg rl1:lower connect inet/81.111.111.31:2516 # Поднимаем интерфейс без ip ifconfig rl1 up # Ввожу интерфейс в promission mode ngctl msg rl1: setpromisc 1 # отключаю перезапись src адреса в заголовке пакета при прохождении интерфейса ngctl msg rl1: setautosrc 0 5. полученные скрипты размещаем в /usr/local/etc/rc.d и наслаждаемся Пара замечаний: 1. само собой в каждой из локалок не должно быть повторяющихся ip адресов 2. все это имеет смысл только при скоростном, синхронном, безлимитном интернете. Особая благодарность http://forum.bestcom.ru/index.php?showforum=7 за помощь в настройке...

<< Предыдущая ИНДЕКС Правка src / Печать Следующая >>

Обсуждение [ Линейный режим | Показать все | RSS ]
  • 1.1, Павел (??), 12:28, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Интерсно, зачем так мучаться, если есть VPN
    Тот же самый OpenVPN, при его использовании можно использовать разные платформы, да и про безопасность забывать не стоит...
     
  • 1.2, Судья (?), 12:55, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Нет, OpenVPN это для тех кто IPSEC прикручивать не умеет, или для линуксоидов где для работы с IPSEC надо настойчиво шаманить с бубном
     
     
  • 2.3, kot (??), 13:19, 25/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    Интересно, а как уважаемый Судья, использую IPSEC сделает bridge соединение двух или более разрозненных сеток?

    Имхо, статья представляет теоретический инетерес в области netgraph, на практике же, plain траффик это не серьезно, хотя бы только потому что men in the middle без напрягов становится пользователем внутренней локальной сети.
    Средствами openvpn аналогичная задача решается "качественнее".

     
  • 2.8, ik_5 (??), 19:30, 25/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    не надо гнать здесь уважаемый,
    одно из преимуществ openvpn - то что он работал и работает на машинах где есть еще и NAT, в отличие от ipsec.
     
     
  • 3.10, BB (??), 15:38, 26/04/2006 [^] [^^] [^^^] [ответить]  
  • +/
    аналогично, то есть не надо гнать, ipsec великолепно работает и из-за NAT и с NAT вместе :)
     

  • 1.4, alexisss (ok), 14:54, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А каким образом он может стать пользователем локалки?
    Все подключения жестко привязаны по портам и IP...
    Весь ethernet траффик пакуеться в UDP и в свободном виде не присутствует....

    Где дырка?

     
  • 1.5, Defender (??), 15:01, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Дарка в том, что он как "траффик пакуеться в UDP" так он от туда и распаковывается.
    Причём без особых усилий...
     
  • 1.6, nuclight (?), 15:56, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А зачем ему третья сетевуха понадобилась, нельзя было без неё что ли обойтись?
     
  • 1.7, Павел (??), 17:31, 25/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    С точки зрения прознания netgraph статья тоже не годиться, т.к. теории никакой абсолютно.
    Я бы такое ни в коем случае у себя не сделал...
    Этож где видано, чтобы корпоративные данные летали по инету нешифрованными :)
     
  • 1.9, NoName (?), 09:51, 26/04/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Эх... что за народ пошел... называют Ethernet-ом все что не попадя..
    К сведению:
    http://ru.wikipedia.org/wiki/Ethernet
    А теперь прочитайте внимательно что Вы написали!
     
  • 1.11, Maxim (??), 06:36, 02/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Статья вредная. Особой теории нет, а то что на практике даже - на это даже ссылаться опасно .
    Связь между тремя офисами без шифрования (это основной недостаток). То что пакуется в UDP это не решение, это как пароль написать на открытке и отправить почтой. Кто захочет - тот прочитает.
    Непонятно зачем нужна третья сетевая карта(которая даже не имеет собственного адреса но подключается к свичу)

    Интересно, а начальство фирмы знает про схему работы?

    PS Решением была бы организация VPN между офисами( например на основе IPSEC, mpd или OpenVPN)

     
  • 1.12, ViRuZzz (??), 10:49, 06/05/2006 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Maxim, Полносью с вами не согласен. Если Вы такое написли, значит вы совершенно не поняли суть проблемы.
    1. Отдельная сетевуха, я думаю, потому, что так нагляднее. Нету IP адреса, это потомоу, что там будет Brigde (Мост). Т.е. IP там не нужен. Это не маршрутизатор.
    2. Я не вижу  проблемы пакеты, упаковыанные в UDP, гнать через IPSec. Мало-ди какая у него ситуация, может ему не нужно жифрование?
    Для соединения офисов, конечно, вариант не очень удачный, но в некоторых местах, абсолютно необходим Layer2 между удаленными точками, вот тут, как раз, и нужно такое решение.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру