Задать вопрос
  • Подскажете книги, написанные для студентов-самоучек?

    Dit81
    @Dit81
    Security researcher, pentester, internet-marketer
    Книги за авторством Герберта Шилдта. Для языков C/C++, Java, C#. Мало воды, есть упражнения. Все объяснено последовательно и понятно. Сам по таким учился и других уже учу.
    Ответ написан
    Комментировать
  • Какое выбрать оборудование для построения локальной сети?

    leahch
    @leahch
    3D специалист. Dолго, Dорого, Dерьмово.
    Берите коммутаторы DLink DES/DGS 1210-28/ME(52) или 1510-28(52). Можно даже D-link DES/DGS-1100-24, но он не очень мультикаст тянет, а в остальном очень стабилены. Длинки поставляем всем заказчикам под проекты, да и у самих стоят, только на них и работаем. Умеют и VLAN и мультикаст и ACL-ы и даже 802.1x + DHCP-snooping.
    И да, мы занимаемся IPTV, поэтому знаю, о чем говорю.

    Что касается роутера, то я уже давно делаю так.
    Беру обыкновенный комп с двумя сетевыми картами с Core i3/i5 и 8-16Гб памяти, 2-4 HDD. За все про все 20-30к рублей.
    Ставлю на него ubuntu:
    - KVM
    - SAMBA
    - FireHol (фаервол)
    - OpenVPN
    - делаю диски в RAID 10
    На фаерволе прописываю маскарадинг, настраиваю файлопомойку на Samba.
    На KVM разворачиваю несколько виртуалок, одна с IP-телефонией (FreePBX), вторая с Windows Server 2008 (можно и самбой обойтись), третья для WEB/RedMine/Trac (ubuntu).
    Дополнительно на последнюю виртуалку ставлю inflyxdb + grafana, на основной хост collectd. Получаю статистику и красивые графики.

    В результате получаю:
    - мощный роутер
    - файлопомойку
    - домен виндовс
    - телефонию
    - организацию VPN с шифрованием и удаленным доступом
    - web-сервер с инструментами для коллективной работы (записки, заметки тикеты)
    И самим и заказчикам такое делаем практически на потоке!
    Ответ написан
    Комментировать
  • Будет ли клиент пинговать другого клиента при такой конфигурации?

    @throughtheether
    human after all
    Собрал топологию на GNS3:
    12c059e9ce9540babb8b669f8177e91e.png
    По первому вопросу:
    Будет ли клиент пинговать другого клиента с адресом 10.45.18.194 и почему?
    Да, пинги проходят:
    ClientA#ping 10.45.18.194 repeat 10
    
    Type escape sequence to abort.
    Sending 10, 100-byte ICMP Echos to 10.45.18.194, timeout is 2 seconds:
    !!!!!!!!!!
    Success rate is 100 percent (10/10), round-trip min/avg/max = 20/34/48 ms


    Теперь самое интересное. 10.45.18.194 отсутствует в таблице маршрутизации Клиента А, поэтому icmp-запросы до 10.45.18.194 инкапсулируются в Ethernet-фреймы с адресом назначения маршрутизатора провайдера (00ff.ffff.ffff). Маршрутизатор провайдера при этом декапсулирует IP-пакет с ICMP-запросом, инкапсулирует его в Ethernet-фрейм со своим адресом (00ff.ffff.ffff) в качестве адреса источника и адресом Клиента Б (00bb.bbbb.bbbb) в качестве адреса назначения (это подтверждается дампами трафика). Клиент Б, получив ICMP-запрос, формирует ответ, отсылает ARP-запрос для определения MAC-адреса Клиента А (т.к. IP-адрес Клиента А находится в той же "подсети", что и адрес Клиента Б), и отсылает ответ непосредственно ему.

    В отличие от обычной ситуации (когда при отстутствии ARP-записей теряются 1-2 пинга), в данном случае генерируется 3 ARP-запроса (Клиент А определяет MAC-адрес маршрутизатора провайдера, маршрутизатор провайдера определяет MAC-адрес Клиента Б, Клиент Б определяет MAC-адрес Клиента А), соответственно первоначально теряются 3 пинга.

    Клиент на маршрутизаторе меняет конфигурацию интерфейса на такую:
    Interface e0/0
    Ip address 10.45.18.15 255.255.255.128
    Ip address 10.45.19.15 255.255.255.0 sec
    No shutdown
    !
    Будет ли адрес 10.45.19.15 присутствовать в ARP таблице маршрутизатора провайдера?

    Во-первых, если просто назначить адрес и не генерировать никаких ARP-запросов, то, естественно, маршрутизатор провайдера просто не узнает о наличии такого адреса. Во-вторых, если сгенерировать, например, gratuitous arp reply (деактивировав и снова активировав интерфейс, shutdown, no shutdown), маршрутизатор провайдера получит ARP-пакет (т.к. ARP распространяется широковещательно), но вполне может не принять его во внимание, учитывая отсутствие маршрута до 10.45.19.0/24 через входящий интерфейс:
    ISP#sh arp
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet  10.45.18.5              -   00ff.ffff.ffff  ARPA   FastEthernet0/0
    Internet  10.45.18.15            24   00aa.aaaa.aaaa  ARPA   FastEthernet0/0
    Internet  10.45.18.194           22   00bb.bbbb.bbbb  ARPA   FastEthernet0/0
    ISP#
    *Mar  1 01:24:18.735: IP ARP: rcvd rep src 10.45.18.15 00aa.aaaa.aaaa, dst 10.45.18.15 FastEthernet0/0
    *Mar  1 01:24:18.739: IP ARP rep filtered src 10.45.19.15 00aa.aaaa.aaaa, dst 10.45.19.15 ffff.ffff.ffff wrong cable, interface FastEthernet0/0
    *Mar  1 01:24:18.739: IP ARP: rcvd rep src 10.45.18.15 00aa.aaaa.aaaa, dst 10.45.18.15 FastEthernet0/0
    *Mar  1 01:24:18.739: IP ARP rep filtered src 10.45.19.15 00aa.aaaa.aaaa, dst 10.45.19.15 ffff.ffff.ffff wrong cable, interface FastEthernet0/0
    ISP#sh arp
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet  10.45.18.5              -   00ff.ffff.ffff  ARPA   FastEthernet0/0
    Internet  10.45.18.15             0   00aa.aaaa.aaaa  ARPA   FastEthernet0/0
    Internet  10.45.18.194           23   00bb.bbbb.bbbb  ARPA   FastEthernet0/0


    Таким образом, экспериментальные ответы на ваши вопросы таковы:
    1) да, пинги проходят
    2) нет, ARP-записи не будет

    Я лично полагаю, что практика (хотя бы такая) - лучший критерий истины. Другое дело, что тот, кто будет проверять ваши ответы, может считать по-другому.
    Ответ написан
    Комментировать
  • Возможно ли поднять единую Wi-Fi сеть с бесшовным роумингом на точках доступа с OpenWRT?

    @alteist
    Я изучал эту тему долго и мучительно (начав путь примерно с такого же вопроса, что и вы), но не являюсь профессионалом. Буду рад замечаниям и критике.

    Вкратце - проблемы, описанные в теле вопроса не соотносятся с заголовком и направлением копания в сторону, мягко говоря, неоднозначного и замыленного термина "роуминг". Для быстрого понимания темы лучше временно выкинуть это слово из вокабуляра. Заметьте, кстати, что в серьезных статьях пишут как минимум fast roaming, а не просто roaming или seamless roaming.

    Также есть две спорные препозиции, начну с них.
    1.
    Единая Wi-Fi сеть

    Если у вас WPA2-PSK, и если не рассматривать малоприменимую в нашей жизни экзотику вроде одного MAC-адреса на разных ТД и mesh-сетей разных уровней, то у вас и так "единая" Wi-Fi сеть. Не менее единая чем у очень богатых дядей с Cisco и Juniper, и менее богатых с D-Link и Ubiquiti. Это я к тому, что нет никакой серебряной пули, решающей описанные вами проблемы. Группа ТД с любой фичей, описание которой содержит слово "роуминг", всё равно останется группой ТД.

    2.
    Есть решения от тех же D-Link или Ubiquiti, которое позволит решить данную проблему.

    PMKID caching - то, что вендоры раньше называли бесшовным роумингом (более честно - zero handoff у Ubiquiti), решает другую проблему - долгую аутентификацию "с нуля" при переключении клиента на другую ТД, в случае, если используется не PSK (там такой проблемы нет), а EAP метод аутентификации. С помощью кэширования части ключа и доступа к кэшу со всех ТД. При этом, в таком решении может не быть 802.11k/802.11r.

    3. 802.11k/802.11r возможно уже есть в OpenWRT (точнее, hostapd), но это нам не сильно поможет. Во-первых, нет внятного описания того, какое железо для этого нужно, нет инструкций как это настраивается, непонятно даже - нужно ли это настраивать. Во-вторых, всё равно на рынке очень мало беспроводных клиентов, поддерживающих 802.11k/802.11r. В-третьих, не факт что если всё это взлетит - будет много толку.

    4. Дело в том, что за исключением специальных редких дорогих vendor-locked беспроводных клиентов, добровольно решение о смене ТД всегда принимает клиент, а не ТД или некий контроллер. ТД может только в рекомендательном порядке рассказать клиенту о своих соседях в рамках 802.11k.

    5. Насколько я понял, 802.11r - это продвинутая стандартизованная версия PMKID caching, которая ускоряет процесс аутентификации при переходе на другую ТД. Никакой связи с функцией поиска ТД с лучшим сигналом.

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

    7.
    ноутбуки постоянно теряют соединение, находясь на одном месте, а мобильные устройства очень редко решаются переключится на ближнюю точку доступа с лучшем сигналом и вместо этого остаются на самой отдаленной.

    В итоге, возможно когда-то чем-то сможет помочь 802.11k, а решение описанной проблемы скорее найдется в банальных действиях:
    • переводе всего, что переводится на кабель
    • переводе части того, что переводится на 5GHz
    • изменение конфигурации ТД в пространстве
    • изменение частотной конфигурации ТД
    • изменение мощности ТД (скорее в сторону понижения, чем повышения)
    • изменение количества ТД (не факт, что в сторону увеличения)
    • и т.д.


    P.S.: Про контроллеры. Насколько я в этом разобрался, все эти вендорские беспроводные контроллеры не нужно воспринимать как нечто уникальное, добавляющее сверх-фичи недоступные простым смертным. Обычно это просто набор программных сервисов, вынесенных из точек доступа для солидности, избыточности и удобства (единая точка управления, PoE и т.д.). Грубо говоря, это коробка, где помимо очевидных вещей могут быть: проприетарный протокол массового распространения настроек, кэш PMKID или аналога, RADIUS или аналог, совсем банальные DHCP, BOOTP, TFTP и т.д., скрытые под толстым слоем красивых названий.

    Еще по теме:
    Сначала указанную ветку комментариев, потом статью., чтобы была верная поправка на ветер "вендорства".
    В основном про аутентификацию и её ускорение.
    Пример внятной подачи информации от производителя клиентских устройств.
    Ответ написан
    Комментировать