Нет доступа к LAN через OpenVPN? Проверьте зоны, маршруты и обратный путь

Маршрутизатор отвечает, потому что он локальный. Чтобы добраться до машины за ним, нужны правило перенаправления, префикс на клиенте и обратный путь для ответа.

Туннель сообщает об успешном подключении, страница самого маршрутизатора открывается, а подключение диска к машине за ним по-прежнему завершается тайм-аутом. В этом сочетании нет противоречия: маршрутизатор отвечает как он сам, а доступ к чему-то за ним — другое решение, принятое в другом месте. Выполняйте проверки ниже по порядку и остановитесь на первой неудаче, потому что каждая опирается на предыдущую. Когда все четыре проходят, неисправность находится над туннелем, а не в нём.

Какой фильтр видит пакет, направленный в LAN

Пакет, адресованный маршрутизатору, потребляется локально; пакет, адресованный хосту за ним, должен быть перенаправлен, и межсетевые экраны судят эти два случая отдельно. Поэтому разрешение добраться до маршрутизатора ничего не говорит о разрешении пройти сквозь него. Прошивка, скрывающая свои наборы правил, всё равно реализует оба, обычно в виде селектора, предлагающего LAN, интернет или оба варианта. Если селектор исключает LAN, никакая последующая проверка уже не поможет.

OpenWrt делает это разделение проверяемым, и различие стоит одного прочтения. Зоне, которая завершает туннель, нужно правило перенаправления в зону LAN, тогда как правило входа управляет только службами на самом маршрутизаторе. Работающая страница администрирования рядом с мёртвым LAN — обычный результат отсутствующего правила перенаправления.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Посмотрите на цель перенаправления зоны, которая несет туннель: accept — это то, что нужно лестнице, а reject объясняет каждый тайм-аут ниже. Две соседние настройки дают тот же симптом, поэтому исключите их, пока вы здесь. Беспроводная изоляция скрывает проводные хосты от беспроводных клиентов, а маршрутизатор, считающий простаивающие хосты LAN офлайн, может отбрасывать ответы даже после того, как перенаправление заработало.

Почему разделённому туннелю нужен проталкиваемый префикс

Клиент, отправляющий весь трафик через туннель, уже имеет префикс LAN через свой маршрут по умолчанию, поэтому добавлять нечего. Разделённый туннель — это случай, требующий явного указания префикса, потому что больше ничего в конфигурации о нём не упоминает. Добавьте директиву в конфигурацию сервера и перезагрузите службу.

push "route 192.168.50.0 255.255.255.0"

Профили, содержащие route-nopull игнорируют протолкнутые маршруты, поэтому тот же префикс должен быть в файле клиента. В любом случае подтвердите, что запись пришла, а не предполагайте это, потому что тихое переопределение выглядит точно так же, как проблема межсетевого экрана.

ip route show | grep 192.168.50

Партнёр «сеть-сеть» требует большего, чем проталкивание. Сервер должен узнать, какие префиксы находятся за этим партнёром, что делает строка iroute в его файле client-config-dir, и его собственная таблица нуждается в соответствующем маршруте в туннель.

Ответу нужен адрес, до которого он может добраться

Перенаправление запроса — лишь половина обмена, потому что хост LAN должен ответить на адрес из пула туннеля. Небольшие маршрутизаторы обычно решают это трансляцией источника в зоне туннеля, поэтому ответ адресуется маршрутизатору и не требует настройки в другом месте. Уберите эту трансляцию, и хосту понадобится собственный маршрут в пул, который он получает бесплатно, когда маршрутизатор является его шлюзом по умолчанию. Хост с адресом, заданным вручную, и другим шлюзом отвечает через этот шлюз, и клиент видит, как сеанс открывается и затем застревает.

tcpdump -ni tun0 host 192.168.50.20

Запустите это на маршрутизаторе, пока клиент повторяет запрос, и читайте назначение ответа, а не сам запрос. Ответ, адресованный пулу, означает, что обратный путь работает и неисправность глубже. Полное отсутствие ответа означает, что хост никогда не принял пакет, что возвращает вас к набору правил.

Лестница, которая заканчивается в нужном месте

Четыре проверки определяют уровень, и каждая — одна команда, а не суждение. Выполняйте их по порядку и останавливайтесь на первой неудаче. Порядок важнее команд, потому что успешный поздний шаг скрывает причину неудачи раннего.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Имена принадлежат концу лестницы и никогда началу. Общий ресурс, отвечающий как 192.168.50.20, но не как nas.local, указывает на разрешение имён или суффикс поиска, и правки межсетевого экрана не могут изменить ни то, ни другое.

Запишите первый неудачный шаг, затем дайте портам служб собственный проход, потому что слушатель и разрешение хоста — отдельные требования. Общий доступ к файлам, удалённый рабочий стол и потоки с камер требуют обоих, а межсетевой экран хоста, доверяющий подсети LAN, но не пулу туннеля, отбрасывает клиента, тогда как ping ещё проходит. Когда все проверки пройдены, а приложение всё равно не работает, неисправность над туннелем: служба, привязанная к одному интерфейсу, или прокси, настроенный на клиенте.

Похожие статьи