Роўтар як кліент SMB супраць перадавальніка пакетаў: што лепш падыходзіць

Перадача трафіку SMB — не тая самая задача, што яго завяршэнне, і роўтар, які робіць адно, можа не спраўляцца з другім. Перадача азначае, што роўтар перамяшчае пакеты, змест якіх ён ніколі не аналізуе. Мантаванне азначае, што роўтар робіцца файлавым кліентам, з праграмным забеспячэннем, якога ў ім можа не быць, з уліковымі данымі, якія ён павінен абараняць, і з рэжымамі збояў, якія ён цяпер бярэ на сябе. Выбар паміж двума — гэта пытанне пра тое, дзе патрэбныя файлы, а не пра тое, што можна ўгаварыць усталяваць платформу маршрутызацыі.

Перадача і завяршэнне — розныя задачы

У ролі перадачы ў роўтара адна адказнасць: дастаўляць пакеты паміж кліентам і серверам, прымяняючы тую палітыку, якую патрабуе шлях. Ён не аўтэнтыфікуецца на агульным рэсурсе, не кэшуе даныя файлаў і не цікавіцца, ці гаворыць сервер SMB2 або SMB3, бо ніколі не чытае паток так далёка. Калі рэсурс робіцца недасяжным, карыстальнік бачыць памылку, а роўтар працягвае маршрутызаваць.

У ролі кліента роўтар далучаецца да размовы пратаколу. Ён узгадняе дыялект, аўтэнтыфікуецца, развязвае імёны, трымае пункт мантавання і паказвае лакальны выгляд файлавай сістэмы ўсяму, што працуе над ім. Гэта сапраўдная паслуга з жыццёвым цыклам, і яна робіць шлюз залежнасцю працоўнага працэсу з файламі. Ён таксама наследуе ўсе рэжымы збояў гэтай залежнасці, уключаючы чаканне пры загрузцы і састарэлыя ўліковыя даныя.

Параўнанне не толькі пра магчымасці. Платформа, якая можа мантаваць рэсурс, не абавязкова тая, якой гэта варта рабіць, а платформа, якая не можа яго мантаваць, можа ўсё ж быць правільным месцам для маршрутызацыі трафіку.

Што насамрэч патрэбна для мантавання CIFS у ядры

На прыладзе з Linux кліент CIFS у ядры і кліент у прасторы карыстальніка — асобныя магчымасці, і невялікія вобразы часта не ўтрымліваюць ні адной. Падтрымка ядра павінна быць у працуючым вобразе, памочнік мантавання павінен існаваць, а дыялект SMB, узгоднены з серверам, павінен быць такім, які прымаюць абодва бакі. Падрабязнасці ёсць у кіраўніцтве па кліенце CIFS для Linux пра ўладкаванне ядра і яго параметры мантавання; гэта правільная даведка, перш чым меркаваць, што зборка пастаўшчыка яго ўтрымлівае.

Праверце наяўнасць магчымасці, перш чым праектаваць вакол яе, і праверце версію, а не наяўнасць імені каманды. Імя модуля ў спісе пакетаў — не тое самае, што працуючы кліент.

lsmod | grep -w cifs
modinfo cifs | head -5
mount.cifs --version
smbclient -L //fs02.corp.internal -U svc-router -m SMB3

Модуль ядра, які загружаецца, і інструмент у прасторы карыстальніка, які паведамляе версію, усё яшчэ не гарантуюць, што мантаванне перажыве змену ключоў VPN, таму стаўцеся да праверкі як да пачатковай умовы, а не як да доказу. Калі вобраз падтрымлівае толькі SMB1, гэта прычына спыніцца, а не прычына ўключыць яго на серверы.

Уліковыя даныя і ідэнтычнасць крыніцы адрозніваюцца ад наўтбука

Перададзены запыт нясе ідэнтычнасць наўтбука праз тунель, а запыт, створаны на роўтары, нясе ўласны адрас крыніцы роўтара, шлях рэзалвера і фільтраванне выхаду. Яны могуць трапіць у іншае правіла міжсеткавага экрана, іншы выгляд DNS і іншы спіс дазволаў на баку сервера. Таму копія, якая працуе з працоўнай станцыі, нічога не даказвае пра ўласнае мантаванне роўтара. Тэстуйце мантаванне з уласнай абалонкі роўтара, а не з працоўнай станцыі за ім.

Дайце роўтару вузка ўпаўнаважаную ідэнтычнасць паслугі, калі роля наогул ухвалена. Ніколі не змяшчайце пароль непасрэдна ў радок каманды мантавання, бо ён застаецца ў гісторыі абалонкі і паказваецца ў табліцы працэсаў, пакуль мантаванне выконваецца.

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

install -m 600 /dev/null /etc/cifs-reports.creds
printf 'username=svc-router\npassword=REPLACE_ME\ndomain=CORP\n' > /etc/cifs-reports.creds
mount -t cifs //fs02.corp.internal/reports /mnt/reports -o credentials=/etc/cifs-reports.creds,vers=3.1.1,ro

Хто адказвае за збой, калі рэсурс знікае

Адсутная аддаленая файлавая сістэма паводзіць сябе інакш, чым адсутны маршрут. Мантаванне можа блакаваць працэсы, якія да яго звяртаюцца, можа збаіць пры загрузцы да з’яўлення тунеля, а запіс, прызначаны серверу, можа трапіць не туды, калі пад пунктам мантавання ёсць лакальны каталог. Гэта збоі захоўвання, якія цяпер належаць сеткавай камандзе, хацела яна гэтага ці не. Ніхто не дамаўляўся пра такую адказнасць, але яна прыходзіць разам з мантаваннем.

Праектуйце парадак загрузкі і параметры мантавання вакол гэтай рэальнасці. Мантаванне толькі для чытання з кароткім тайм-аўтам і дакументаваным крокам аднаўлення абараніць прасцей, чым запісвальнае мантаванне, ад якога залежыць усё астатняе. Пацвердзіце, што тунель узнімаецца да таго, як нешта паспрабуе мантаваць, інакш першая загрузка пасля адключэння электрычнасці завісне.

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

Праверце рашэнне супраць фактычнай задачы

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

Праверце змантаваны выгляд і свабоднае месца з самога роўтара, бо менавіта там іх убачыць працоўная нагрузка. Паўтарыце праверку пасля перападключэння, а не толькі пасля чыстай загрузкі.

findmnt -t cifs -o TARGET,SOURCE,OPTIONS
df -h /mnt/reports
ls -l /mnt/reports | head

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