Proxy Arp для управления

[N.Leiten 89]

Вот идея всплыла недавно, на фоне реформирования своей сети. Решил поделиться.

 

1. В общем по стандартам, точнее чтобы правильно всё работало и было меньше проблем нужно строить сеть или на управляемых свитчах (достаточно дорого для начального уровня) или соблюдать топологию и строить гирлянду в надежде на будущую формацию. Естественно как вариант полной управляемости - это сеть WAN разделенная по LAN и между ними роутеры (маршрутизация третьего уровня с разделением по подсетям). Или тот же WAN, только между локальными сегментами ставить очень умные свитчи.

Это было вступление.

 

2. Теперь об интересном. (практика)

Чаще всего возникают вопросы - "есть у меня лока на N человек и есть за горизонтом у друга локалка с M человек - как объединить дешево".

Естественно, легко догадатся, что сразу предлагается радио. Небеспочвенно - дешево, и расстояние покрыть можно любое (компромисс скорость/расстояние, остальное дело прямых рук). Всё красиво, пока таких ситуаций не больше пяти и физических абонентов не больше сотни. Потом эта вся сеть просто переворачивается вверх тормашками и мило умирает. Управляемости ноль, зато работает Vypress и сетевое окружение

При этом по pppoe прекрасно можно раздавать интернет. А можно и по PoPToP

 

3. Теперь неинтересное. (теория)

Дабы не входить в споры что лучше/хуже (смотрим введение). Отказываемся от широковещательного трафика (полностью). То есть забываем о вайпрессах, насси и обязательно о сетевом окружении. Точка. К чему в данном случае мы приходим? Конечно - или роутеры или дорогие свитчи (последнее оставляем на будущее, когда в кармане будут деньги). Остаются роутеры.

Самое интересное, что роутеры подразумевают разные подсети в сегментах маршрутизации (мы должны разделять физически все сегменты, чтоб широковещательный трафик не бегал). А с ними и прописывание маршрутов у клиентов (именно прописывание, т.к. основной шлюз у нас уже в ВПН задействован для выхода в интернет). То есть мы должны прибежать к каждому абоненту, прописать статический маршрут. При этом мы обязательно теряем одну очень важную деталь – управляемость с точки зрения айпи-адресов. То есть выгодней и удобней всего иметь DHCP сервер, который автоматически всё раздаст (или по указаному мак-адресу или по диапазону). То есть при возникновении проблем – не нужно бежать к абонентам и у каждого менять айпи-адреса с маршрутами. Для сети, в которой до 100 абонентов можно и побегать (расстянув удовольствие на месяц-два). Для сети с количеством абонентов 300, 400, наконец 1000 ненабегаешься – проще подправить конфиги на сервере DHCP. (для точности стоит заметить – в больших сетях именно так всё и работает). К чему я заговорил о DHCP? Очень просто. Мы хотим строить сеть правильно с самого начала (введение), чтобы при покупке умных свитчей и реформировании сети это не сказалось на конечных абонентах и ваших нервных клетках.

 

4. Отступление.

Имею практику работы с маршрутизаторами и статическими маршрутами – очень неудобно ручками всё вбивать, если у тебя в цепочке стоит больше пяти роутеров. Поднимать же ospf/bgp/zebra имеет смысл, если уверен в стабильности каналов. А когда мы рассматриваем реальный вариант (пункт 2), когда дешево и сердито (очень сердито и зло, я бы сказал) строится сеть. Любой потерянный пакетик с данными о маршрутизации может завалить всю сеть. На дешевом оборудовании сложно построить радиолинк без потерь, тем более в наше время загаженных радиоэфиров.

 

 

5. Теперь о главном.

Что даёт нам роутер – он даёт возможность фаерволинга (если это линукс/бсд, то думаю и так всё понятно, а кроме *никс на эту роль ничего другое не подойдет, увы – фактор мы выбрали – дешевизна, а это и оборудование). Плюс очень вкусно использовать шейпинг – зарезал абонента на мегабит или на 10 мегабит и вполне спокойно можно предоставлять услуги дальше.

И непосредственно главное – причем здесь ProxyARP. Думаю уже и так всё понятно. Делаем сеть, например 180.22.0.0/16 и делим по сегментам. Объединяем радиолинками р2р с роутерами с proxyARP+DHCP+Shaper/Firewall и вполне вменяемая/управляемая сеть готова. На каждый сегмент, выдаем, например, /24 подсеть и маршрутизируем на роутерах куда и что надо. Самое главное – у абонентов ничего прописывать не нужно, ARP запросы прекрасно всё выполнят за вас.

 

6. Теперь о грустном. (специфика)

Тонкие моменты использования ВПН. Те кто знают – подтвердят: в pppoe есть проблемка – она не терпит шлюзов. Точнее терпит, правда только один и тот должен быть с pppoe-relay демоном висеть. В данной структуре сети проблематично вести ВПН-туннель основанный на pppoe в единый центр. То есть еще одно ограничение – используем PoPToP (о других VPN ничего сказать не могу – не изучал/не знаю).

 

