LINUX.ORG.RU
ФорумAdmin

iptables. Подменить IP адрес в запросе

 


0

2

Привет!

Я купил китайский анализатор воздуха Xiaomi ClearGrass Air Detector и он по mqtt работает только с китайским сервером, а я бы хотел получать информацию с него в локальной сети.

ClearGrass подключен по Wi-Fi к Raspberry Pi, которая работает точкой доступа. C помощью tcpdump я вижу как ClearGrass общается с mqtt.cn.cleargrass.com.

Мне нужно пакеты предназначенные для mqtt.cn.cleargrass.com направлять на локальный mqtt сервер и отвечать от имени mqtt.cn.cleargrass.com. Я не специалист в iptables и мои правила не работают:

sudo iptables -i wlan0 -t nat -A PREROUTING -d 154.8.191.174 -p tcp -j DNAT --to 127.0.0.1

Пробовал и все запросы от анализатора направлять на 127.0.0.1:

sudo iptables -i wlan0 -t nat -A PREROUTING -s 192.168.115.19 -p tcp -j DNAT --to 127.0.0.1
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

Подскажите советом, что я делаю не так?

★★

Последнее исправление: aivs (всего исправлений: 1)

Мне нужно пакеты предназначенные для mqtt.cn.cleargrass.com направлять на локальный mqtt сервер и отвечать от имени mqtt.cn.cleargrass.com.

тебе надо DNS запись подменить

targitaj ★★★★★
()
Ответ на: комментарий от slowpony

Ну значит тогда пусть на шлюзе добавит этот ip на свой интерфейс

targitaj ★★★★★
()

можешь попробовать использовать какую нибудь програмку для mitm атак (например mitmproxy) в этих целях. Ну или подменить dns запись на свой локальный ip развернув dns сервер (например pdnsd) и заставив анализатор использовать его.

anonymous
()
Ответ на: комментарий от anc

У меня настроено так:

pi@raspberrypi:~ $ grep "ip_forward" /etc/sysctl.conf 
net.ipv4.ip_forward=1

Добавлю еще

net.ipv4.conf.wlan0.route_localnet=1
aivs ★★
() автор топика
Ответ на: комментарий от targitaj

В cat /etc/dnsmasq.conf добавил записи:

address=/mqtt.cn.cleargrass.com/127.0.0.1
address=/ott.io.mi.com/127.0.0.1
alias=154.8.191.174,127.0.0.1

mqtt.cn.cleargrass.com = 154.8.191.174
ott.io.mi.com - это какой то китайский dns

Отрабатывает только address=/ott.io.mi.com/127.0.0.1, т.е. DNS запросы для ott.io.mi.com перекидываются на локальный DNS сервер, это видно по tcpdump.

aivs ★★
() автор топика
Последнее исправление: aivs (всего исправлений: 1)

«iptables -t nat -A POSTROUTING -j MASQUERADE»

Откуда вы все это берете?

Хотя бы «iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE»

Заворачивать на 127.0.0.1 - не очень хорошая идея.

Самый безопасный вариант - поднять интерфейс dummy с каким-нибудь статическим адресом и DNAT-ить на него.

vel ★★★★★
()
Ответ на: комментарий от vel

У Raspberry Pi на wlan0 статический адрес 192.168.115.1 Сейчас сделал такую конфигурацию:

sysctl -w net.ipv4.ip_forward=1
sysctl -w net.ipv4.conf.wlan0.route_localnet=1

Все входящие пакеты на интерфейсе wlan0 предназначенные для 154.8.191.174 перебрасывать на 192.168.115.1

sudo iptables -i wlan0 -t nat -A PREROUTING -d 154.8.191.174 -j DNAT --to-destination 192.168.115.1

Не работает, tcpdump по прежнему показывает, что пакеты идут на 154.8.191.174, а не на 192.168.115.1. Что не так?

aivs ★★
() автор топика
Ответ на: комментарий от aivs

sysctl -w net.ipv4.conf.wlan0.route_localnet=1

Это только для варианта 127.0.0.1 в вашем случае уже не нужно.

anc ★★★★★
()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от aivs

Только проблема в том, что если ты заворачивашь все пакеты, то их кто-то должен слушать на 192.168.115.1

