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 с поддръжка и тествайте възстановяването на всичко, което копирате през него, преди да разчитате на това резервно копие.