7. Вывод.

Имея сеть WAN, формально с гирляндой LAN подсетей в разные стороны с роутерами в режиме ProxyARP получаем псевдо-прозрачное соединение. Имеем управляемость на границе каждого сегмента. Управляемость с точки зрения администрирования (определение айпи-подсетей, используя DHCP). И, самое главное, легкость при реформировании сети в будущем – нам не нужно бегать к абонентам, они продолжат работать и дальше.

Минусы в данной ситуации тоже есть.

Непосредственно в ВПН (выше описано). Производительность роутеров (если мы используем проводной сегмент и только провод, то PCrouter должен быть мощным, чтоб маршрутизировать нормально поток данных и поток пакетов). Но, учитывая что на практике у нас магистралью выступает радиолинк, скорость которого редко превышает 25мбит, то сполне спокойно с маршрутизацией может справится не самый последний ПиСишник. А теперь интрига – достаточно много оборудования беспроводного уже умеет режим роутера и внутри держит линукс – мысль можно продолжить… Переносим роутер, фаервол/шейпер/dhcp на точку доступа и получаем идеал сети с минимум вкладов.

 

8. Post Scriptum

Прошу оценить идею и высказать свое мнение/замечание.

Обращаю внимание – идея такой сети пришла в голову в связи использованием и написанием прошивки для точек доступа DWL-G700ap с роутером и всеми вышеперечисленными возможностями. Стоимость точек доступа около 50уе, что очень неплохо. Для бюджетного варианта использования как раз подходит.

[N.Leiten 89]

Одиннадцать человек просмотрело Оцените идею, как она вам.

 

Могу дополнить, что в данном случае у клиентов выдается подсеть всей сети. И каждый абонент считает, что видит физически всю сеть, хотя на самом деле это не так.

ЗЫ. У себя точно такое уже буду внедрять. Протестировал на точке доступа с прошивкой Wive - работает

[kvirtu 315]

В принипе все правильно изложено

[p0int 0]

как вариант прокси арпа можно использоваться ip-sentinel достаточно удобно

[Profi the same 1]

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

[Den_LocalNet 1 474]

ИМХО FreeBSD в режиме бриджа решает вопрос проще (совсем прозрачно, не менее контролируемо и меньше нагружает проц в отличии от роутинга)

 

Что касаемо точек - думаю что слабенько роутить она будет.

[N.Leiten 89]

Учитывая, что мы рассматриваем контроллируемую бюджетную сеть. В частности На первое время, пока нагрузка небольшая, можно такой вариант пользовать...

Проводил тестирование точек г700ап. С нулевыми правилами способна роутить больше 2700 пакетов/с (больше не смог сгенерировать на целероне 600мгц). в ближайшее время буду тестировать с нагрузкой правил...

Но как идея жить может, насколько я смотрю Можно оформить и забросить в статьи, что-то из разряда как нужно строить если мало денег

[BlackSedan 0]

Учитывая, что мы рассматриваем контроллируемую бюджетную сеть. В частности На первое время, пока нагрузка небольшая, можно такой вариант пользовать...

Проводил тестирование точек г700ап. С нулевыми правилами способна роутить больше 2700 пакетов/с (больше не смог сгенерировать на целероне 600мгц). в ближайшее время буду тестировать с нагрузкой правил...

Но как идея жить может, насколько я смотрю Можно оформить и забросить в статьи, что-то из разряда как нужно строить если мало денег

идея правильная... у меня правда точки г700 в бриджах, каждый дом оконечивается эдимаксом (все с линухом на борту), бордеры (они-же эдимаксы) коннектятся к фре на Л9 (л2тп тонелинг), и действительно получается подобие "большой Л2 сети"...

[Pit 35]

Мне кажется плохо точкам будет, замечено что точки начинают бажить по эзернету когда заполняется мак таблица точки, если ром на линуксе то я думаю можно что-то придумать.

Да еще бродкастами чтобы точку не ввели в непонятки.

 

 

 

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

[N.Leiten 89]

Из практики - стоят овислинки 5460 (тот же чип, процессор, только памяти больше) В режиме роутера. на проводе гирлянда из неуправляемых свитчей. Количество абонентов больше 600. Работает нормально. так что от броадкаста левого не валятся От маршрутизации - будем тестировать.

[mr.Scamp 41]

Статья очень хорошая, спасибо.

Правда специфику всю не прочувствовал, ибо обычно на длинные линки (между "районами") ставится оптика.

Из сложностей могу назвать возможное недовольство и потерю клиентов, которые "не видят сеть" и "чат неработает!!!!". Также могут пострадать многие игры, которые общаются широковещалкой.

Проблема решается установкой локального IRC-сервера (общение) и какого-нибудь DC++ хаба (обмен файлами), если есть много времени - можно и с игровыми серверами поэкспериментировать.

Как метод доступа в Интернет советую pptp-VPN, удобно тем, что сервер доступа доступен через несколько локальных маршрутизаторов. Как сервер доступа неплохи FreeBSD/mpd или Cisco (что намного дороже, но, говорят, стабильнее).

 

