fun105

Если, например, задать для исходящего и входящего трафика дисциплину prio tc qdisc add dev eth0 root handle 1:0 prio tc qdisc add dev eth0 ingress handle 1:0 prio и потом через фильтры задать что трафик для ssh относится к первому классу (у которого самый высокий приоритет) tc filter add dev eth0 parent 1:0 protocol ip prio 1 \ u32 match ip dport 22 0xffff flowid 1:1 подсмотрел здесь. Так получится настроить? Или через tc так не будет работать?

Если я правильно понял, там используют IFB чтобы шейпить входящий трафик. Но там получается есть разные настройки для разных интрефейсов, отдельно для входящего и исходящего траффика. А вот если бы можно было бы построить такое "дерево классов" для htb, которое работает сразу с входящим и исходящим трафиком. И там задать что для ssh мы используем 100kbit/s и их не занимать, а остальную полосу для всего остального. Но похоже так пока не получится, по крайней мере так я понял мехнизм работы tc.

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

Да, с формулировкой могут быть проблемы, т.к. не большой специалист в этой области. Попробую описать еще раз. Есть устройство, подключенное к vpn серверу. Есть пользователь, тоже подключенный к этому vpn-серверу. Пользователь подключается к устройству по ssh через vpn. На компьютере у пользователя запускается софт, который принимает данные от устройства. Когда поток данных становится слишком большим, начинает торомозить подключение ssh - команды проходят с задержкой и их результат тоже отображается с задержкой. Если отключить передачу данных с устройства, то ssh начинает работать стабильно. Какая у меня была идея. Есть интернет канал у устройства. Через него к нему подключаются по ssh и по нему же оно передает данные data1. Как бы сделать так, чтобы часть этого канала была всегда зарезервирована для ssh, пусть и за счет передачи данных data1. Например, из общего канала выделить примерно 100 kbit/s для ssh, а все остальное чтобы использовалось для передачи data1. Если канала не хватает для передачи и ssh и data1, то тогда ssh передавать в первую очередь, а data1 - как получится. Только в этом случае данные ssh получается это будет входящий трафик на устройство, а data1 - исходящий. Инструкции, которые я находил, предлагают использовать tc для контроля полосы. Но, как я понял, через tc можно регулировать только исходящий трафик. Т.е. в моем случае я, как я предполагаю, могу ограничить канал data1 до какого-то искуственного значения, 500 kbit/s, например. Но если канал в интернет будет более скоростной (чем 500 kbit/s), то получится что я искуственно ограничиваю скорость передачи, чего не хотелось бы. Идея tc + htb с классами траффика подошла бы, как я думаю, если бы можно было бы регулировать весь трафик, и входящий и исходящий. А в явном виде через tc можно ограничить только исходящий. Поэтому подумал, что может быть это получится сделать через IFB/IMQ (какие-то псевдо интерфейсы, на разобрался с ними еще). Или может тут будет достаточно где-то (tc + prio?) указать, что у траффика ssh наивысший приоритет и он будет обрабатыватьтся в первую очередь. VPN сейчас используется Wireguard (не обязательно его использовать), не видел у него в настройках ничего про сжатие. SSH вроде же по умолчанию работает со сжатием и шифрованием, не думаю что там текстовые данные передаются в явном виде.

