У меня есть распределенная установка для работы с: 3 внешними зданиями с маршрутизаторами на основе прошивки Tomato, подключающимися к другому маршрутизатору на основе томатов в качестве настройки VPN. Маршрутизатор сервера также находится в нашей частной локальной сети (как периферийное устройство).
В нашей основной локальной сети у нас есть сервер DHCP, работающий на сервере Linux, предлагающий 192.168.0.0/19 (да, маска подсети 255.255.224.0!), Исключая октет 192.168.2.x/24. На каждом сайте каждый Tomato VPN Client (с этого момента маршрутизаторы) должен предлагать IP-адреса в определенном диапазоне своим клиентам в подсети 192.168.2.x. SiteA - 192.168.2.2-29 (маршрутизатор .1), SiteB - 192.168.2.31-50 (маршрутизатор .30), а SiteC - 192.168.2.52-80 (.51 - маршрутизатор). Компьютеры могут подключаться к нашему серверу без проблем.
Однако происходит то, что внезапно (когда раньше это работало совершенно нормально) у меня есть маршрутизатор от SiteA, предлагающий аренду клиентам на других сайтах. Поскольку они находятся в одной конечной сети (192.168.0.0/19), они могут получать доступ к серверам в нашей локальной сети, но не к Интернету.
В качестве временного исправления я мог удаленно подключиться к компьютерам в SiteB и SiteC и назначить шлюз по умолчанию для маршрутизаторов в каждом месте. Это не очень хорошее решение, так как оно не позволяет другим сотрудникам посещать сайт со своими ноутбуками или планшетами и иметь возможность подключиться сразу.
Маршрутизаторы не скомпилированы с поддержкой ebtables
как рекомендуется в нескольких других потоках. Конечная цель состоит в том, чтобы серверы DHCP предлагали аренду только на стороне локальной сети своих собственных маршрутизаторов.
Конфигурация VPN-клиента маршрутизатора B
Конфигурация VPN-клиента маршрутизатора A (перенаправленный интернет-трафик изначально был отключен; он был включен выше только для тестирования)