Как сделать Mikrotik прозрачным в сети?
Есть сеть организации 192.168.50.1\24 с выходом в Интернет. Каждый компьютер и устройство прописаны по маку и имеют закреплённый за ними IP. Один из компьютеров подключён через Mikrotik, MAC скопирован с компьютера, к нему же подключен расшаренный принтер. Когда это всё это было без маршрутизатора, то работало нормально — все компьютеры видели друг друга, резолвили имена и тд, расшаренные принтеры, сетевые шары, никаких проблем. С Mikrotik’ом стало похуже — с этого компьютера доступ к другим есть, а его не видно из сети вообще. Возможно ли сделать так, чтобы Mikrotik стал совершенно прозрачным для всех в этой сети, чтобы работали расшаренные принтеры, сетевые шары и тд?
UPD: По совету воткнул оба кабеля в LAN порты. В итоге внутренняя сеть стала работать, всё видится, на всё заходит. Но, внешний интернет не работает. Можно ли прописать маршрут на микротике 0.0.0.0/0 через шлюз 192.168.50.1, чтобы работал интернет или это делается каким-то более сложным вариантом?
Кроме того, насколько я понял, имеются две подсети: организации — 192.168.50.1/24 и всего, что будет включено в микротик — 192.168.88.1/24; и нужно соединить эти две подсети?
Если сделать так: на всех компьютерах сети 192.168.50.1/24 прописать
route add 192.168.88.1 mask 255.255.255.0 192.168.88.1
а на самом роутере маршрут до 192.168.50.1/24 через шлюз 192.168.50.1? Будет ли работать такая схема?
Маршрутизация локальной сети через прозрачный socks-прокси
Потребовалось пустить трафик со всех домашних устройств, включая смартфоны, через ssh tunnel.
Советую другой способ с использованием tun2socks.
- маршрутизатор TP-LINK, подключенный к провайдеру.
- смартфоны и ноутбук подключенные к беспроводной точки доступа маршрутизатора.
Ноутбук находился далеко от маршрутизатора (в другой комнате) и регулярно использовался, поэтому пришлось искать решение маршрутизации трафика с помощью встроенного беспроводного интерфейса (и без всяких там eth0).
Инструментарий:
openssh-client — стандартный ssh клиент для linux.
autossh — позволяет проверять соединение с ssh сервером, и подключаться при разрыве.
redsocks — прозрачный socks-прокси сервер.
isc-dhcp-server — dhcp сервер.
iptables — думаю, комментарии излишне.
Итак, приступим. Первым делом поднимем DHCP сервер на беспроводном интерфейсе ноутбука.
Настроим нужный интерфейс:
Узнать название необходимого интерфейса можно командой:
Далее настроим сам dhcp сервер:
Должен содержать строчку с указанием необходимого интерфейса:
Пробежимся по главным параметрам:
option domain-name-servers — адреса DNS серверов, которые получат клиенты при подключении. В случае наличия локального DNS сервера (как у меня), необходимо указать адрес интерфейса 192.168.1.100.
range — диапазон присваиваемых IP адресов.
option routers — этот адрес будет служить шлюзом для клиентов.
Настройка завершена, необходимо перезапустить службу командой:
Проверить состояние можно командой:
Осталось только настроить маршрутизатор на использование нашего DHCP сервера, а именно, переключить режим DHCP, в настройках LAN на «Relay» и указать там, IP адрес нашего DHCP сервера — 192.168.1.100.
Теперь все устройства, подключающиеся к точке доступа роутера, будут получать сетевые настройки от сетевого интерфейса ноутбука, но сам доступ в интернет необходимо настроить. Напомню, что задача состоит в том, чтобы трафик всех устройств, включая ноутбук заворачивал в ssh-туннель. На мой взгляд ssh туннель разумней запускать в качестве службы, которая будет принимать перенаправления от прокси сервера redsocks.
Установим необходимый инструментарий:
Если мы хотим иметь постоянный ssh туннель, который активируется при загрузки системы, необходимо создать службу systemd и включить ее. Так как мы будем использовать autossh, нужно заметить, что параметр -f (работа в фоне) включающий в себя параметр AUTOSSH_GATETIME=0, не поддерживается в systemd. Поэтому нужно указать использование параметра AUTOSSH_GATETIME=0 явно. Вот так выглядит базовая конфигурация сервиса:
After=network.target — Запуск службы при наличии сетевого подключения.
Environment=«AUTOSSH_GATETIME=0» — указывает systemd работу ssh в фоне.
Отдельно следует рассмотреть параметр ExecStart:
Запуск autossh со следующими параметрами:
-M — порт мониторинга. С этим параметром autossh будет непрерывно посылать запросы на сервер через указанные порты, если от сервера не приходит ответ, autossh подключается заново. Указанный порт мониторинга и порт порядком выше (+1) должны быть свободными в системе. Так как это делает такой мониторинг не практичным, мы отключаем эту функцию указывая значение 0.
«- o ServerAliveInterval» и «-o ServerAliveCountMax» — две опции, указывающие ssh клиенту отправлять запросы серверу непосредственно через туннель (то что нам нужно), чтобы поддерживать соединение, когда оно не активно. Также, если от сервера не следует ответа, соединение будет считаться разорванным и autossh подключается заново.
-N — не отправлять команд на сервер.
-D 1080 — открываем динамический порт на localhost.
user@server — здесь следует указать пользователя и адрес(доменное имя) сервера.
-p 22 — указываем порт подключения.
Включаем запуск во время загрузки:
Итак, запущены DCHP сервер на беспроводном интерфейсе ноутбука и стабильный ssh туннель в системе, осталось только завернуть в него трафик со всех устройств в локальной сети. Сделаем это с помощью redsocks и iptables.
Сохраняем конфиг и перезагружаем службу:
Остался, последний трюк с использование iptables. Предлагаю сразу создать скрипт со следующим содержанием:
Теперь все запросы с локальной сети, включая хост, будут направляться в ssh туннель.
Прозрачный обход блокировок в домашней сети
Последние новости в очередной раз заострили проблему блокировок интернет-ресурсов. С одной стороны о способах их обхода написано немало, и пережевывать эту тему в очередной раз казалось бы незачем. С другой, регулярно предпринимать какие-то дополнительные действия для посещения нужного ресурса — это не совсем то, что должно удовлетворить айтишника (и не всегда то, с чем может справится человек к айти неблизкий).
Нужно простое и прозрачное для пользователей решение, которое, будучи единожды настроенным, позволит просто пользоваться интернетом, не задумываясь, что же сегодня заблокировали по заявкам очередных копирастов-плагиаторов.
Сама собой напрашивается мысль о том, чтобы обходить блокировку уже на домашнем маршрутизаторе.
Собственно, поднять на маршрутизаторе и гонять весь траффик через VPN несложно, а у некоторых VPN-провайдеров есть даже пошаговые инструкции по настройке OpenWrt на работу с ними.
Но скорости VPN сервисов все же отстают от скоростей доступа в интернет, да и VPN-сервис либо стоит денег, либо имеет массу ограничений, либо необходимость регулярного получения новых логинов. С точки зрения оптимизации затрат, как финансовых, так и временных, предпочтительней выглядит Tor, но его скорость еще хуже, а гонять через Tor торренты и вовсе идея не лучшая.
Выход — перенаправлять в VPN/Tor только траффик блокируемых ресурсов, пропуская остальной обычным путем.
Внимание: данная схема не обеспечивает анонимности просмотра заблокированных сайтов: любая внешняя ссылка раскрывает ваш настоящий IP.
Конкретная реализация на OpenWrt приведена в конце статьи. Если не интересуют подробности и альтернативные варианты решения, то можно листать сразу до нее.
Туннелирование и перенаправление траффика в туннель
Настройка VPN или Tor’а сложностей представлять не должна. Tor должен быть настроен, как прозрачный proxy (либо настроить связку из tor и tun2socks). Т.к. конечной целью явлется обход блокировок ркн, то в конфиге Tor’а целесообразно запретить использование выходных узлов на территории РФ ( ).
В Tor’а траффик перенаправляется правилом с REDIRECT ’ом на порт прозрачного прокси в цепочке PREROUTING таблицы nat netfilter’а.
Для перенаправления в VPN (или Tor + tun2socks) траффик маркируется в таблице mangle , метка затем используется для выбора таблицы маршрутизации, перенаправляющей траффик на соответствующий интерфейс.
В обоих случаях для классификации траффика используется ipset с хостами, подлежащими (раз)блокировке.
Формирование ipset c (раз)блокируемыми хостами
К сожалению, вариант «загнать все IP из реестра» в ipset не работает как хотелось бы: во-первых в списках присутствуют не все IP адреса блокируемых хостов, во-вторых в попытке уйти от блокировки IP адрес у ресурса может измениться (и провайдер об этом уже знает, а мы – еще нет), ну и в третьих – false positives для находящихся на том же shared hosting’е сайтов.
Городить огород с dpi того или иного вида не очень хочется: как-никак работать это должно на довольно слабом железе. Выход достаточно прост и в какой-то степени элегантен: dnsmasq (DNS сервер, который на маршрутизаторе скорее всего уже установлен) умеет при разрешении имен добавлять ip-адреса в соответствующий ipset (одноименная опция в конфиге). Как раз то, что нужно: вносим в конфиг все домены, которые необходимо разблокировать, и дальше по необходимости dnsmasq сам добавляет в ipset именно тот ip адрес, по которому будет идти обращение к заблокированному ресурсу.
У меня были сомнения, что dnsmasq запустится и будет нормально работать с конфигом в полдесятка тысяч строк (примерно столько записей в реестре после усушки и утряски), однако они к счастью оказались безосновательны.
Ложка дегтя в том, что при обновлении списка dnsmasq придется перезапускать, т.к. по SIGHUP он конфиг не перегружает.
Составление списка доменов
Должно происходить автоматически, насколько это возможно.
Первый вариант (который и реализован в примере): формировать список на основе единого реестра блокировок и обновлять его по cron’у.
Роскомнадзор широкой общественности реестр блокировок не предоставляет, однако мир не без добрых людей и есть минимум два ресурса, где с ним можно ознакомиться. И, что отлично, API у них тоже имеется. При разборе списка нужно учесть, что в списке доменных имен помимо собственно доменных имен присутствуют и IP адреса. Их нужно обрабатывать отдельно (или вообще на них забить: их примерно 0,1% от списка и врядли они ведут на интересующие вас ресурсы). Кириллические домены далеко не всегда представлены в punycode. Немалую часть списка занимают поддомены на одном домене второго уровня, указаны домены с www/без www и просто дублирующиеся записи. Все перечисленное в большей степени относится к списку от rublacklist.net (он в добавок еще и странно, местами некорректно, экранирован). Именно для него пришлось городить монструозный lua-script (приводится ниже), нормализующий и сжимающий список почти в два раза. C antizapret.info ситуация сильно лучше и можно было бы обойтись однострочником на awk.
Можно пойти другим путем: многие провайдеры при обращению к заблокированному ресурсу перенаправляют на заглушку об ограничении доступа. Например http://block.mts.ru/?host=/host/&url=/url/¶ms=/params/ . Подменив с помощью того же dnsmasq ( address=/block.mts.ru/192.168.1.1 ) A-запись block.mts.ru на адрес веб-сервера маршрутизатора (и разместив на нем несложный скрипт) можно локально формировать список запрошенных пользователями сети заблокированных ресурсов, добавлять их в конфиг dnsmasq, повторно делать nslookup (чтобы ip адрес добавился в ipset) и еще раз редиректить пользователя на первоначальный URL. Но необходимость каждый раз при этом перезапускать dnsmasq несколько расхолаживает. Да и работать будет только для http.
Теперь еще об одной ложке дегтя: некоторое провайдеры замечены за тем, что помимо включенных в список ркн сайтов самодеятельно блокируют и официально в списках не значащиеся. При этом блокируют тихой сапой и заглушки не выводят. Так что совсем без ручного привода не обойтись.
Дополнительные замечания
DNS серверы провайдера использовать в качестве апстрим серверов естественно не стоит. Ибо блокировка может произойти еще на стадии разрешения имени ресурса. Отдаст сервер провайдера на искомый адрес, что это CNAME block.mts.ru и все. Наиболее простое решение server=8.8.8.8, server=8.8.4.4 . Модификации провайдерами DNS-ответов сторонних серверов лично я пока не наблюдал. В случае, если начнут — можно отправлять запросы доменов из запретного списка на другой апстрим (через VPN/Tor), однако без надобности я бы конфиг не раздувал.
При использовании Tor’a можно бонусом получить возможность серфинга по .onion сайтам: Tor при разрешении имени через встроенный dns-сервер отобразит его на виртуальный адрес из заранее заданного диапазона. Дальше нужно только перенаправить обращение к этому адресу на прокси Tor’а и voila. Но еще раз напомню, что анонимности подключение с избирательным туннелированием трафика не обеспечивает.
Реализация на OpenWrt (15.05)
Сам маршрутизатор должен быть не самый плохой, особенно при использовании Tor’а. MIPS 400MHz@32MB RAM это тот минимум, который стоит рассматривать.
При наличии USB-порта недостаток встроенного флеша можно компенсировать USB-флешкой (вообще мне представляется достаточно здравой идея не использовать встроенный флеш для регулярно перезаписываемых данных).
Штатно в прошивках OpenWrt содержится урезанный dnsmasq, не умеющий ipset. Необходимо заменить его на dnsmasq-full.