Есть одно устройство (одноплатник с armbian), у него есть доступ в интернет через сотовый модем. На нем запущен vpn для удаленного доступа к нему через vpn-сервер. Есть компьютер, на котором настроено подключение к этому же vpn серверу и с которого подключаются к этому устройству через vpn. С компьютера подключаются к устройству через ssh. С этого же устройства на сервер передаются данные по отдельному подключению (data1). Проблема в том, что иногда, когда устройство передает много данных, подключение по ssh начинает тормозить и устройство перестает реагировать на команды. Что можно предпринять чтобы ssh работал при любых условиях стабильно? Если не будет хватать интернет канала, то можно дропнуть часть данных которые передает устройство. Поскольку у устройства подключение через модем, то нет точного значения для доступной ширины канала, зависит от уровня сигнала. Примерно это можно было бы описать так - если есть данные по ssh - передавай их, есть есть возможность передать что-то еще - передавай data1. Пока идет поиск в интернерте, есть пара идей (могут быть неточности в формулировках т.к. раньше с такими вещами не работали). 1. Т.к. источником data1 являетс устройство, то манипуляции с трафиком нужно производить на нем. 2. Настроить классы траффика через iproute2 + tc htb и там задать отдельный класс для подключения по ssh c заданной гарантированной скоростью. Но тут есть несколько непонятных моментов. Будет ли это работать если подключение по ssh идет на устройство (для устройства - входящий трафик), данные data1, которые передает устройство на сервер получается исходящий трафик. Если я правильно понял, то tc может регулировать только исходящий трафик. Если нам нужно гарантировать полосу для ssh, за счет урезания трафика data1, это будет работать? Получится ли такое настроить через tc? 3. Поможет ли тут использование таких вещей как IFB/IMQ? Как я понял с их помощью, условно, можно задавать глобальные ограничения для общего потока трафика. 4. Использовать QoS. Как я понял, если настроить для подключения по ssh высший приоритет, это может решить проблему. Но не понял как это лучше сделать, тоже через tc?

Diman, пока так и поступил - сменил адрес роутера в сети1, все работает. DHCP используется только в сети2, поэтому перенастройка пулов не потребовалась. tun, как советовали выше не совсем подходит, из-за того что софт на серверах определяет доступность соседних серверов по netbios именам компьютеров. Можно конечно прописать их на каждом сервере в файл hosts, но я решил идти что объединить сети будет проще.

SUrov_IBM, спасибо за ответ. Думал получится проще, похоже нет, попробую разобраться с Вашим вариантом. По поводу работы OpenVPN в режиме моста вопрос еще один возник. Нужно ли на клиенте объединять в мост интефрейс локальной сети и tap интерфейс?

Если ничего не получится, то придется попробовать изменить адресацию. Сейчас думаю, если проблема с наличием двух узлов с адресами 192.168.1.1, то в сети1 его можно перенастроить на другой, тоже из той же подсети, но свободный в обоих сетях. Я себе так и представлял работу в режиме моста - подключил клиента к серверу и он в одной локальной сети с сетью за сервером. Возможно, при использовании в режиме моста, объединять tap интерфейс c интерфейсом локальной сети нужно только со стороны сервера (тоже надо попоробовать).

У меня была такая мысль, но как избежать этого я не придумал. Если использовать tun, то непонятно как компьютерам из сети2 сказать что 192.168.1.12 находится в другой подсети, только если использовать разные подсети в сети1 и в сети2.

Имеется такая сеть. Сервер1(192.168.1.12/24)---Роутер1(LAN:192.168.1.1/24(Сеть 1), WAN: 172.16.xxx.xxx)--- Интернет --- ---Роутер2(LAN:192.168.1.1/24 (Сеть 2), WAN: 77.88.xxx.xxx)---Сервер2(192.168.1.250/24) Сеть1 и Сеть2 имеют одинаковый адрес (192.168.1.0/24) и шлюз (192.168.1.1), но подключены к разным роутерам. В сети1 находится только Сервер1 и Роутер1, адрес Сервера1 не повторяется в Сети2. Сетей вида Сеть1 несколько, их нужно подключить к Сети2. Роутер1 - TP-Link c OpenWRT, Роутер2 - Mikrotik. Роутеры в остальных сетях - TP-Link+ddwrt. Чего я бы хотел добиться: чтобы любой из компьютеров в сети1 видел любой из компьютеров из сети2 и наоборот. Решение которое я пока придумал - использовать OpenVPN в режиме bridge. OpenVPN запускается как приложение на серверах. TAP-Интерфейс на серверах объединяется в мост с севой картой. Пробовал запускать - даже работало немного. Сервер1 пинговал компьютеры из Сети2. Сервер2 пинговал Сервер1. Но при этом имеются больщие потери пакетов (около 20%). Если отключить впн и просто пинговать роутер по даресу, то потерь пакетов почти нет и задержки значительно меньше (думаю проблема не в линке). При дальнейшах проверках наблюдаю что при подключении Сервера1 к Серверу2, Сервер2 начинает сильно лагать (подключен к нему по RDP). Когда Сервер2 отключается то лаги пропадают. Думаю проблемы могут возникать из-за появления в сети двух хостов с адресом 192.168.1.1, но как это обойти не знаю. Также не совсем понятно как и нужно ли настраивать адреса для тунельных интерфейсов (опции ifconfig, server-bridge ip-addr mask pool) Логи и конфиги во вложении. Соединение было активно в течение дня несколько часов, в логах много ошибок сокетов, думаю соединение закрывалось одним из роутеров по таумауту, т.к. обмена не было). forum.zip

