Попробуйте добавить в раздел nat -> destination -> rule-set NAT_VPN следующее правило:
rule GRE {
match {
source-address 0.0.0.0/0;
destination-address XXX.XXX.XXX.XXX/32;
application junos-gre;
}
then {
destination-nat pool Qnap;
}
По моему представлению, оно позволит натировать GRE трафик.
Копать в сторону wifi location tracking (но у mikrotik я такого решения не нашел). Если вам важнее ехать, чем шашечки, то прочитайте про пеленгацию ('охота на лис'). В принципе, с направленной антенной, думаю, вполне возможно очертить примерный сектор обитания клиента.
С одной точкой доступа, у которой наличествует одна всенаправленная антенна сделать то, чего вы хотите, нельзя ни на оборудовании Mikrotik, ни на оборудовании Cisco systems, ни на оборудовании Ubiquiti. Точка доступа в этом случае не имеет никакой _технической_ возможности дифференцировать сигнал, пришедший 'слева' от сигнала, пришедшего 'справа'.
Вы в условии упомянули _одну_ точку доступа. Имеются ли другие? Имею в виду, под вашим управлением? Точки доступа независимые или управляются одним контроллером?
Реализует что 'это'? Определение местоположения клиента с точностью до сантиметра при помощи одной точки доступа с одной всенаправленной антенной? Пример можете привести?
Если речь все же об определении местоположения клиента (кстати, визуализация с точностью до сантиметра и определение фактического местоположения с точностью до сантиметра это довольно ортогональные вещи) при помощи нескольких точек доступа (точнее, трансиверов), то, полагаю, используются различные техники радиопеленгации. Грубо говоря, у вас есть N трансиверов, местоположение которых вам известно. Вам известна диаграмма направленности антенны каждого трансивера. Вам известны характеристики (мощность, фазовые характеристики и т.д.) сигнала от клиента, принимаемого каждым трансивером. Исходя из этих данных, вы можете значительно сузить пространство вариантов для предполагаемого местоположения клиентского трансивера.
Рад, что все благополучно разрешилось. Хотел бы отметить, что при построении сети на внятном оборудовании (которое хотя бы SNMP отдает) и своевременном мониторинге поиск источника проблемы занял бы на порядок меньше времени.
>Это скорее лаба, чем промышленное решение.
Это хорошо, потому что есть подозрение, что у 2960s может не хватить буферов при высокой загрузке SAN-подобным трафиком.
Схема, думаю, рабочая. (вот моя фантазия на тему rghost.ru/download/private/55848218/3741bde8c33469...
Линк от каждого сервера (я правильно понимаю, что у вас 2 сервера, по 6 гигабитных интерфейсов в каждом?) до каждого коммутатора - это lacp-etherchannel из 3 физических интерфейсов.
1) насколько мне известно, MTU для случая L2-обработки (форвардинга) фреймов у 2960 задается одной командой, безразлично деления на вланы.
2) уточните планируемую схему подключения. Что будет подключаться к каждому коммутатору? Есть ли L2-форвардинг между портами одного устройства (т.е. ESX-сервера или СХД)? Вы собираете лабу или промышленное решение?
Если я вас правильно понял (нужно решение, агностическое касательно нюансов имплементации сайта, нечто вроде Web Application Firewall), то вам, вероятно, поможет реверс-прокси с соответствующей логикой. Как вариант, nginx c поддержкой Lua для реализации необходимой логики.
Как я понял, Netgear wndr3400 - это SOHO-маршрутизаторы. Я правильно понимаю, что у них задействованы только LAN-порты?
Это довольно грустно, когда 'продакшен' сети создают на таком оборудовании. За 4000 рублей можно было бы купить подержанный cisco catalyst 2950, например, с в разы большими возможностями для траблшутинга. Еще пара вопросов:
1) Кроме 82.204.201.210 есть хосты, пинги до которых также пропадают? Запустите параллельно пинг до 8.8.8.8, например.
2) Кроме пропадания пингов, есть ли другие проявления проблемы (не открываются страницы, например)
3) Маршрутизатор использовали только с целью увеличения количества портов?
4) на линке между HDSL модемом и маршрутизатором какая адресация используется - частная (192.168.x.x, 172.16.x.x-172.31.x.x, 10.x.x.x) или глобальная?
И еще одна гипотеза - питание. Как правило, SOHO-роутеры не могут похвастаться БП повышенной всеядности, вероятно, периодические 'подвисания' происходят из-за кондиций электрической сети.
){kind=link}