Доступ к разным IP-адресам подсети на двух разных интерфейсах

Доступ к разным IP-адресам подсети на двух разных интерфейсах

Я пытаюсь настроить Raspberry Pi так, чтобы он предоставил мне доступ к устройствам, подключенным либо к eth0, либо к wlan1.

Желаемая функция такова:

  • Пользователь подключается к точке доступа RPi через wlan1 и получает IP-адрес (192.168.4.x)
  • Отдельное устройство подключается к RPi через eth0 и получает IP (192.168.5.x)
  • Пользователь может получить доступ к интерфейсу конфигурации подключенного устройства eth0 через его локальный IP-адрес.

Я использовал dnsmasq для настройки DHCP-серверов на каждом интерфейсе, и они вполне успешно предоставляют IP-адреса;

# dnsmasq.conf
interface=wlan1
dhcp-range=wlan1,192.168.4.2,192.168.4.99,24h

interface=eth0
dhcp-range=eth0,192.168.5.1,192.168.5.99,24h

listen-address=::1,127.0.0.1,192.168.5.1,192.168.4.1

Я также обновил iptables для пересылки трафика между интерфейсами;

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wlan1 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o wlan1 -j ACCEPT

Однако я все еще немного запутался, когда дело доходит до фактического доступа к различным IP-адресам. Я думаю, что мне нужно настроить некоторые маршруты, но я пытаюсь понять, как именно это реализовать.

Пингование IP-адресов 192.168.4.x и 192.168.5.x через соединение wlan0: введите описание изображения здесь

И из ...4.x и ...5.x из соединения eth0: введите описание изображения здесь

Выводы iptables и netstat:

pi@rak-gateway:~ $ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
pi@rak-gateway:~ $ netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan0
192.168.4.0     0.0.0.0         255.255.255.0   U         0 0          0 wlan1
192.168.5.0     0.0.0.0         255.255.255.0   U         0 0          0 eth0

решение1

Однако я все еще немного запутался, когда дело доходит до фактического доступа к различным IP-адресам. Я думаю, что мне нужно настроить некоторые маршруты, но я пытаюсь понять, как именно это реализовать.

Что нужно помнить о маршрутизации:каждый компьютер на маршрутенеобходимо знать, куда отправить конкретный пакет.

Итак, если A подключается к RaspPi как 192.168.4.x, а B как 192.168.5.y, то

  • Необходимо знать, что пакеты на 192.168.5.*/24 поступают на адрес 192.168.4.? RaspPi.
  • B, когда он отвечает, должен знать, что пакеты на 192.168.4.*/24 идут на адрес 192.168.5.? RaspPi.

Вы получаете это бесплатно, если A и B подключены только к RaspPi и имеют IP-адрес RaspPi, установленный в качестве шлюза по умолчанию. Если это не так, например, потому что A и B также подключены к чему-то другому или потому что вы не настроили dnsmasqобъявление шлюза по умолчанию, то вам нужно установить маршрутына А или В.

Вы можете сделать это либо статически напрямую на A или B, либо использовать DHCP для распределения маршрутов (первая ссылка в Google для получения инструкции).здесь, поищите больше в Google).

В любом случае отладка должна включатьрассматривая маршрутына обоих устройствах A и B (в Linux можно использовать ip route get 1.2.3.4, где 1.2.3.4 — адрес назначения).

решение2

Спасибо за ваши новости.

Первое, что я бы посоветовал вам, это исправить ваш eth0диапазон DHCP, начав с . 192.168.5.2В настоящее время он, похоже, начинается с 192.168.5.1.

Следующее, что нужно опубликовать, — это таблица маршрутизации устройства, подключенного через eth0, и таблица маршрутизации устройства, подключенного через wlan1.

Прежде чем получить таблицы маршрутизации, убедитесь, что оба устройства успешно выполнили DHCP и имеют адреса в ожидаемых подсетях.

Связанный контент