Підключення до 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 в інтернет, щоб обійти відсутнє правило, — не рішення.