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