Jump to content

Recommended Posts

Posted (edited)

Всем Здрастуйте! Проблема следующая:

 

Есть небольшое колличество удаленных абонентов, которые связаны с основной сетью через безпроводной мост. В качестве БС стоит старый добрый Planet WAP4000A (в режиме AP), со стороны абонентов стоит такой же Planet WAP4000A(AP Client).

Начали поступать жалобы от этих абонентов на частые обрывы VPN-соединения, причем после обрыва следовала ошибка 800, при этом IP адрес абоненту назначался DHCP-сервером соответсвующий. Если на сервере удалить статическую таблицу мас-адресов (arp -ad), проблема на некоторое время решалась, пока биллинг автоматом не загрузит таблицу из своей базы arp -f /usr/...static_arp (используем статическую привязку айпи-мак)

 

После продолжительных танцев с бубном, удалось выяснить, что проблема в следующем:

мак адрес клиента, который мы используем для связки айпи-мак 00:00:00:00:01, по этому же маку клиент получает ип 10.2.7.2 от ДШСП.

мак клиентской точки доступа 00:00:00:00:02.

 

Звонит клиент, сообщает о проблеме.

пингуем клиента 10.2.7.2, не пинается

делаем arp -ad, пинг появляется

клиент в онлайн

 

смотрим мак клиента arp -n 10.2.7.2 и видим мак 00:00:00:00:02. НО это же мак точки доступа! Как такое может быть?

Если пнуть клиента 10.2.7.2 (Comp2 на схеме) с машины 10.2.7.3 (Comp3 на схеме), и посмотреть мак, то мак 00:00:00:00:01 соответствует маку клиента.

Если пнуть клиента с машины 10.2.7.4 (Comp1 на схеме), которая в свитче за БС, мак уже 00:00:00:00:02 соответствует маку точки доступа.

 

также прилагаю скриншот пинга со стороны сервера аналогичного клиента.

 

 

post-81759-000996900 1327429415_thumb.png post-81759-064275900 1327429385_thumb.png

 

Подобные аномалии наблюдаютя и в других сегментах сети, так что на WAP4000A я не грешу. Похоже на ARP-spoofing, но странно, что мас-адрес подмениваеся точкой доступа.

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

Edited by woda
Posted

смотрим мак клиента arp -n 10.2.7.2 и видим мак 00:00:00:00:02. НО это же мак точки доступа! Как такое может быть?

Так и должно быть.

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

Posted

Так и должно быть.

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

 

А если клиентов, которые находяться за WaP4000A, перевести на PPoE вместо PPTP. Этот вариант решит проблему?

Posted (edited)

А если клиентов, которые находяться за WaP4000A, перевести на PPoE вместо PPTP. Этот вариант решит проблему?

Коротко - нет.

 

Ещё раз, читаем про WDS. Из Planet-ов подходят WAP-5100 и выше.

Но по цене они не дешевле MT, а по качеству линка - заметно хуже.

 

Хотя, если есть время на эксперименты - 2х NSlocoM5 решат проблему и недорого.

Edited by Deac
Posted

Коротко - нет.

 

Ещё раз, читаем про WDS. Из Planet-ов подходят WAP-5100 и выше.

Но по цене они не дешевле MT, а по качеству линка - заметно хуже.

 

Хотя, если есть время на эксперименты - 2х NSlocoM5 решат проблему и недорого.

 

Все ясно! Спасибо большое за помощь!

Posted

заходил на консоль UBNT NanoStation. в ebtables стоит трансляция мак-адресов. пока не особо волновало, но можно и убрать это правило из L2-фаервола. предполагаю, что на ваших точках тоже linux и может есть даже tcpdump

Posted

в BRIDGE - будет все ок. если планеты бридж держат. AP client -> считай он стоит dhcp клиентом/и натит всем кто за ним. bridge -> прозрачный. ничего не натит ничего не трогает тупо TX+RX

Posted

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

Posted

Как вы себе представляете NAT в L2 ?

от клиента: src мак клиента -> src мак НАТ.... долетело до сервера

от сервера: dst мак NAT...долетело до L2 NAT - как он узнает какому клиенту дальше пакет переслать, если все клиенты ходили на этот шлюз?

А ещё есть ARP, в котором тоже нужно маки транслировать, по хорошему.

В случае IP есть порты для TCP/UDP либо хелперы для остального, а тут как пакеты отличать при обратной трансляции?

Posted (edited)

Как вы себе представляете NAT в L2 ?

NAT - никак, а вот прокси - легко. :)

См. ProxyARP. Без WDS - вообще единственный вариант.

 

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

 

Причина то давно и хорошо известна - передавать надо 4(ЧЕТЫРЕ) MAC-а: по одному от точек доступа и по одному от конечных потребителей.

Это собственно и есть WDS.

Edited by Deac
Posted
См. ProxyARP. Без WDS - вообще единственный вариант.

Прокси АРП знаю как работает, мне интересен был именно нат в л2, его себе не представляю :)

Posted

На данный момент ваша дискуссия не актуальна, т.к. оборудование, которое поддерживает НАТ и ПРОКСИ на L2 будет стоить аналогично замене оборудования моста на микротик, который уже поддерживает нормальный WDS=)

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...
На сайте используются файлы cookie и сервисы аналитики для корректной работы форума и улучшения качества обслуживания. Продолжая использовать сайт, вы соглашаетесь с использованием файлов cookie и с Политикой конфиденциальности.