Да, дизайн не айс, но все меняется по мере необходимости. Спасибо что ткнули в нужном направлении. Задвоенные пакеты заметил в логах когда пост начал писать, но думал что это ПО их так отправляет. Про рикошет как-то даже не догадывался, надо будет попробовать ваш вариант с /30 подсетью между роутерами. Текущий вариант так и возник - шлюз 192.168.105.2 прописан уже у всех, осталось только на нем маршрут правильный прописать до сети 192.168.1.0/24. Если предположить, что ответ возвращался через другой роутер (что я проверить не догадался, в wiresharke посмотрел что ответ приходит и ладно), то R1 вполне справедливо мог считать соединение не установившемся (т.к. пакет SYN,ACK возвращался через R2) и считать остальные пакеты в состоянии invalid.

Такой вопрос возник. В какой момент содинение становится established? У меня получилось так что пакет SYN в одну сторону проходит, в ответ приходит SYN,ACK. А ответ ACK на него успешно дропается правилом drop invalid, почему-то. О сети. Есть роутер R1 (RB750GL, 6.32.2) (WAN, local - 192.168.105.2), R2 (192.168.105.62, 192.168.1.1/24). На R1 прописан маршрут: ip route print ... 3 A S ;;; To network 1 192.168.1.0/24 192.168.105.62 1 Т.е. хосты из подсети 192.168.105.0/24 ходят в подсеть 192.168.1.0/24 через R1, на котором есть нужный маршрут. Сеть 192.168.1.0/24 находится за роуетером R2. Также на R1 в filter: 0 chain=forward action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd before" 1 ;;; ACCEPT established connections chain=forward action=accept connection-state=established log=no log-prefix="" 2 ;;; ACCEPT related packets chain=forward action=accept connection-state=related log=no log-prefix="" 3 chain=forward action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd after" 4 ;;; DROP invalid connections chain=forward action=drop connection-state=invalid dst-address=192.168.1.24 log=yes log-prefix="drop invalid" 5 ;;; DROP invalid connections chain=forward action=drop connection-state=invalid log=no log-prefix="" 6 ;;; JUMP to Safe city network chain=forward action=jump jump-target=forward_to_safe_city dst-address=192.168.1.0/24 log=no log-prefix="" в самом конце правило "Drop all other" В цепочке forward_to safe_city такие правила: /ip firewall filter> print chain=forward_to_safe_city 0 chain=forward_to_safe_city action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd before 1" 1 ;;; ACCEPT to Safe city network, filter on 105.62 chain=forward_to_safe_city action=accept dst-address=192.168.1.0/24 log=no log-prefix="" 2 chain=forward_to_safe_city action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd after 1" Хост с адресом 192.168.105.5 пытается подключиться к хосту 192.168.1.24 на порт 5900 (UltraVNC). В логе получаю следующее: 14:52:00 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:00 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 40 14:52:00 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 40 14:52:00 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 40 14:52:00 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 40 14:52:00 firewall,info drop invalid forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 40 14:52:03 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:03 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:03 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:03 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 52 14:52:03 firewall,info drop invalid forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51019->192.168.1.24:5900, len 52 Видно,что пакет с флагом SYN cначала проходит цепочку forward (строки с fwd before и fwd after), затем попадает в цепочку forward_to_safe_city, там отмечается (fwd before 1) получает accept и уходит по назначению. В ответ приходит пакет с флагами SYN,ACK (он не логируется). Далее хост должен ответить пакетом с флагом ACK. Он отвечает, но на микротике этот пакет почему-то не попадает под правила 1 и 2 в таблице forward и дропается правилом, которое дропает пакеты со статусом invalid. Если изменить порядок правил в цепочке forward, например, так, 0 chain=forward action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd before" 1 ;;; ACCEPT established connections chain=forward action=accept connection-state=established log=no log-prefix="" 2 ;;; ACCEPT related packets chain=forward action=accept connection-state=related log=no log-prefix="" 3 chain=forward action=log src-address=192.168.105.5 dst-address=192.168.1.24 log=yes log-prefix="fwd after" 4 ;;; JUMP to Safe city network chain=forward action=jump jump-target=forward_to_safe_city dst-address=192.168.1.0/24 log=no log-prefix="" 5 ;;; DROP invalid connections chain=forward action=drop connection-state=invalid dst-address=192.168.1.24 log=yes log-prefix="drop invalid" 6 ;;; DROP invalid connections chain=forward action=drop connection-state=invalid log=no log-prefix="" то все будет работать. Тот самый 3 пакет с флагом ACK уйдет в цепочку forward_to_safe_city, там получит accept и соединение установится. Но судя по логу таким способом будут проходить все пакеты, даже после того как соединение установлено, т.е. остальные пакеты не поподают под лействие правила с селекторм connection-state=established: 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (SYN), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 52 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,PSH), 192.168.105.5:51181->192.168.1.24:5900, len 41 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:38 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd before forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd after forward: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 15:18:43 firewall,info fwd before 1 forward_to_safe_ci: in:ether2-master-local out:ether2-master-local, src-mac f4:6d:04:2f:ab:3a, proto TCP (ACK,RST), 192.168.105.5:51181->192.168.1.24:5900, len 40 Может быть дело в том что конечная точка соединения в другой подсети и за другим роутером?

