lugoblin

SMB весьма чуствителен к latency. Если большие файлы перекачивать, то, может, взлетит. А если кучу мелких, или постоянный seek по большим, то будет тормозить. Сильно, причём независимо от толщины канала, что затрудняет объяснять пользователям в чём же дело. Я бы завёл специально обученную виртуалку на той-же локации что и w2019, и с одной стороны монтировал бы в неё папку по SMB, а с другой выставлял бы точку монтирования в Инет по SFTP или SSHFS.

Я сдаюсь. Очень путанно, руками надо смотреть.

Тогда я опять потерялся. Если ещё актуально, опишите цифрами "клиенты с одного аплинка, не могут зайти на адреса в другом аплинке", с какого адреса на какой, и на какой порт.

@Cramac Подключение с 178.х.х.213 на 91.х.50.8:3306 это то что вы пытаетесь починить?

Фильтрами же. server# tcpdump -i интерфейс port 31337 client# telnet 178.x.x.213 31337

Так вы, кажется, всё уже увидели. Если пакет пришёл на внутренний интерфейс для внешнего адреса, то ответ, хоть и от внешнего адреса, должен уходить с внутреннего же итерфейса. А если он уходит с внешнего интерфейса, значит по нему принято неверное решение о маршрутизации и следующий хоп его похерит. Как понять через какой интерфейс: смотрите на один интерфейс за раз. На какой смотрите, через тот и идёт.

Можно жёстко задать порты для данных --port-range и в явном виде их разрешить на файерволе. nf_conntrack_tftp и nf_nat_tftp же... Но не на Микротике, да. Можно сам Mikrotik в качестве TFTP сервера подрядить.

@alibek Попробуйте запросить файл по абсолютному пути, tftpd-hpa в этом отношении несколько путанно устроен. Permissions на файловой системе в порядке? Кроме порта 69, оно может использовать другие порты >1024 для трансфера данных, файервол должен их пропустить. На всякий случай, посмотрите сниффером.

Во первых, вот для этого вам не требуется морочиться с маркировкой пакетов. Если критерий для выбора маршрута это src_addr, то это можно делать непосредственно в ip rule. Во вторых, у вас таблица wan3 куцая. Проверьте сниффером, но я подозреваю что пакеты из серой сети до 178.x.x.213 добираются, а вот ответные уходят в дефолтный маршрут wan3, т.к. к ним сразу применяется правило 32765. В упрощённом случае, таблица wan3 должна содержать копию таблицы main, и отличаться только дефолтным маршрутом. Проверьте, если дело в этом то надо будет понять зачем в вас так много всего в таблице main и придумать как бы описать по аккуратнее то что ван нужно. Предположу, что адрес 188.x.x.242 отвечает серым сетям как надо.

@Cramac , покажите вывод: ip addr ip rule ip route ip route show table wan1 ip route show table wan2 ip route show table wan3 И уточните, с какого именно на какой адрес не проходит траффик.

Нет. Тема вполне обычная, но второго дефолта к провайдеру не надо, тем более с одинаковой метрикой.. Обычно делают статичный маршрут до адреса сервера VPN через провайдера, и уже потом дефолт отправляют в туннель. Например, до создания туннеля: default via 111.111.111.1 111.111.111.0/30 scope link src 111.111.111.2 Гейт провайдера 111.111.111.1, у нас 111.111.111.2, и мы с провайдером в сетке с маской 255.255.255.252. После создания туннеля с сервером 222.222.222.1, добавляем для него очень специфичный маршрут: default via 111.111.111.1 111.111.111.0/30 scope link src 111.111.111.2 10.10.10.1/32 dev ppp0 222.222.222.1 via 111.111.111.1 Внутри туннеля наш гейт 10.10.10.1, но пока Интернет работает как было. После перенаправления траффика в туннель, через гейт 10.10.10.1: default via 10.10.10.1 111.111.111.0/30 scope link src 111.111.111.2 10.10.10.1/32 dev ppp0 222.222.222.1 via 111.111.111.1 Траффик вне туннеля, до сервера VPN, подчиняется более специфичному маршруту. Всё остальное идёт по дефолтному. Можно не пререзаписывать существующий дефолтный маршрут, а оставить его в покое и дописать второй, с более приоритетной метрикой. При падении VPN - убрать. default via 111.111.111.1 metric 100 111.111.111.0/30 scope link src 111.111.111.2 10.10.10.1/32 dev ppp0 222.222.222.1 via 111.111.111.1 default via 10.10.10.1 metric 50 Если устройство не умеет играть метриками, то для назначения более приоритетного дефолтного маршрута можно схитрить. Так-же, при падении VPN убрать. default via 111.111.111.1 111.111.111.0/30 scope link src 111.111.111.2 10.10.10.1/32 dev ppp0 222.222.222.1 via 111.111.111.1 0.0.0.0/1 via 10.10.10.1 128.0.0.0/1 via 10.10.10.1

Очень разнообразная. В общем случае, если админить извне без VPN, что угодно, не только сетевое оборудование, то коннектиться через тщательно борнированный Jump Host, по SSH с ключами. В случае Микротиков, админить по SSH или HTTPS а не через Winbox, и по IP а не через Ethernet. Jump Host должен уметь проброс портов по SSH.   В письменном виде, обращаясь к Лицу Принимающему Решения, чётко сформулируйте текущую проблему, её причины, наносимый ущерб и перспективы повторения если не прининять превентивных мер. Обозначте план и стоимость решения, только коррективными мерами (сходить ногами, пожонглировать кабелями, неудобства для остальных клиентов, перспектива рецидива и т.д.), и используя превенивные меры (заменить свич на минимально управляемый, всех мигрировать, остальные мероприятия провести програмно). Есть подозрение, что стоимость второго варианта не будет существенно выше.

Если они уже перемешиваются, то задержка на вашем DHCP их отделить не поможет... Может быть, география распределения таких юзеров прольёт какой-то свет на местонахождение буки. Nmap-пом его можно потыкать, или каким-нибудь ещё инструментом для идентификации. В принципе, в такой ситуации усилия направляют не на "купирование" левого DHCP, а на его отключение. Совсем в грубом случае, можно вычленить глупый свич к которому он подключён, и вручную перепробовать все абонентские линии которые к нему стекаются, на какой ответит DHCP. Муторно, но это расплата за дешевизну свича.

Да, значит NAT не объехать. Выработайте у себя в 10.1.0.0/16 стандартное правило, по которому выделяются диапазоны адресов для отображения "странных" сетей, и мапьте.

Почему? А как камеры общаются с системой видеонаблюдения, на 4-ом уровне OSI? Камера стучится в DVR, или DVR подключается к камере? Если первое, то можно всю 192.168.1.0/24 смапить на один адрес в 10.1.0.0/16. А дать камерам адреса из 10.1.0.0/16, не? Их всё равно можно будет спрятать за Mikrotik-ом от остальной сети, и даже давать им адреса из его DHCP.