Подключение к OpenVPN есть, а ping и SMB-ресурса нет? Проверьте три шлюза

Туннель поднимается, клиент получает адрес, а в удалённой LAN никто не отвечает. Ping не проходит, общий ресурс не открывается, а журнал VPN выглядит чистым, потому что с его точки зрения сеанс здоров. Между этим сеансом и файлом на сервере стоят три независимых шлюза: политика перенаправления, порты, нужные службе, и имя, которое вы ввели вместо адреса.

Каждый шлюз отказывает по-своему, и только первый находится на сервере VPN.

Перенаправление — это политика в цепочке FORWARD

Приём прослушивателя OpenVPN происходит на INPUT, поэтому туннель может подключиться, хотя каждый пакет в сторону LAN отбрасывается. Трафик, приходящий на tun0 и уходящий через интерфейс LAN, проходит FORWARD, а хост с политикой DROP по умолчанию там молча его отбрасывает. Прежде чем трогать что-либо ещё, проверьте и sysctl, и цепочку: sysctl net.ipv4.ip_forward и iptables -L FORWARD -v -n.

Разрешите нужное направление и относящиеся к нему ответы, например правило accept из интерфейса туннеля в интерфейс LAN плюс правило stateful для трафика established и related. Если LAN находится за другим маршрутизатором, этому маршрутизатору нужен обратный маршрут к пулу клиентов или source NAT на сервере VPN. Подтвердите этот путь одним ping до добавления новых правил, потому что правило, до которого нельзя добраться, никогда не появляется в счётчике.

SMB нужен не один порт

Общий доступ к файлам — это не один разговор TCP 445. Обнаружение использует UDP 137 и 138, старые сеансы NetBIOS используют TCP 139, а современные сеансы SMB используют TCP 445. Правило, открывающее только 445, создаёт раздражающий случай, когда подключённый диск работает, а просмотр сети нет, или наоборот.

Большие передачи через туннель тоже упираются в проблемы MSS, которые выглядят как сломанный общий ресурс. SYN, объявляющий полный размер сегмента LAN, отбрасывается из-за меньшего MTU туннеля, и соединение зависает после рукопожатия. Ограничение MSS на пути перенаправления, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, устраняет такой вид зависания. Проверяйте копией в несколько мегабайт, а не списком каталога, потому что малые ответы проходят даже тогда, когда большие передачи нет.

Адаптер туннеля появляется как новый сетевой профиль

Windows относит каждый адаптер к сетевому профилю, и новый адаптер туннеля обычно попадает в Public, где правила общего доступа к файлам и принтерам заблокированы. Это решение брандмауэра хоста на файловом сервере, а не проблема маршрутизации на сервере VPN. Сознательно смените категорию с помощью Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private после того, как убедитесь, что политика это разрешает, потому что категория меняет и то, какие входящие правила действуют.

Тот же профиль объясняет ping, который не проходит, хотя TCP 445 работает: эхо-запросы в Public по умолчанию отбрасываются.

Имена сами по себе не пересекают маршрутизируемый туннель

Разрешение имён NetBIOS и локальное обнаружение опираются на широковещательные рассылки, которые маршрутизируемый туннель не переносит. Поэтому ввод короткого имени сервера не срабатывает, хотя его адрес работает, и общий ресурс кажется сломанным, когда сломан только поиск. Добавьте DNS-запись для сервера в том резолвере, который выдаёт туннель, или используйте адрес в ярлыке.

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

Проверяйте по одному уровню и читайте первый сбой

Двигайтесь снизу вверх: пропингуйте шлюз туннеля, пропингуйте хост в LAN по адресу, затем откройте порт службы с помощью Test-NetConnection -ComputerName 10.8.0.5 -Port 445, и только потом проходите проверку подлинности на ресурсе. Первый неудачный шаг — это слой, который нужно чинить, а каждый следующий шаг шум, пока тот не пройдёт. Ping, который отвечает, хотя порт остаётся закрытым, указывает на собственный брандмауэр файлового сервера, а порт, который открывается несмотря на молчащие ping, указывает на фильтрацию ICMP. Запишите первый неудачный шаг, прежде чем что-то менять, потому что второе изменение скрывает результат первого.

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

Держите учётную запись для общего ресурса отдельно от входа в VPN в своих заметках, потому что успешный туннель ничего не говорит о правах на файлы. Выставлять SMB в интернет, чтобы обойти отсутствующее правило, — не решение.