Робочий ноутбук у особистому VPN: що насправді проходить

Підключення корпоративного ноутбука до домашнього VPN ставить його у два місця одночасно, і цікаве питання тут менше й корисніше за тривожне. Ніхто не протягнув кабель Ethernet між офісом і домом, і жоден маршрут не робить домашню мережу продовженням корпоративної підмережі. Існує одна кінцева точка з доступом до обох середовищ, і три окремі механізми вирішують, що справді може переміщатися між ними. Прохід цими трьома від кінцевої точки назовні дає відповідь, на яку адміністратор може діяти, замість суперечки про ярлики.

Починайте з кінцевої точки, а не зі схеми мережі

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

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

Три точки перетину, розглянуті окремо

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

Ідентичність і дані утворюють другу точку перетину. Корпоративні облікові дані, сесійні cookie, завантажені документи й права керування живуть на кінцевій точці, і приєднання до іншої мережі саме по собі їх не розкриває. Змінюється набір сторін, які могли б впливати на кінцеву точку, поки вона зберігає ці облікові дані, а це питання про надійність особистої мережі, а не про маршрутизацію. Це судження, яке власник кінцевої точки не може ухвалити сам, і на нього не відповідає відсутність правила переспрямування.

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

Просіть один ресурс, а не дві мережі

Більшість реальних вимог вужчі, ніж здається на перший погляд: одна консоль, один файловий ресурс, один внутрішній вебзастосунок. Сформулюйте вимогу саме так і дозвольте власникові ресурсу вирішити, чи належить вона взагалі до цієї кінцевої точки. Запит, сформульований як об'єднання двох мереж, важко схвалити й легко відхилити; запит на одну названу службу має відповідь.

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

Врахуйте вплив DNS і маршрутів

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

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

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

Перевірте й залиште шлях до відступу

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

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

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