kayot Опубликовано 13 апреля, 2018 · Жалоба 11 часов назад, AlKov сказал: но это же явный Cisco ip unnumbered. Или я ошибаюсь и путаю тёплое с мягким? Как раз таки вы пытаетесь сделать PPP на базе IPoE, а unnumbered вам это позволяет сделать. Вот только он был придуман вовсе не для таких извращений - вы используете unnumbered что б не нарезать клиентам сети и одновременно пытаетесь заставить клиента делать unnumbered у себя, используя недоступный шлюз. Какой-то клиент будет работать, какой-то нет, это плохая схема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба Хорошо. А давайте попробуем подойти с другой стороны, вот с этой - 1 час назад, kayot сказал: Какой-то клиент будет работать, какой-то нет, это плохая схема. Т.о. получается, что - а). Windows - "плохой клиент" б). TpLink - "плохой клиент" в). Asus - "плохой клиент" г). Zyxel - "плохой клиент" д). UBNT - "плохой клиент" е). подозреваю (не проверял), что и cisco тоже в этой компании "плохой клиент" = тот, который "понимает" /32 И только DLink - "правильный клиент". Приглашает к размышлению.. И это не сарказм, это действительно так.. Далее... В моём случае (роутеры DLink не работают с /32) вариантов вижу не много - 1. выдавать клиенту IP с маской /12 (проверено, работает) 2. сделать, как предлагает Ivan_83 - отдать в опциях маршрут до шлюза через выданный IP адрес. Первый вариант вызывает сомнения и опасения в плане нарушения стабильности работы собственно NAS-а, да и абонентского сегмента. Второй - пока не представляю, как исполнить. Хочу попробовать отдавать клиенту шлюз радиусом атрибутом - DHCP-Router-IP-Address. Не очень удобно, конечно, но пока других вариантов не нахожу.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 апреля, 2018 · Жалоба Давайте еще раз. 1. /12 выдавать не нужно, выдавайте реальную маску используемой вами подсети. /20 или что там нарезано. 2. БРАСу и клиенту все равно какую маску отдаете, лишь бы клиент и шлюз были в одной подсети. В любом случае весь клиентский трафик отправляется на шлюз, между собой клиенты все так же изолированы. Если нужен трафик между клиентами на реальных ИП - включаете прокси арп и "типа L2" трафик будет бегать по L3 через НАС, не нужен - не включаете и все полностью изолировано. 3. Аццелю и клиенту опять же совершенно все равно как вы выдаете маску и шлюз, из пула или из радиуса. Это сугубо вопрос удобства и предпочтений вашего биллинга. Я вообще выдаю отдельным DHCP сервером(perl скрипт от Ivan_83), мне так удобнее. Вы конечно можете попробовать подобрать настройки что /32 заработал на длинках, но зуб даю, завтра встретите очередной роутер который работать не захочет или какой-нить комп со старым линуксом. И начнете сначала. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
casper.w00t Опубликовано 13 апреля, 2018 · Жалоба Сталкивались с такой проблемой давненько. Перешивали в dd-wrt и все работало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба 16 минут назад, kayot сказал: 1. /12 выдавать не нужно, выдавайте реальную маску используемой вами подсети. /20 или что там нарезано. /12 и используется. 18 минут назад, kayot сказал: Вы конечно можете попробовать подобрать настройки что /32 заработал на длинках, но зуб даю, завтра встретите очередной роутер который работать не захочет или какой-нить комп со старым линуксом. И начнете сначала. Согласен. Не исключено.. P.S. DHCP-Router-IP-Address не прокатило, аццел матерится [2018-04-13 10:38:50]: error: eth0.3709.205: can't determine Server-ID [2018-04-13 10:38:50]: debug: eth0.3709.205: terminate Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
EShirokiy Опубликовано 13 апреля, 2018 · Жалоба Полностью согласен с @kayot, не понятно зачем заморачиваться с /32, абоненты и так будут друг от друга изолированы. В этом и вся прелесть IP Unnambered, закинул IP на лупбэк, обозначил диапазон вланов и раздаешь IP-адреса. /12 я бы не стал делать, но какой-нибудь /22 вполне Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба 13 минут назад, EShirokiy сказал: /12 я бы не стал делать, но какой-нибудь /22 вполне Не получится, т.к. с незапамятных времён PPTP и PPPoE остались IP 172.18... 172.19... Можно, конечно, и поменять, но тут другой гемор вылезет - нефлоу статистика - весь ум сломаешь, узнавая какой IP был у клиента год назад. Это когда ФСБ "попросит" клиента вычислить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 13 апреля, 2018 · Жалоба 5 минут назад, AlKov сказал: Можно, конечно, и поменять, но тут другой гемор вылезет - нефлоу статистика - весь ум сломаешь, узнавая какой IP был у клиента год назад. Это когда ФСБ "попросит" клиента вычислить. Странно такое слышать. На период до 3 лет нужно хранить логи сессий (детализацию) — и по этим логам всегда можно сопоставить IP и абонента. А больше 3 лет ФСБ просить не будет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба 1 минуту назад, alibek сказал: Странно такое слышать. На период до 3 лет нужно хранить логи сессий (детализацию) — и по этим логам всегда можно сопоставить IP и абонента. А больше 3 лет ФСБ просить не будет. Всё так и есть. Долго объяснять, да к тому же это и не имеет отношения к обсуждаемому. Если кратко - при смене клиентского IP, поиск усложняется. А вот по теме - насчёт /12.. Есть опасения, что какая-то SOHO железка/ОС и не схавает.. Может, конечно, это и безосновательные опасения, но.. После таких "заскоков" начинаешь дуть на холодную воду.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 13 апреля, 2018 · Жалоба 5 минут назад, AlKov сказал: Есть опасения, что какая-то SOHO железка/ОС и не схавает.. То что не примет /12 — это крайне сомнительно. Разве что на каком-то особо экзотической китайской железке, там любые чудеса возможны. Другое дело, что если в FDB/ARP по какой-то ошибке зальются данные (MAC-адреса, ARP-записи) с /12, то любой железке станет плохо. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 13 апреля, 2018 · Жалоба да простой сканер портов в локалке на клиентском компе может переполнить ТАКУЮ ARP-таблицу. :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба 15 минут назад, UglyAdmin сказал: да простой сканер портов в локалке на клиентском компе может переполнить ТАКУЮ ARP-таблицу. :) Так в данном случае (vlan per user) "локалки" как таковой не существует, и ARP proxy выключен. Для интереса пробовал тупо попинговать "соседей" по сети на компе, подключенном "напрямую" - кроме ARP, Request who-has 172.16.16.51 ничего не увидел на интерфейсе клиента. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alibek Опубликовано 13 апреля, 2018 · Жалоба 7 минут назад, AlKov сказал: и ARP proxy выключен Я же писал "по ошибке". Если вдруг кто-то случайно включит или BRAS глюкнет — словите такой шторм, что все ляжет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 13 апреля, 2018 · Жалоба 7 минут назад, alibek сказал: Я же писал "по ошибке". Если вдруг кто-то случайно включит или BRAS глюкнет — словите такой шторм, что все ляжет. Ну это уже "перебор". От случайностей никто не застрахован. Гораздо более интересны возможные "закономерности" для такого варианта. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 13 апреля, 2018 · Жалоба 34 минуты назад, AlKov сказал: Так в данном случае (vlan per user) "локалки" как таковой не существует, и ARP proxy выключен. Для интереса пробовал тупо попинговать "соседей" по сети на компе, подключенном "напрямую" - кроме ARP, Request who-has 172.16.16.51 ничего не увидел на интерфейсе клиента. Запрошенные адреса тоже хранятся в ARP-таблице какие-то время (секунд 5). Если софт в роутере кривоват, то сканер переполнит эту таблицу за секунду. Поэтому мысль ограничить её маской до 256 адресов или даже меньше - не такая и плохая. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 13 апреля, 2018 · Жалоба Так маршрутизатор в любом случае должен знать маки клиентов. Т.е ARP таблица там и так будет заполнена, разве нет? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 13 апреля, 2018 · Жалоба 2 часа назад, AlKov сказал: Не получится, т.к. с незапамятных времён PPTP и PPPoE остались IP 172.18... 172.19... У вас адреса из этого диапазона используются вразнобой что ли? Отрезать реально используемое количество вида 172.16/19 и забыть. /12 я б таки не использовал, реально может вирусня арп-таблицу на БРАСе переполнять, а ставить её размером в мильёны неразумно. 2 минуты назад, myth сказал: Так маршрутизатор в любом случае должен знать маки клиентов. Т.е ARP таблица там и так будет заполнена, разве нет? Будет, но при сканировании всего диапазона в таблице будет вместо 5к клиентов - 1 млн пустых записей. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 13 апреля, 2018 · Жалоба Но по /24 на район(микрорайон) я бы все-таки нарезал 3 минуты назад, kayot сказал: при сканировании всего диапазона в таблице будет вместо 5к клиентов - 5 млн пустых записей да, не учел этого. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 апреля, 2018 · Жалоба 14 часов назад, NiTr0 сказал: попытка прописать шлюз который физически недоступен - у нормальных *nix осей вызывает непонимание Что значит физически не доступный? Это ты намекаешь на шлюз не принадлежащий ни одной из подсетей интерфейсов? Если так, то иди читай исходники, всё прекрасно работает во всех осях, даже в этих ваших линуксах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 13 апреля, 2018 · Жалоба В любом случае, должно, но не обязано. Скорее всего, решится добавлением статического маршрута, но костыли это... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 апреля, 2018 · Жалоба 4 часа назад, AlKov сказал: 2. сделать, как предлагает Ivan_83 - отдать в опциях маршрут до шлюза через выданный IP адрес. 4 часа назад, AlKov сказал: Второй - пока не представляю, как исполнить. Заюзать дхцп сервер на перле. 1 час назад, AlKov сказал: Для интереса пробовал тупо попинговать "соседей" по сети на компе, подключенном "напрямую" - кроме ARP, Request who-has 172.16.16.51 ничего не увидел на интерфейсе клиента. arp-scan в помощь. 2 минуты назад, myth сказал: В любом случае, должно, но не обязано. Скорее всего, решится добавлением статического маршрута, но костыли это... С чего бы это костыли? Я уже описывал принцип по которому оно работает в ядре. То что родной дхцп клиент не сделал такой простой вещи в длинке не означает что делая это самостоятельно мы сделаем хуже. Костыль будет в том случае, если такой маршрут начнёт ломать то что сейчас работает, и тогда придётся в дхцп сервере добавлять условия кому отдавать маршрут а кому нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
DRiVen Опубликовано 13 апреля, 2018 · Жалоба 3 часа назад, Ivan_83 сказал: Что значит физически не доступный? Это ты намекаешь на шлюз не принадлежащий ни одной из подсетей интерфейсов? Да, не принадлежащий и как следствие не имеющий ARP-записи на шлюзе. Передача в ethernet пока еще на уровне аппаратных адресов происходит, нельзя отправить пакет не зная MAC. 3 часа назад, Ivan_83 сказал: Если так, то иди читай исходники, всё прекрасно работает во всех осях, даже в этих ваших линуксах. Без посылов разгребать код, вкратце механизм не объясните? Только для интерфейса, имеющего маску, отличную от /32. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
rdc Опубликовано 13 апреля, 2018 · Жалоба к чему весь этот спор? надо делать шлюз в пределах подсети, и не будет проблем ни с кем Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 13 апреля, 2018 · Жалоба 1 час назад, DRiVen сказал: Без посылов разгребать код, вкратце механизм не объясните? Только для интерфейса, имеющего маску, отличную от /32. Я же объяснял. Есть пакет с ip dst 8.8.8.8, системе сказали его послать к чортовой матери, она смотрит в таблицу маршрутизации и находит там либо: - имя интерфейса, в чей диапазон адресов попадает адрес - ip шлюза куда послать пакет, если там ещё нет имени интерфейса то делается ещё один запрос к таблице маршрутизации чтобы узнать на каком интерфейсе ip шлюза С этой инфой система лезет в арп кеш и зная имя интерфейса и ndst ip (это уже может быть ip шлюза, а заодно и mtu для данного маршрута) она получает l2 адрес (это не обязательно эзернет, ха-ха), если его там нет, то создаётся временная запись в кеше, пакет привязывается к её очереди, дальше в сеть уходит арп запрос. Если на х арп запросов за время т не было ни одного ответа то запись вместе с очередью не отправленных пакетов херится. Ещё пакет может похерится если слишком много желающих пакетов, тк у очереди есть лимит на длину. Если арп ответ приходит, то все пакетики из очереди отсылаются, запись помечается валидной и выставляется время/таймер. Это в общем так. Вместо arp может быть nd, вместо эзернета - инфинибанд, фаерварь и чего то там ещё старого, что никак не выпилят. Общий смысл простой: система ищет куда бы сплавить пакет, думаю можно приколотся и вообще заставить её слать их мультикастом/броадкастом, повесив дефолт шлюзом 255.255.255.255 или 224.*.*.* и оно всё равно будет работать, даже может лучше :) ибо для этих адресов арп запрос не делается: в первом случае копируется константа, во втором случае там простой мапинг, те практически копирование ip в мак адрес. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 13 апреля, 2018 · Жалоба 11 минут назад, Ivan_83 сказал: Есть пакет с ip dst 8.8.8.8, системе сказали его послать к чортовой матери, она смотрит в таблицу маршрутизации и находит там либо: - имя интерфейса, в чей диапазон адресов попадает адрес - ip шлюза куда послать пакет, если там ещё нет имени интерфейса то делается ещё один запрос к таблице маршрутизации чтобы узнать на каком интерфейсе ip шлюза а если там нет ни того ни того (как в случае костылей с /32)? ну и да, все загнется еще на этапе добавления маршрута через "хренпоймигде". и это логично и правильно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
