Я всегда с собой беру…
Некоторые сотовые провайдеры не разрешают раздавать их безлимитный интернет без дополнительной платы. Приобретать отдельное походное устройство по обеспечению широкополосного беспроводного доступа в глобальную сеть с абонентской платой более 1к рублей в месяц ради нескольких дней в году может совсем не хотеться. В связи с этими обстоятельствами в статье рассмотрено, как сотовые операторы узнают о раздаче доступа в интернет с мобильных устройств, а также какие возможности имеются на борту RouterOS по обеспечению приватности подобных действий.
В течение длинных новогодних каникул представляю короткую инструкцию по организации походного интернета на скорую руку и примерно как дома. Без особой подготовки, серьёзных материальных затрат и требуемого времени. Многие из нас сейчас собирают чемоданы для поездки на дачу или даже куда-то гораздо подальше. Многим всё равно необходимо пару часов по вечерам проводить за работой. Разумеется, без интернета не обойтись. 4G и 3G сейчас работает хорошо и много где, поэтому в таких поездках я всегда беру с собой дешёвый MikroTik стоимостью 1500 рублей, который подключаю к своему телефону по Wi-Fi. Вопрос этичности подобных действий рассматривать не буду, так как статья техническая и носит исключительно исследовательский характер.
Для начала вооружаемся роутером hAP mini (в соответствии с маркировкой производителя RB931–2nD). Его кстати после прохождения официального тренинга раздают почти бесплатно.
У этого скромного девайса некоторое время как уже имеется на борту работающая технология Powerline, которая позволяет использовать специализированные сетевые адаптеры для построения проводных LAN на основе связанных электрических линий (проводов, несущих ток 220 вольт, спрятанных в стенах и потолках наших домов). Помнится, в уже далёком 2005 году это называлось лозунгом, вроде такого: «Раздаём интернет прямо из розетки»! Более подробную информацию от вендора по настройке технологии можно почитать здесь и здесь. Забавная фича, и, кстати, дополнительный полноценный LAN порт. В гостинице можно попытаться поднять собственную проводную локалку между друзьями единомышленниками, находясь при этом на разных этажах. Зарубиться во что-то сетевое, как в старые добрые времена, до прихода в нашу жизнь высокоскоростного интернета и облачных технологий с их игровыми аккаунтами. Этакий дух компьютерных игровых клубов, как коммерческих, так и любительских, развёрнутых внутри студенческих общежитий технических университетов.
Возвращаюсь к предмету статьи. На текущий момент в дикой природе в странах СНГ я встречал только такой способ обнаружения раздачи интернета, применяемый сотовыми операторами, как анализ TTL на сетевом уровне. Коротко по существу. Мой сотовый телефон использует для исходящих пакетов TTL, равный 64. Таким образом, на gateway-default провайдера приходят пакеты именно такие. Если я попытаюсь раздать интернет своему laptop, то он уже использует TTL равный 128 (хотя это не важно, в принципе). Раздатчик интернета (телефон) каждому пакету изменит его на 127, следовательно, gateway-default провайдера получит легко узнаваемые пакеты и оправит меня на страницу заглушку, подрубив интернет до значений, близких к нулю. Даже, если интернет будет роздан не ноутбуку, а другому телефону, то всё равно на оборудование провайдера придёт 63, что опять-таки легко распознаваемо.
Из представленного описания видно, что анализ TTL является функцией L3 Firewall, поэтому для препятствования его работы можно воспользоваться маркировкой трафика, отлично функционирующей в рамках RouterOS, и выставить нужное замаскированное значение:
/ip firewall mangle
add action=mark-connection chain=postrouting comment="LAN=>WAN connections" new-connection-mark="LAN=>WAN connections" out-interface=wlan1-Station passthrough=yes
add action=mark-packet chain=postrouting comment="LAN=>WAN packets" connection-mark="LAN=>WAN connections" new-packet-mark="LAN=>WAN packets" passthrough=yes
add action=change-ttl chain=postrouting comment="LAN=>WAN packets change TTL to 65" new-ttl=set:65 packet-mark="LAN=>WAN packets" passthrough=yes
Обращаю внимание на имя исходящего интерфейса wlan1-Station. Людям, хорошо не знакомым с оборудованием MikroTik, может быть непонятно, что оно означает. RouterOS позволяет использовать свои «железные» беспроводные интерфейсы в качестве Wi-Fi клиентов. Это позволяет подключаться к раздатчику интернета (он же сотовый телефон) по беспроводному каналу. Для этого настраиваем профиль безопасности:
/interface wireless security-profiles
add authentication-types=wpa2-psk disable-pmkid=yes eap-methods="" mode=\
dynamic-keys name=myPhone supplicant-identity="" wpa2-pre-shared-key=0123456789
Затем настраиваем не виртуальный беспроводной интерфейс:
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n disabled=no frequency=auto \
name=wlan1-Station radio-name="" security-profile=myPhone ssid=”RUVDS" wireless-protocol=802.11
Если всё корректно, то можно увидеть информационное сообщение connected to ess с прилагаемыми техническими подробностями:
Осталось получить от телефона сетевые настройки, а так как они будут динамическими, то здесь нам понадобится маскарад:
/ip dhcp-client add disabled=no interface=wlan1-Station use-peer-dns=no use-peer-ntp=no
/ip firewall nat add action=masquerade chain=srcnat out-interface=wlan1-Station
Далее имеется логичная возможность раздать интернет уже посредством MikroTik, для этого проделываем похожие действия:
/interface wireless security-profiles
add authentication-types=wpa2-psk comment=ourHome disable-pmkid=yes \
eap-methods="" mode=dynamic-keys name=Home supplicant-identity="" \
wpa2-pre-shared-key=veryStrongPassword!
/interface wireless
add disabled=no keepalive-frames=disabled \
master-interface=wlan1-Station multicast-buffering=disabled name=\
wlan1-Virtual-AP security-profile=Home ssid=Home wps-mode=disabled
Интерфейс »wlan1-Virtual-AP» является виртуальным и поэтому унаследует большинство технических характеристик от мастер интерфейса »wlan1-Station». Важно учитывать, что клиентом Wi-Fi может выступать только не виртуальный интерфейс роутера. Дополнительно, если по какой-то причине мастер интерфейс не подключён к точке доступа, то связанный с ним виртуальный интерфейс так же не будет функционировать. Другими словами, ваша собственная точка доступа Wi-Fi от роутера будет не активна, пока RouterOS не соединиться с мобильным телефон, раздающим интернет. В целях снижения утилизации эфирного времени, если имеется более продвинутый MikroTik, то лучше раздать интернет в другом диапазоне. Например, если сотовый телефон работает в режиме модема на беспроводном канале из диапазона 2.4 ГГц, то Wi-Fi на роутере следует запустить в диапазоне 5 ГГц:
/interface wireless
set [ find default-name=wlan2 ] band=5ghz-a/n/ac channel-width=20/40mhz-XX \
disabled=no frequency=auto mode=ap-bridge name=wlan2-AP security-profile=\
Home ssid=Home5GHz wireless-protocol=802.11 wps-mode=disabled
Ниже представляю оставшийся минимум настроек RouterOS, чтобы не отправлять не подготовленного читателя в увлекательное путешествие по сети интернет при попытках воспроизвести подобное решение:
/interface bridge add dhcp-snooping=yes fast-forward=no name=bridgeHome
/ip address add address=10.0.0.1/24 interface=bridgeHome network=10.0.0.0
/ip pool add name=poolHome ranges=10.0.0.2-10.0.0.254
/ip dhcp-server network add address=10.0.0.0/24 dns-server=10.0.0.1 gateway=10.0.0.1 netmask=24
/ip dhcp-server add address-pool=poolHome disabled=no interface=bridgeHome lease-time=12h name=serverHome
/interface bridge port
add bridge=bridgeHome interface=ether1
add bridge=bridgeHome interface=ether2
add bridge=bridgeHome interface=ether3
add bridge=bridgeHome interface=wlan1-Virtual-AP
/ip dns set allow-remote-requests=yes servers=8.8.8.8,8.8.4.4,1.1.1.1
/system clock set time-zone-name=Europe/Moscow
/system identity set name=MikroTik
/system ntp client set enabled=yes primary-ntp=ntp1.stratum2.ru secondary-ntp=ntp2.stratum2.ru
Добавлю немного безопасности, чтобы сдавать устройство, готовое к эксплуатации из коробки:
/ip firewall filter
add action=accept chain=input comment="Input Established,Related=>Accept" connection-state=established,related
add action=drop chain=input comment="Input Invalid=>Drop" connection-state=invalid
add action=drop chain=input comment="Input !bridgeHome=>Drop" in-interface=!bridgeHome
add action=accept chain=forward comment="Forward Established,Related=>Accept" connection-state=established,related
add action=drop chain=forward comment="Forward Invalid=>Drop" connection-state=invalid
add action=drop chain=forward comment="Forward !dst-nat=>Drop" connection-nat-state=!dstnat in-interface=wlan1-Station
/ip service
set telnet disabled=yes
set ftp disabled=yes
set api disabled=yes
set api-ssl disabled=yes
/interface list add name=LAN
/interface list member add interface=bridgeHome list=LAN
/ip neighbor discovery-settings set discover-interface-list=LAN protocol=mndp
/tool mac-server set allowed-interface-list=none
/tool mac-server mac-winbox set allowed-interface-list=LAN
/tool mac-server ping set enabled=no
Стоит упомянуть о том, что изменять TTL можно и на клиентских устройствах. Делается это достаточно просто на операционных системах Windows и Linux (при наличии, конечно, соответствующих прав). Однако, во-первых, в целом это не очень удобно. Во-вторых, не решает вопрос со смартфонами и подобными устройствами. Следовательно, решить проблему с TTL именно на шлюзе — отличная идея.
Добавлю, что в вопросе блокировки трафика со стороны мобильных провайдеров я встречал странную практику. Вместо того, чтобы дропать весь интернет не родиевого клиента, сотовый оператор рубил только DNS пакеты. Вариантов, как это можно перепрыгнуть, достаточно много. Мне нравится подкрутить маршрутизацию, направив DNS пакеты в шифрованный VPN туннель:
/ip route
add check-gateway=ping comment="DNS over OVPN" distance=1 gateway=192.168.15.1 routing-mark="DNS routing"
/ip route rule
add action=lookup-only-in-table comment="DNS over VDS" dst-address=1.1.1.1/32 table="DNS routing"
add action=lookup-only-in-table comment="DNS over VDS" dst-address=8.8.8.8/32 table="DNS routing"
add action=lookup-only-in-table comment="DNS over VDS" dst-address=8.8.4.4/32 table="DNS routing"
Для любителей загрузить качественное кино гигабайт на 15 размером посредством торрент обменников, могу сказать, что это не понравится ни одному мобильному провайдеру. А соответственно можно ожидать и санкций от них в виде низкой скорости на уровне 5 кбит/с, так что на загрузку может понадобиться несколько недель:
VPN и здесь сделает свое дело. Немного изменяем настройки для dhcp-client, назначаем статические маршруты и дополним Firewall еще одним правилом:
/ip dhcp-client add disabled=no interface=wlan1-Station use-peer-dns=no use-peer-ntp=no add-default-route=no
/ip route add dst-address=ipVpnServera gateway=172.20.10.1
/ip route add dst-address=0.0.0.0/0 gateway=192.168.15.1
/ip firewall nat add action=src-nat chain=srcnat comment="SRC-NAT for ovpn-out" out-interface=ovpn-out1 to-addresses=ipVpnClient
На сервере не забываем включить ip forward и настроить NAT, например, так:
iptables -t nat -A POSTROUTING -s 192.168.15.0/24 -o eth0 -j SNAT --to-source ipVpnServer
echo '1' > /proc/sys/net/ipv4/ip_forward
В результате весь трафик будет вложен внутрь VPN туннеля, общая скорость интернета припадёт, но торренты качаться будут уверенно:
Добавлю, что VPN серверы позволяют передать клиентам дополнительные сетевые настройки. Например, если в файле конфигурации OpenVPN сервера указать строку ниже, тогда он будет назначен в качестве шлюза по умолчанию, конечно, если клиентская сторона это разрешит:
push "redirect-gateway def1"
Для troubleshooting можно воспользоваться сайтом 2ip.ru, который должен будет показать подробную информацию не о ваших домашних устройствах, а об VDS сервере, на котором вертится VPN. Здесь важно упомянуть, что в представленных схемах при настройке VPN клиентов на RouterOS нужно использовать IP адрес вместо доменного имени сервера, иначе описанные механизмы не смогут завестись по техническим причинам. Также на удалённом сервере можно запустить программу Tcpdump, и увидеть пролетающие пакеты:
tcpdump -i eth0 port 53
16:04:21.179296 IP ruvds.ru.35058 > dns.google.domain: 31590+ A? fonts.gstatic.com. (35)
16:04:21.180286 IP ruvds.ru.42023 > dns.yandex.ru.domain: 36125+ PTR? 8.8.8.8.in-addr.arpa. (38)
16:04:21.183646 IP dns.yandex.ru.domain > ruvds.ru.42023: 36125 1/0/0 PTR dns.google. (62)
16:04:21.184318 IP ruvds.ru.51949 > dns.yandex.ru.domain: 24509+ PTR? 8.8.88.77.in-addr.arpa. (40)
16:04:21.191127 IP dns.yandex.ru.domain > ruvds.ru.51949: 24509 1/0/0 PTR dns.yandex.ru. (67)
Вот в принципе и всё, по предмету разговора. Я всегда с собой беру роутер MikroTik. На новом месте добавляю при необходимости новые »wireless security-profiles», немного настраиваю беспроводной интерфейс и пользуюсь интернетом, как дома. А без собственного облачного сервера сейчас IT специалисту ну никак не обойтись.
Подведём итоги
Откуда провайдеры мобильного интернета узнают, что за нашим шлюзом зиждется новая компьютерная сеть? Основной способ это, конечно, анализ TTL, который относится по компетенции к работе L3 Firewall. Грамотно настроенный Firewall Filter, NAT и Mangle на RouterOS могут полностью скрыть это на сетевом уровне. Что касается прикладного уровня, то здесь уже начинается участок ответственности IDS (IPS) систем. Конечно, большинство современного интернет-трафика на текущий момент использует шифрование, однако Wireshark доказывает, что всё равно регулярно встречаются использование HTTP в работе различных скриптов даже на сайтах, работающих под HTTPS. Здесь уже есть с чем поработать, например, заголовок User-Agent выдаст с потрохами ваш браузер:
Конечно, и на этот способ легко реализовать способы противодействия, так как, в конечном счёте, это бесконечная гонка. Игра в кошки мышки. Что применимо в целом к отрасли информационной безопасности. На этом все, пора вновь присоединяться к праздничному веселью. С наступившим Новым годом, читатели Хабра!
