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 підтримуваним і перевіряйте відновлення всього, що копіюєте через нього, перш ніж покладатися на цю резервну копію.