Спільний доступ із Mac видно через VPN: вимкнути чи сховати?

Списки огляду будуються з оголошень, а оголошення — не надання доступу. Хтось бачить ім'я вашого ноутбука в далекому списку тому, що multicast-запит перетнув межу, на якій він зазвичай зупиняється на маршрутизаторі. Цей перетин пояснює і те, чому запис з'являється, і те, чому видалення запису не те саме, що закриття служби. Перш ніж щось змінювати, вирішіть, проти чого з цих двох ви насправді заперечуєте.

Що насправді являє собою запис огляду

Відповідач mDNS на Mac відповідає на запити про типи служб, які він розміщує, і відповідь несе ім'я, порт і кілька текстових записів. Клієнт, що запитав, потім показує це ім'я в списку. Ніщо в обміні не доводить, що з'єднання вдасться, і ніщо в ньому не дає дозволу: список — це твердження про ім'я, а не про доступ. Саме ця відмінність визначає, чи варто щось вимкнути або припинити це публікувати.

Різні служби реєструються окремо, тому зникнення одного запису не означає, що всі оголошення припинилися. Спільний доступ до файлів реєструє один тип, до екрана — інший, а принтери, медіатеки й інструменти розробника реєструють кожен свій. Перш ніж вважати один перемикач головним керуванням, перелічіть, що зареєстровано і який процес цим володіє:

dns-sd -B _smb._tcp
lsof -nP -iUDP:5353

Multicast залишається локальним, якщо щось не з'єднає його мостом

Multicast DNS надсилає до локальної для каналу групи на UDP 5353, і маршрутизатори за замовчуванням не пересилають цю групу. Тому тунель, який маршрутизує одноадресний трафік, залишає виявлення позаду, і саме тому Mac у маршрутизованому VPN зазвичай невидимий для віддаленого сайту. Містовий тунель або навмисно налаштований ретранслятор змінює це, поміщаючи обидва кінці в один домен широкомовлення. Яка у вас конструкція — властивість тунелю, а не назви протоколу, надрукованої на ньому.

Перегляньте конфігурацію сервера, щоб побачити, чи він з'єднує інтерфейс мостом, чи маршрутизує підмережу, бо обидва поводяться по-різному для кожного протоколу, залежного від широкомовлення. Якщо тунель з'єднаний мостом, очікуйте витоку більше ніж одного виду оголошень, зокрема того, що ніхто не збирався публікувати. Якщо він маршрутизований, запис у віддаленому списку, ймовірно, прийшов через ретранслятор або через виявлення на основі одноадресного DNS, а не через групу multicast. Ці шляхи мають різні виправлення, і блокування порту multicast закриває лише один із них.

Зупинка служби — найчистіша межа

Якщо Mac не має справи з обслуговуванням файлів, вимкніть спільний доступ підтримуваним елементом керування, замість того щоб намагатися приховати його оголошення. До зупиненої служби не можна підключитися, її не можна вгадати, і до неї не дістанеться старий клієнт, який пам'ятав ім'я. Ця властивість робить її сильнішим керуванням, і вона зовсім не потребує співпраці мережі.

Посібник зі спільного доступу до файлів від Apple описує модель дозволів для спільних тек, дозволених користувачів і гостьового доступу, а панель спільного доступу показує поточний стан. Перегляньте ці три, коли служба справді потрібна, бо спільний доступ, який має існувати, — це доступ, який треба обмежити. Гостьовий доступ заслуговує окремого погляду, оскільки він може дозволити з'єднання без жодних облікових даних. Потім підтвердьте, на яких інтерфейсах служба слухає, бо доступ, запропонований на кожному інтерфейсі, пропонується і в тунелі.

Коли потрібна служба, а не аудиторія

Іноді спільний доступ законний, а аудиторія — ні. Обмеження служби схваленими джерелами, з виявленням як окремим і меншим керуванням, — чесний порядок. Правила брандмауера, дозволи для кожного користувача й прослуховування правильного інтерфейсу звужують доступ так, як приховане оголошення не може.

Придушення виявлення є косметичним у строгому сенсі: служба все ще відповідає кожному, хто знає ім'я. Якщо проблема в самій публікації, обмежте її на рівні, який її несе. У мережі, якою ви керуєте, це означає вирішити, які типи служб мають перетинати межу, і налаштувати міст, ретранслятор або фільтр відповідно. Копіювання команди фільтра моста з форуму працює лише якщо ваш сервер запускає саме цей стек і цей режим тунелю, а в мережі, якою ви не керуєте, чесна відповідь — ви не можете контролювати, що пам'ятає віддалений клієнт.

Погляньте з віддаленого боку

Перевіряйте з віддаленого боку, а не з власної мережі Mac, і перевіряйте свіжий огляд, а не кешований список. Потім спробуйте пряме підключення до служби за іменем і за адресою, бо два результати відповідають на різні питання. Відсутній запис при успішному підключенні означає, що ви сховали мітку, а невдале підключення означає, що ви закрили службу. Кеш змушує обидва тести брехати, якщо пропустити оновлення, тому запустіть клієнт заново.

Запишіть, що ви змінили і до якого з трьох керувань це належить: службу зупинено, доступ обмежено або виявлення обмежено. Коли хтось повідомляє, що Mac досі видно, цей запис підкаже, чи звіт застарілий, чи інше оголошення заявляє про себе. Більшість несподіванок тут — друга реєстрація, яку ніхто не пам'ятав, що вмикав, а не зламане керування.

Перепроверте решту реєстрацій, перш ніж зробити висновок, що зміна не вдалася. Короткий список кращий за ще один раунд здогадок.