NAS недоступен через VPN: адрес, обратный путь или служба?

Туннели поднимаются, клиенты получают адрес, а NAS не отвечает совсем. Этот единственный симптом скрывает три несвязанных отказа, и порядок их проверки определяет, сколько займёт ремонт. Адресация идёт первой, потому что перекрывающаяся подсеть может отправить запрос на чужое устройство. Обратный путь идёт вторым, потому что запрос, приходящий без ответа, выглядит точно так же, как закрытая служба. Служба и разрешения идут последними, и только после того, как доказаны первые два пункта.

Три отказа, которые все читаются как «недоступно»

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

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

Условие первое: этот адрес — то самое устройство?

Запишите подсеть NAS и диапазон, который VPN выдаёт клиентам, и сравните оба с сетью, в которой сейчас находится ноутбук. В этом разборе NAS стоит на 10.40.7.25, а пул VPN — 10.40.9.0/24, два отдельных частных диапазона в рамках одного плана площадки; у домашней сети, где используется 192.168.0.0/24 или 10.0.0.0/24, гораздо больше шансов столкнуться с одним из них.

Когда локальная сеть и сеть NAS перекрываются, клиент отправляет такой трафик на свой собственный шлюз и может попасть на постороннее устройство, у которого случайно тот же адрес. Проверьте путь, прежде чем вводить учётные данные в то, что отвечает.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

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

Условие второе: ответ возвращается?

Клиенту нужен маршрут к NAS, а сети NAS нужен обратный путь к пулу VPN. Пересылка на шлюзе, правила брандмауэра и намеренная трансляция адресов каждая по-своему влияют на эту пару. Заметки strongSwan о пересылке описывают варианты обратного маршрута и трансляции для частной подсети за шлюзом.

Когда запрос приходит, а ответ уходит через другой шлюз, никакое изменение DNS не исправит асимметрию. Запись трафика с обеих сторон решает вопрос за одну попытку и показывает, переписала ли трансляция источник, на который ответил NAS. Администратор отвечает за эту границу: разрешите только нужные службы и диапазон клиентов VPN и запишите, что выбрано — маршрутизация или трансляция.

Условие третье: служба есть и она разрешена?

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

Проверяйте той учётной записью, которой действительно нужны файлы, а не администраторской из установки, потому что права администратора не могут исправить отсутствующий маршрут, а маршрут не может выдать разрешение на общий ресурс. Имена тоже относятся сюда: имя NAS, найденное дома, часто зависит от локального multicast, который маршрутизируемый туннель не переносит, поэтому попробуйте задокументированное производителем частное имя узла или сам адрес, чтобы отделить именование от доступа.

Проверяйте снаружи сети NAS, затем расширяйте постепенно

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

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

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

Не публикуйте порты обмена файлами или администрирования в интернете, чтобы обойти необъяснимый сбой. Исправьте частный путь, держите программное обеспечение NAS поддерживаемым и проверяйте восстановление всего, что копируете через него, прежде чем полагаться на эту резервную копию.