Пусть не управляемый, пусть посто группирует порты. Все равно не ясно: как он работает при включении этих преключателей? Может для него и мануал существует с их (переключателей) описанием? А то на оф.сайте 2ч страничный мануал в которм нет ничего.

А не подскажет ли кто-нибудь, как этот compex PS2216 настраивается при помощи переключателей? А то попалась в руки модель 2004 г.в, а настроить пока не получается. На сайте у них даже программа для настройки есть (Winsmart 4.0), но она, если я правильно понял подходит только для моделей >2005 г.в. Итак, что у нас есть. У нас есть несколько переключателей: Trunk1, Trunk2, Priority и Vlan. Собственно и вопрос в том, как будет работать этот свитч при включении различных переключателей. И какие комбинации возможны, или наоборот бессмысленны. Пока примерно ясно как работает Vlan: с портов 2-16 друг друга не видно, но есть доступ к порту 1 (т.е. имемем 15 port-based vlan на портах 2-16 и общий порт 1 (он trunk?) (поправьте, если не так)). Про режимы trunk1 и trunk2 здесь где-то уже встречал: trunk1: порты 1,2,9,10 могут использоваться для подключения к другому управляемому свитчу на скорости 400 mb/s; trunk2 - то же, но для портов 3,4,11,12. Так ли это? Приходится понемногу разбираться с сетями, поэтому вопросы могут показаться некорректными. На подробное объяснение не претендую, буду признателен за объяснение его работы в общих словах при включении различных переключателей.

А не подскажет ли кто-нибудь, как этот compex PS2216 настраивается при помощи переключателей? А то попалась в руки модель 2004 г.в, а настроить пока не получается. На сайте у них даже программа для настройки есть (Winsmart 4.0), но она, если я правильно понял подходит только для моделей >2005 г.в. Итак, что у нас есть. У нас есть несколько переключателей: Trunk1, Trunk2, Priority и Vlan. Собственно и вопрос в том, как будет работать этот свитч при включении различных переключателей. И какие комбинации возможны, или наоборот бессмысленны. Пока примерно ясно как работает Vlan: с портов 2-16 друг друга не видно, но есть доступ к порту 1 (т.е. имемем 15 port-based vlan на портах 2-16 и общий порт 1 (он trunk?) (поправьте, если не так)). Про режимы trunk1 и trunk2 здесь где-то уже встречал: trunk1: порты 1,2,9,10 могут использоваться для подключения к другому управляемому свитчу на скорости 400 mb/s; trunk2 - то же, но для портов 3,4,11,12. Так ли это? Приходится понемногу разбираться с сетями, поэтому вопросы могут показаться некорректными. На подробное объяснение не претендую, буду признателен за объяснение его работы в общих словах при включении различных переключателей.