Тунэлі ўздымаюцца, кліенты атрымліваюць адрас, а NAS не адказвае зусім. Гэты адзіны сімптом хавае тры не звязаныя адмовы, і парадак іх праверкі вызначае, колькі зойме рамонт. Адрасацыя ідзе першай, бо падсетка, што перакрываецца, можа адправіць запыт на чужую прыладу. Зваротны шлях ідзе другім, бо запыт, які прыходзіць без адказу, выглядае гэтак жа, як закрытая служба. Служба і дазволы ідуць апошнімі, і толькі пасля таго, як даказаны першыя два пункты.

Тры адмовы, якія ўсе чытаюцца як «недаступна»

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

ObservationMost likely conclusion
Route to the NAS address leaves the wrong interfaceOverlapping or missing private route
Request visible on the server, no reply seenReturn path, gateway forwarding or translation
TCP connection refused rather than droppedReachable host, service not listening or filtered
TCP works, login or file access failsShare permission, account or protocol version

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

Умова першая: гэты адрас — тая самая прылада?

Запішыце падсетку 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 падтрымліваным і правярайце аднаўленне ўсяго, што капіруеце праз яго, перш чым спадзявацца на гэтую рэзервовую копію.

Падобныя артыкулы