На потоках до 100 Мбит в качестве маршрутизаторов, которые терминируют VLAN/отдельные ветки сети можно использовать PC, причём весьма неплохие результаты даёт Microtik, не уступая по производительности FreeBSD, а по управляемости даже в некоторых местах превосходя.

[N.Leiten 89]

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

А пока суть дела - перестроили два крыла сети, теперь будем приниматься за центр - провода и клиенты на них В общем ситуация классная. Мне понравилось - оно действительно работает и даже проще чем я думал

Единственное но, с которым можно смирится, но я попробую бороться.

При посылке первого пакета на хост за одним шлюзом задержка может быть (для первого пакета) до 300мс, остальные в норме. Если несколько шлюзов на пути, то задержка вырастает до 3секунд, а то и больше. Как вариант борьбы с этим явлением я вижу поднятие туннелей к каждому шлюзу от каждого шлюза и прописывать "кратчайший" маршрут к подсетям в туннель - буду пробовать. Если есть еще варианты для фантазирования - внимательно выслушаю и протестирую. О результатах сообщу.

 

ЗЫ. Наверное, таки буду писать статью - всё-таки никто такого еще не делал, а для бюджетного варианта - самое оно.

[mr.Scamp 41]

N.Leiten, а можно ли поподробнее о самой реализации Proxy ARP с техническими деталями?

Хотелось бы узнать, почему именно имеет место задержка перед установлением связи и какие ОС могут нормально работать в такой сети. Является ли это RFC-совместимым?

[frig 2]

едиснтвенное что, так это если-бы была серверная прога эмулирующая работу сетевого окружения, то есть так как етсь. кликнул на ярлык, компы-папки, то проблем с юзерами вообще не будет

 

СМЕРТЬ БРОДКАСТАМ! автору респект. сам о таком думаю. вот единственную проблему описал.

[mr.Scamp 41]

едиснтвенное что, так это если-бы была серверная прога эмулирующая работу сетевого окружения, то есть так как етсь. кликнул на ярлык, компы-папки, то проблем с юзерами вообще не будет

Проще пользователей обучить. И дать им более достойную замену устаревшим технологиям.

Они ведь приходят в сеть ради общения, обмена файлами и компьютерных игр.

А через какую программу это всё делается - среднестатистическому казуалу побарабану. Что поставили - то и использует.

[N.Leiten 89]

mr.Scamp

 

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

Теперь представь, что с одного конца сети пошел арп запрос и по цепочке в другой конец он "ретранслируетя" (на самом деле подставляются другие мак-адреса, поэтому не совсем ретрансляция), и каждый роутер проверяет свои таблицы, пока не выстроится цепочка роутеров, которые считают что нужный айпи-мак находится на одном из интерфейсов. Когда же таблицы сформировались идет голая маршрутизация, без особых задержек.

 

Теперь о решении этой проблемы. Линукс был бы не линукс, если бы не его функциональность и безопасность. Для безопасности в линуксе специально ввели задержку на ответ проксиАРП, в точках Г700 он равен 80. Устанавливается этот параметр в

/proc/sys/net/ipv4/neigh/DEV/proxy_delay

Я установил этот параметр значением 10, теперь максимальная задержка стала 450мс на первый пакет Раньше была около 3500мс

Пользуйтесь на здоровье.

[Barabashka 0]

Давай подробное описание как и что с картинкой :loop:

[Apelsin 34]

а что означает в случае 180.22.0.0/16

последняя цифра /16 как, где это писать?

я привый делать так

айпи 192.168.0.XXX

маска 255.255.255.0

 

:loop:

[deep_admin 1]

Я вот читаю и волосы дыбом становятся! какой прокси-арп! это же костыль!

Вы этим прокси-арпом теряете управление канальным уровнем уже после первого роутера, другими словами теряете мак-адрес. К тому же производительность роутера в таком режиме крайне низка (для радио конечно хватит).

Почему не делать обычный бридж + ebtables. Там огромное кол-во модулей, можно фильтровать, роутить, шейпить и нет ограничений для пппое. Причем на правильных сетевухах (intel pro 1000 с чипсетом 82540EM) можно перемолоть до 600мбит/с на обычных писюках.

[N.Leiten 89]

deep_admin

Привет, завтра увидимся.

Насчет бридж+ebtables - конечно. Я просто предлагаю варианты Следующий вариант как раз таким и будет Пока есть возможность - тестирую. Особенно если учесть, что в принципе любое изменение топологии (в данном случае метода "прозрачности") никак не сказывается на абоненте .

Вооот. Ну а речь как раз шла о радио, поэтому вот так и зашел разговор .

 

Apelsin

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

[N.Leiten 89]

Насчет бриджев и управляемости - буду пробовать собрать прошивку с ebtables. В принципе проблем быть не должно, за исключением объема флешки. Буду резать сбор статистики по ipcad.

Если бриджы тоже будут нормально работать - то тоже буду писать статейку, только позже.