tcpdump видит пакет только в 2-х места (смотри http://inai.de/images/nf-packet-flow.svg про AF_PACKET)

Если все плохо и больше мыслей нет, то -j TRACE в помощь.

vel ★★★★★
()
Ответ на: комментарий от vel

На самой Raspberry Pi запущен mosquitto брокер, который должен принимать пакеты предназначенные для 154.8.191.174.

Еще раз о задаче:
Датчик по wifi подключен к Raspberry Pi и общается с китайским сервером. На Raspberry Pi нужно все пакеты для 154.8.191.174 перенаправлять на 127.0.0.1 или 192.168.115.1

aivs ★★
() автор топика
Ответ на: комментарий от aivs

mqtt ходит по tcp, по 2-м портам. Их и нужно dnat-ить.

Брокер должен слушать тот адрес, на который ты делаешь dnat.

Может ли этот брокер работать как прозрачный прокси - не знаю.

vel ★★★★★
()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от sanwashere

Сделал

sudo iptables -i wlan0 -t nat -A PREROUTING -d 154.8.191.174 -p tcp -j REDIRECT --to-ports 1883

Пакеты на интерфейсе wlna0 предназначенные для 154.8.191.174 перенаправлять на локальный порт 1883.
На 1883 у меня слушает mosquitto, но от датчика так ничего и не получил, tcpdump показывает, что пакеты по прежнему идут на сервер 154.8.191.174.

 192.168.115.19.34098 > 154.8.191.174.1883: Flags [P.], cksum 0x6d98 (correct), seq 56722:57259, ack 230, win 490, options [nop,nop,TS val 16742851 ecr 4134052668], length 537

Еще какое то правило нужно?

Добавил еще правило: все пакеты от датчика направлять на шлюз:

sudo iptables -i wlan0 -t nat -A PREROUTING -s 192.168.115.19 -p tcp -j REDIRECT

Не работает

aivs ★★
() автор топика
Последнее исправление: aivs (всего исправлений: 4)
Ответ на: комментарий от sanwashere

Вот такие эксперименты с iptables наделал:

pi@raspberrypi:~ $ sudo iptables -t nat -L -n -v
Chain PREROUTING (policy ACCEPT 35981 packets, 3144K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 REDIRECT   tcp  --  wlan0  *       0.0.0.0/0            154.8.191.174        redir ports 1883
 6758  405K REDIRECT   tcp  --  wlan0  *       192.168.115.19       0.0.0.0/0           
    0     0 REDIRECT   tcp  --  wlan0  *       192.168.115.19       0.0.0.0/0            redir ports 1883

Chain INPUT (policy ACCEPT 43522 packets, 3596K bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain POSTROUTING (policy ACCEPT 6 packets, 1050 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 174K   11M MASQUERADE  all  --  *      eth0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 159K packets, 9671K bytes)
 pkts bytes target     prot opt in     out     source               destination 

и вот netstat

pi@raspberrypi:~ $ sudo netstat -ltpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:8084            0.0.0.0:*               LISTEN      398/mongoose        
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1266/dnsmasq        
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      574/sshd            
tcp        0      0 127.0.0.1:52698         0.0.0.0:*               LISTEN      14922/sshd: pi@pts/ 
tcp        0      0 0.0.0.0:1883            0.0.0.0:*               LISTEN      15564/mosquitto     
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      398/mongoose        
tcp        0      0 0.0.0.0:44545           0.0.0.0:*               LISTEN      13229/z-way-server  
tcp        0      0 0.0.0.0:8083            0.0.0.0:*               LISTEN      13229/z-way-server  
tcp6       0      0 :::53                   :::*                    LISTEN      1266/dnsmasq        
tcp6       0      0 :::22                   :::*                    LISTEN      574/sshd            
tcp6       0      0 ::1:52698               :::*                    LISTEN      14922/sshd: pi@pts/ 
tcp6       0      0 :::1883                 :::*                    LISTEN      15564/mosquitto 

В результате я хочу в mosquitto видеть, что ему приходит mqtt сообщение, но этого нет.

aivs ★★
() автор топика
Ответ на: комментарий от aivs

Запустил nc -l 80 и мне пришел запрос! Это уже прогресс!

pi@raspberrypi:~ $ sudo nc -l 80
GET /now_time?data=DIDk5TAOF66bXYeO6izyIjNKxoonmLW+KIkWe1fbFfUkmF2fOqO++ZlFZWvdg9Vy+Grv6pM/niU/9nRVEZvH3pI9Jinc8SUtyMIPZgXbVdoUu4ucarBbKnEu3X8gAb0SYs0SGMG68y/+Lfk/KYrUmF+Npjyt6+SxW9q+t2fU9595G0CQpMlDD5tF2NFCl9un8bejxtvQMaTx/B6ry8GLMGj/gHbrTnlH0HPcuUvjazoHb7NDzuEr/N9TQN3+BVjDEMlhx9QynGGzSM8KuSoX7s4WrGfXodCdU0OMHk/ZED11kP7JI2jc/A97DvyT9dmdGjrqj6eKOVF+5LHU0M87ew== HTTP/1.1
timestamp: 1581806870
version: 3.4.5_0137
source: Snow
kid: 6F9D1622F75427882D96506DE26567CD
lang: en_US
Content-Type: application/x-www-form-urlencoded
Connection: Keep-Alive
Accept-Encoding: gzip, deflate
Accept-Language: en-US,*
User-Agent: Mozilla/5.0
Host: snowapi.cleargrass.com

Но почему же тогда на sudo nc -l 1883 ничего не приходит, хотя запросы идут

aivs ★★
() автор топика
Ответ на: комментарий от aivs

Этот запрос отловился с nc -l 80:

192.168.115.19.60206 > 140.143.220.31.80: Flags [P.], cksum 0xb979 (correct), seq 1:673, ack 1, win 457, options [nop,nop,TS val 17697126 ecr 4188962922], length 672: HTTP, length: 672

А этот запрос с nc -l 1883 не ловится:

192.168.115.19.34098 > 154.8.191.174.1883: Flags [P.], cksum 0xab01 (correct), seq 4316:4851, ack 37, win 490, options [nop,nop,TS val 17701600 ecr 4143630469], length 535

Может для iptables не все порты редиректит? Типа больше 1000 уже не работает?

aivs ★★
() автор топика
Ответ на: комментарий от sanwashere

Делаю публикацию

mosquitto_pub -h localhost -p 1883 -t topic/1 -m hi

Слушаю 1883

pi@raspberrypi:~ $ nc -l 1883
#MQTT<mosqpub|13300-raspberry

т.е. реагирует.

Послушал eth0 интерфейс, который является выходом в интернет и запросы к 154.8.191.174.1883 идут в интернет:

sudo tcpdump -i eth0 -vv -s0 -X -n host 154.8.191.174
192.168.1.108.34098 > 154.8.191.174.1883: Flags [P.], cksum 0xdfb9 (correct), seq 3:539, ack 4, win 490, options [nop,nop,TS val 21529600 ecr 4181913152], length 536
	0x0000:  4500 024c 72e6 4000 3f06 aafa c0a8 016c  E..Lr.@.?......l
	0x0010:  9a08 bfae 8532 075b 82cc e271 6759 b13b  .....2.[...qgY.;
	0x0020:  8018 01ea dfb9 0000 0101 080a 0148 8400  .............H..
	0x0030:  f942 ee40 3095 0400 2a73 6e6f 772f 6461  .B.@0...*snow/da
	0x0040:  7461 2f36 4639 4431 3632 3246 3735 3432  ta/6F9D1622F7542
	0x0050:  3738 3832 4439 3635 3036 4445 3236 3536  7882D96506DE2656
	0x0060:  3743 447b 2264 6174 6122 3a7b 2262 6174  7CD{"data":{"bat
	0x0070:  7465 7279 223a 3130 302c 2262 6174 7465  tery":100,"batte
	0x0080:  7279 5f73 7461 7465 223a 2263 6861 7267  ry_state":"charg
	0x0090:  696e 6722 2c22 636f 3222 3a31 3030 322c  ing","co2":1002,
...
    154.8.191.174.1883 > 192.168.1.108.34098: Flags [.], cksum 0xc508 (correct), seq 4, ack 539, win 713, options [nop,nop,TS val 4181919771 ecr 21529600], length 0
	0x0000:  4500 0034 f66f 4000 3206 3689 9a08 bfae  E..4.o@.2.6.....
	0x0010:  c0a8 016c 075b 8532 6759 b13b 82cc e489  ...l.[.2gY.;....
	0x0020:  8010 02c9 c508 0000 0101 080a f943 081b  .............C..
	0x0030:  0148 8400                                .H..
12:35:00.841353 IP (tos 0x0, ttl 63, id 29415, offset 0, flags [DF], proto TCP (6), length 54)

А вот запросы на 80 порт в интернет не идут, заворачивают на localhost, как и ожидалось:

pi@raspberrypi:~ $ sudo tcpdump -i eth0 -vv -s0 -X -n port 80
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes


aivs ★★
() автор топика
Последнее исправление: aivs (всего исправлений: 1)
Ответ на: комментарий от aivs

Добился, чтобы все запросы для китайского mqtt сервера заворачивали на локальный mqtt сервер:

sudo iptables -t nat -I PREROUTING --src 0/0 --dst 154.8.191.174

Теперь вижу в mosquitto

pi@raspberrypi:~ $ sudo mosquitto
1581846851: mosquitto version 1.5.7 starting
1581846851: Using default config.
1581846851: Opening ipv4 listen socket on port 1883.
1581846851: Opening ipv6 listen socket on port 1883.
1581846867: New connection from 192.168.115.19 on port 1883.
1581846867: New client connected from 192.168.115.19 as mqtt-4wqy9rsou@6F9D1622F75427882D96506DE26567CD (c1, k30, u'AKIDhDVaT9FrtiKirluq1xe6JH0VnyveOPQB').

Но основная задача все-же полностью ограничить датчику доступ в интернет и отвечать на все запросы с локального сервера.

aivs ★★
() автор топика
Ответ на: комментарий от aivs

У вас у правил ″-t nat″ нулевые счётчики. Это значит, что они ни разу не сработали. Правило срабатывает один раз на первый пакет соединения (у которого state NEW), при сработке правила создаётся запись в таблице conntrack, остальные пакеты (в ту и в обратную сторону) изменяются по этой записи, а не по правилу в iptables.

Можно с помощью команды conntrack удалить запись из этой таблицы, тогда правило сработает. Правда это будет не первый пакет tcp-соединения. Или можно сгенерить RST-пакет, чтобы разорвать соединение, которое установил датчик. Или перезагрузить его.

mky ★★★★★
()
Ответ на: комментарий от mky

Спасибо большое! Я никак не мог понять почему правило сразу не работает, а через некоторое время начинало работать.
Перезагрузил датчик и сразу все данные пошли на localhost.
Сейчас использую только одно правило:

iptables -i wlan0 -t nat -A PREROUTING -s 192.168.115.19 -j REDIRECT

Верно ли я его понимаю: «Все пакеты на интерфейсе wlan0 от 192.168.115.19 редиректить на localhost»?
Нужен ли -j REDIRECT вообще? Следует ли использовать еще правила?

aivs ★★
() автор топика
Последнее исправление: aivs (всего исправлений: 2)
Ответ на: комментарий от aivs

Верно ли я его понимаю: «Все пакеты на интерфейсе wlan0 от 192.168.115.19 редиректить на localhost»?

Нет, не верно вы понимаете. Редирект на первый ip интерфейса на который прилетел пакет.

anc ★★★★★
()
Ответ на: комментарий от aivs

Нужен ли -j REDIRECT вообще? Следует ли использовать еще правила?

REDIRECT или DNAT решать вам, особой разницы нет. Если у вас там заработало как вы хотели, то других правил в iptables и не нужно.

mky ★★★★★
()
Ответ на: комментарий от anc

В моем случае интерфейс wlan0, первый ip на нем 192.167.115.1, это локальный ip. Видимо поэтому у меня все работает. Есть ли команда, чтобы начать отлавливать пакеты по этому правилу с уже существующим подключением, без перезагрузки датчика?

aivs ★★
() автор топика
Ответ на: комментарий от aivs

Есть ли команда, чтобы начать отлавливать пакеты по этому правилу с уже существующим подключением, без перезагрузки датчика?

Ничего не понял. Поясните чего достигнуть хотите.

anc ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.