1

В моем случае у меня есть два маршрутизатора openwrt, соединенные с мостом openvpn.

Iptables может остановить трафик с помощью iptables-mod-extra:

iptables -I FORWARD -m physdev --physdev-out tap0 -p udp --dport 67:68 -j DROP
iptables -I FORWARD -m physdev --physdev-in tap0 -p udp --dport 67:68 -j DROP
iptables -I INPUT -m physdev --physdev-in tap0 -p udp --dport 67:68 -j DROP

Также трафик может быть остановлен ebtables:

ebtables -I FORWARD -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I FORWARD -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I INPUT -i tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP 
ebtables -I OUTPUT -o tap0 -p IPv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP

1 ответ1

2

Вы правильно настроили мост VPN и разделение DHCP.

Проблема (скорее всего) в вашей второй точке доступа / маршрутизаторе «10.0.0.5», которая внутренне запоминает (слишком долго?) что устройство было подключено к его интерфейсу Wi-Fi и что оно не обновляет эту информацию, когда пакеты с тем же MAC-адресом поступают из другого интерфейса, в вашем случае это интерфейс TAP VPN-туннеля.

Снова подключившись к «10.0.0.1», ваше устройство ("Macbook") отправляет ARP-запросы «У кого есть 10.0.0.5», которые проходят через VPN-туннель на «10.0.0.5», но на которые нет ответа или нет получить перенаправленный на правильный (теперь TAP) интерфейс.

Вам нужно проверить, как интерфейс VPN TAP соединен с точкой доступа / маршрутизатором, если настройка моста соответствует вашей конфигурации.

Я предлагаю вам повторить свои тесты и записать журналы tcpdump на рассматриваемых интерфейсах, а также на внутренний мост и / или с интерфейсом (-ами) Wi-Fi, чтобы увидеть, куда идут ответы ARP, а затем открыть новый вопрос с соответствующими тегами, касающимися этого, возможно, конкретного проблема с вашим AP / роутером.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .