VPN блокує доступ до локальної мережі: як правильно налаштувати розділення тунелів у Windows

February 8, 2026 • February 8, 2026 • Читання: 4 хв • Views: 1

Було корисно?

Усе працює, доки ви не підключаєте корпоративний VPN. Тоді ваш локальний NAS зникає, принтер стає «офлайн», а один розумний домашній вимикач ніби перестає існувати. VPN не лише додав безпечний шлях до роботи — він тихо перемапив всю вашу мережу.

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

Що саме ламається, коли доступ до LAN пропадає

Коли VPN «ламав доступ до локальної мережі», люди звинувачують шифрування, тунелі, файрволи або атмосферу. На практиці це зазвичай одне з наступного:

Змінився маршрут за замовчуванням (0.0.0.0/0 і/або ::/0) на адресу VPN-адаптера. Тепер «усе, що не вважається явним локальним», йде в тунель — включно з тим, що ви вважали локальним.
Зник маршрут до локальної підмережі, бо VPN пропихнув ширшу маршрутну анонсацію, яка перемагає. Приклад: ви вдома в 192.168.1.0/24, а VPN штовхає 192.168.0.0/16 — і раптом ваша домашня мережа «корпоративна».
Відбір маршруту правильний, але метрики ні. Windows обирає найдовший префікс; при паритеті — найменшу метрику. Якщо у VPN-адаптера агресивно мала метрика, він «виграє» занадто часто.
Зміни DNS. Ваші DNS-сервери перемикаються на корпоративні резолвери, які не можуть розвʼязувати локальні імена (або навмисно відмовляють), тож «nas» і «printer» перестають резольвитися, хоча IP-зʼєднання в порядку.
Політика блокує локальний LAN. Деякі VPN-клієнти навмисно додають фільтри (правила WFP), щоб заборонити локальний доступ під час підключення. Це не розділення тунелів; це «без локального розгалуження».
Включився IPv6. Windows віддає перевагу IPv6, коли є. VPN, який підтримує лише IPv4, разом з LAN, що рекламує IPv6, може призвести до дивної поведінки, якщо не перевіряти наявні маршрути.

Виправлення рідко зводиться до «увімкнути split tunneling» як чарівної галочки. Суть: визначте, що має йти через тунель, що має залишатися локально, і зафіксуйте це явними маршрутами та поведінкою DNS, яку ви зможете пояснити наступному на виклику.

Дев’ять фактів і історичних нюансів, які стануть у пригоді (на вечірках або викликах інцидентів)

Розділення тунелів колись було контраверсійним, перш ніж стало модним. Ранні корпоративні VPN віддавали перевагу «повному тунелю», бо це зменшувало ризик мостіння корпоративних і ненадійних мереж на одному хості.
Windows десятиліттями використовує ту саму базову логіку відбору маршруту. Найдовший префікс перемагає; якщо рівно — виграє найменша метрика. Інтерфейси змінюються, математика — ні.
«Use default gateway on remote network» був первинною UX-лазівкою. У старіших клієнтів Windows цей чекбокс вирішував, чи встановлює VPN маршрут 0.0.0.0/0 через тунель.
Корпоративні клієнти VPN почали агресивно штовхати маршрути, коли мережі зросли. Коли є десятки внутрішніх префіксів, простіше штовхати «сумарні маршрути». Так ви ненавмисно поглинаєте домашні підмережі.
Always On VPN зробив розділення тунелів питанням управління. Коли VPN завжди підключений, гігієна маршрутів і DNS перестає бути приємною опцією і стає щоденною нормою.
DNS — сучасний полюс битви. Багато програм безпеки більше дбають про витік DNS, ніж про маршрути, тож клієнти VPN тепер маніпулюють DNS дедалі креативніше.
NRPT зʼявився, бо Windows зрозумів: DNS потребує політик, а не надії. Name Resolution Policy Table дозволяє сказати «ці домени до цих DNS-серверів», що є розділенням тунелів для DNS.
Автонастроювання метрик може бути «корисним», поки так не стане. Windows може автоматично призначати метрики інтерфейсу залежно від швидкості лінку. Віртуальний NIC VPN може повідомляти нісенітні дані й вигравати війну маршрутів.
Перекриття приватних адрес — давня офісна трагедія. RFC1918 дав усім ті самі три приватні діапазони; не дивно, що всі понаставляли ті самі /24. Потім прийшли VPN зі сумарними маршрутами й пожерли домашні мережі до сніданку.

Швидка схема діагностики (перевірити перше/друге/третє)

Якщо потрібно перейти від «VPN зламав мій LAN» до кореневої причини за пʼять хвилин, робіть у такому порядку:

Перше: визначте, чи це маршрути чи DNS

Спробуйте дістатися локального пристрою за IP-адресою (не за іменем). Якщо IP працює, а імʼя — ні, ви в зоні DNS.
Якщо IP не працює — ви в зоні маршрутизації/файрвола. Не здогадуйтеся; читайте таблицю маршрутів.

Друге: перевірте маршрути, що можуть захоплювати вашу LAN

Шукайте 0.0.0.0/0 через VPN (повний тунель).
Шукайте великі/сумарні приватні маршрути, які штовхає VPN (наприклад 192.168.0.0/16) і які перекривають вашу домашню підмережу.
Підтвердіть, що маршрут до локальної підмережі все ще існує і має розумні метрики.

Третє: перевірте, чи клієнт VPN не забороняє локальний LAN

Деякі клієнти встановлюють правила Windows Filtering Platform. Маршрути можуть бути ідеальні, але пакети все одно вмирають.
Перевірте активні правила файрвола, зміни профілю та чи не застосувався раптом профіль «Public».

Четверте: перевірте метрики адаптерів і пріоритет інтерфейсів

Якщо два маршрути однаково специфічні, вирішує метрика. Метрика VPN рівна 1 — це думка, і зазвичай неправильна.

Ось ваша схема триажу: IP vs DNS, потім маршрути, потім фільтри, потім метрики.

Практичні завдання: команди, виводи, рішення (12+)

Усі ці кроки — «реальні завдання»: команда, що значить її вивід, і що робити далі. За потреби використовуйте підвищений PowerShell. Ви тут не для клацань; ви тут, щоб контролювати систему.

Завдання 1: Визначити, чи лише імʼя — проблема розвʼязання імен

cr0x@server:~$ ping 192.168.1.10
Pinging 192.168.1.10 with 32 bytes of data:
Reply from 192.168.1.10: bytes=32 time=2ms TTL=64

Ping statistics for 192.168.1.10:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss)

Що це означає: Є звʼязність рівня 3 до пристрою. Маршрутизація до LAN, ймовірно, в порядку.

Рішення: Якщо «ping nas» не працює, але пінг за IP працює, пропускайте налаштування маршрутів і переходьте одразу до задач з DNS.

Завдання 2: Доведіть шлях розвʼязання імен (який DNS-сервер відповів)

cr0x@server:~$ nslookup nas
Server:  corp-dns01.example
Address:  10.20.30.40

*** corp-dns01.example can't find nas: Non-existent domain

Що це означає: Система питає корпоративний DNS, який не знає локального імені «nas».

Рішення: Виправляйте поведінку DNS (NRPT, списки суфіксів або локальні DNS-сервери), а не дерибанте маршрути.

Завдання 3: Перевірте конфігурацію активного інтерфейсу (знайдіть захоплення VPN)

cr0x@server:~$ ipconfig /all

Ethernet adapter Ethernet:
   IPv4 Address. . . . . . . . . . : 192.168.1.50
   Default Gateway . . . . . . . . : 192.168.1.1
   DNS Servers . . . . . . . . . . : 192.168.1.1

PPP adapter CorpVPN:
   IPv4 Address. . . . . . . . . . : 10.99.12.34
   Default Gateway . . . . . . . . : 10.99.12.34
   DNS Servers . . . . . . . . . . : 10.20.30.40
   DNS Suffix Search List. . . . . : corp.example

Що це означає: VPN рекламуватиме себе як шлюз і штовхатиме корпоративний DNS. Типово для повного тунелю (або погано налаштованого розділення тунелів).

Рішення: Перегляньте таблицю маршрутів далі, щоб перевірити, чи 0.0.0.0/0 тепер через CorpVPN.

Завдання 4: Читайте таблицю маршрутів уважно

cr0x@server:~$ route print
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0       10.99.12.34     10.99.12.34     5
        10.0.0.0        255.0.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25
===========================================================================

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

Рішення: Шукайте маршрути, що перекривають вашу домашню мережу (наприклад 192.168.0.0/16) або перевірте, чи клієнт VPN не блокує локальний LAN через файрвол/WFP.

Завдання 5: Знайдіть класичний перекривний маршрут, що «з’їдає» ваш LAN

cr0x@server:~$ route print | findstr 192.168.
     192.168.0.0    255.255.0.0       10.99.12.34     10.99.12.34     5
     192.168.1.0    255.255.255.0      192.168.1.50    192.168.1.50    25

Що це означає: Маєте 192.168.0.0/16 через VPN і 192.168.1.0/24 локально. /24 є більш специфічним, тому має вигравати. Але якщо ваша локальна мережа — фактично 192.168.0.0/24, вам кепсько: /16 VPN перемагає над відсутнім або неправильним локальним маршрутом.

Рішення: Підтвердіть фактичний локальний префікс і забезпечте явний локальний маршрут для нього. Якщо VPN штовхає маршрут, який точно відповідає вашому локальному префіксу, тільки зміна політики (або перенумерація) дає чисте вирішення.

Завдання 6: Показати, який інтерфейс Windows використає для доступу до локальної IP

cr0x@server:~$ powershell -NoProfile -Command "Find-NetRoute -RemoteIPAddress 192.168.1.10 | ft -AutoSize"
DestinationPrefix NextHop     InterfaceAlias RouteMetric ifIndex PolicyStore
----------------- -------     -------------- ---------- ------ -----------
192.168.1.0/24    0.0.0.0     Ethernet       25         12     ActiveStore

Що це означає: Для 192.168.1.10 Windows обирає Ethernet (локально). Добре.

Рішення: Якщо тут показано VPN-інтерфейс, потрібно виправити специфічність маршруту або метрики (або видалити конфліктний маршрут, який встановив VPN).

Завдання 7: Підтвердьте, чи VPN налаштований на розділення тунелів

cr0x@server:~$ powershell -NoProfile -Command "Get-VpnConnection -Name 'CorpVPN' | Select-Object Name,SplitTunneling,RememberCredential,AuthenticationMethod | Format-List"
Name                 : CorpVPN
SplitTunneling       : False
RememberCredential   : True
AuthenticationMethod : MSChapv2

Що це означає: Розділення тунелів вимкнено. Очікуйте маршрут за замовчуванням через VPN.

Рішення: Якщо політика дозволяє, увімкніть розділення тунелів і додайте явні маршрути до корпоративних мереж (не навпаки).

Завдання 8: Увімкнути розділення тунелів (вбудований VPN Windows)

cr0x@server:~$ powershell -NoProfile -Command "Set-VpnConnection -Name 'CorpVPN' -SplitTunneling $True -PassThru | Select-Object Name,SplitTunneling"
Name    SplitTunneling
----    --------------
CorpVPN True

Що це означає: Windows припинить примусово встановлювати маршрут за замовчуванням через VPN (залежно від того, які маршрути штовхає сервер VPN). Тепер вам потрібні явні маршрути до корпоративних мереж.

Рішення: Негайно додайте маршрути для корпоративних префіксів (або покладайтеся на правильно штовхані маршрути). Перевірте з route print після повторного підключення.

Завдання 9: Додати явний маршрут до корпоративної підмережі через VPN-інтерфейс

cr0x@server:~$ powershell -NoProfile -Command "Add-VpnConnectionRoute -ConnectionName 'CorpVPN' -DestinationPrefix '10.20.0.0/16' -PassThru | ft -AutoSize"
ConnectionName DestinationPrefix
-------------- -----------------
CorpVPN        10.20.0.0/16

Що це означає: Ви робите розділення тунелів правильно: у тунель йде лише корпоративний трафік.

Рішення: Повторіть для всіх потрібних внутрішніх префіксів. Не додавайте величезні «на всякий випадок» маршрути; саме так ви знову захопите LAN користувача.

Завдання 10: Підтвердити, що маршрут за замовчуванням повернувся до локального шлюзу (після повторного підключення)

cr0x@server:~$ route print | findstr /c:" 0.0.0.0"
          0.0.0.0          0.0.0.0        192.168.1.1     192.168.1.50    10

Що це означає: Інтернет/маршрут за замовчуванням знову локальний. VPN має обробляти лише ті префікси, які ви спрямували в нього.

Рішення: Якщо 0.0.0.0 все ще вказує на VPN, клієнт/сервер примушують повний тунель. Не боріться з ОС: вимагайте політику «дозволити локальний LAN» або налаштування клієнта (якщо доступно).

Завдання 11: Перевірити метрики інтерфейсів (мовчазний вирішувач)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetIPInterface -AddressFamily IPv4 | Sort-Object InterfaceMetric | Select-Object InterfaceAlias,InterfaceMetric,NlMtu,ConnectionState | ft -AutoSize"
InterfaceAlias InterfaceMetric NlMtu ConnectionState
-------------- -------------- ----- ---------------
CorpVPN        5              1400  Connected
Ethernet       25             1500  Connected
Wi-Fi          55             1500  Disconnected

Що це означає: У VPN нижча метрика, тож якщо він встановлює будь-який маршрут подібної специфічності, він, ймовірно, виграє.

Рішення: Якщо маршрутизація нестабільна, встановіть явні метрики: підвищте метрику VPN або знизьте метрику LAN відповідно. Будьте обережні: деякі клієнти VPN скидають метрики під час підключення.

Завдання 12: Встановити метрику інтерфейсу для VPN-адаптера (коли ви контролюєте його)

cr0x@server:~$ powershell -NoProfile -Command "Set-NetIPInterface -InterfaceAlias 'CorpVPN' -InterfaceMetric 50"

Що це означає: Відсутність виводу — нормально. Ви змінили порядок пріоритетів.

Рішення: Перевірте з Get-NetIPInterface і потім Find-NetRoute. Якщо клієнт VPN постійно змінює метрику назад — потрібно налаштувати політику на стороні клієнта або продавця, а не ручне підлаштування.

Завдання 13: Прослідкуйте шлях пакета до «локального» хоста, який не працює

cr0x@server:~$ tracert 192.168.1.10

Tracing route to 192.168.1.10 over a maximum of 30 hops

  1    25 ms    24 ms    25 ms  10.99.12.34
  2     *        *        *     Request timed out.

Що це означає: Ваш «локальний» трафік йде в VPN (перший хоп — шлюз/інтерфейс VPN). Це проблема маршрутизації, а не проблема принтера.

Рішення: Виправте таблицю маршрутів: забезпечте явний on-link маршрут для вашої локальної підмережі через Ethernet/Wi‑Fi і видаліть/уникайте конфліктних маршрутів VPN.

Завдання 14: Перевірте, чи змінився профіль Windows Firewall (і блокує відкриття/SMB)

cr0x@server:~$ powershell -NoProfile -Command "Get-NetConnectionProfile | ft -AutoSize"
Name           InterfaceAlias NetworkCategory IPv4Connectivity IPv6Connectivity
----           -------------- --------------- ---------------- ---------------
HomeNetwork    Ethernet       Private         Internet         NoTraffic
CorpVPN        CorpVPN        Public          Internet         NoTraffic

Що це означає: Інтерфейс VPN у профілі Public. Деякі середовища також змушують основний профіль стати Public, що ламає виявлення файлів/принтерів і вхідні правила.

Рішення: Якщо ваш профіль LAN став Public, виправте категорію мережі (де політика дозволяє) або скорегуйте правила файрвола для необхідних сервісів (SMB, mDNS, LLMNR, WS-Discovery) обережно.

Завдання 15: Перегляньте активні правила файрвола, що можуть блокувати локальну підмережу під час VPN

cr0x@server:~$ powershell -NoProfile -Command "Get-NetFirewallRule -Enabled True -Direction Outbound | ? DisplayName -match 'VPN|Block|Local' | Select-Object -First 8 DisplayName,Action,Profile | ft -AutoSize"
DisplayName                          Action Profile
-----------                          ------ -------
Block local subnets when VPN active  Block  Any

Що це означає: VPN-клієнт (або корпоративна політика) встановив явне правило блокування. Зміни маршрутів не допоможуть.

Рішення: Потрібна політична винятковість («дозволити локальний LAN»), інша постава VPN або окрема довірена мережна конструкція. Не повторюйте сліпо зміни маршрутів проти файрвол-блоку.

Завдання 16: Перевірте DNS-сервери та призначення DNS по інтерфейсу

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientServerAddress -AddressFamily IPv4 | ft -AutoSize"
InterfaceAlias ServerAddresses
-------------- --------------
Ethernet       {192.168.1.1}
CorpVPN        {10.20.30.40,10.20.30.41}

Що це означає: DNS розділений по інтерфейсах, але поведінка резольвера Windows може все одно віддавати перевагу корпоративному DNS для односличних імен або певних суфіксів пошуку.

Рішення: Використовуйте FQDN для корпоративних сервісів, налаштуйте свідомо список суфіксів пошуку або застосуйте NRPT, щоб домени корпорації йшли до корпоративних DNS, а все інше залишалося локальним.

Розділення тунелів у Windows: як це насправді працює

Розділення тунелів означає: лише трафік, призначений для конкретних віддалених мереж, йде через VPN. Усе інше — ваша локальна мережа, локальний інтернет-брейк-аут, веб-інтерфейс принтера — залишається в локальній мережі.

Повний тунель означає: VPN стає вашим шлюзом за замовчуванням. Це простіше для команд безпеки (одна контрольна точка), і іноді потрібно для відповідності. Це також спосіб намагатися друкувати через дата-центр у трьох штатах від вас.

У Windows розділення тунелів виражається в маршрутах:

У повному тунелі ви отримуєте 0.0.0.0/0 через VPN.
У розділеному тунелі ви отримуєте лише корпоративні префікси через VPN.
Маршрути локальної підмережі залишаються on-link (Ethernet/Wi‑Fi).

Три моделі, які ви побачите на практиці

Вбудований VPN Windows (IKEv2/SSTP/L2TP) з Set-VpnConnection
Працює добре, коли ви контролюєте обидва кінці або можете штовхати розумні маршрути. Добре підходить для Always On VPN.
Клієнт стороннього виробника, який інжектує маршрути та правила файрвола
Іноді можна налаштувати розділення тунелів у клієнті, але клієнт може також наполягати на «блокуванні локального LAN» за допомогою правил WFP. Читайте налаштування вендора; не вважайте, що ґуджети Windows застосовуються.
«Розділення тунелів», яке таким не є
Деякі налаштування називають себе розділенням тунелів, бо вони виключають кілька інтернет-сервісів, але все одно відправляють усі приватні діапазони через тунель. Це не розділення тунелів; це вибіркова мука.

Що варто робити, на мою думку

Віддавайте перевагу маршруто-орієнтованому розділенню тунелів. Оголошуйте корпоративні префікси явно. Тримайте їх якнайвужчими. Сумарні маршрути прийнятні лише якщо ви контролюєте план адресації і він не перекриватиметься з користувачами.
Не покладайтеся на «чарівні» метрики. Метрики — це вирішувачі при паритеті, а не інструмент архітектури. Спочатку використовуйте явні префікси.
Припускайте, що перекриття RFC1918 траплятиметься. Якщо у вашій корпорації 192.168.0.0/16, ви обрали шлях конфлікту з усіма домашніми маршрутизаторами на планеті.

Цитата, яку варто тримати в голові під час оглядів дизайну VPN: парафраз ідеї Джона Оустерхаута: «Добре інженерне рішення — це управління складністю.» Складність маршрутів завжди збирає відсотки.

DNS: тихіший спосіб, як VPN ламає ваш LAN

Маршрутизація привертає всю увагу, бо вона видима: таблиці маршрутів, шлюзи, кількість хопів. DNS-помилки відчуваються як привиди. Ви вводите \\nas, а Windows знизую плечима. Ви вводите \\192.168.1.10 — і це працює. Це не надприродне; це резольвер робить те, для чого його налаштували.

Чому DNS VPN завдає локального болю

Корпоративний DNS не знає ваших локальних імен. Однослівні імена як nas або printer часто залежать від локального суфіксу пошуку, mDNS, LLMNR або DNS-проксі домашнього маршрутизатора.
Корпоративний DNS може навмисно блокувати приватні зворотні запити. Команди безпеки іноді жорстко налаштовують резолвери, щоб відмовляти «дивні» запити від клієнтів, включно з локальними зворотними зонами.
Windows може віддавати перевагу DNS одного інтерфейсу для певних запитів. DNS по інтерфейсах існує, але поведінка залежить від суфіксів, політик і від того, чи клієнт VPN встановив пріоритет інтерфейсу.

Практична DNS-стратегія, що не змусить вас плакати

Використовуйте FQDN для корпоративних сервісів. Не залежіть на суфіксах пошуку для продуктивних інструментів. Це зручно, поки не перестає працювати.
Використовуйте NRPT, щоб відправляти домени корпорації до корпоративних DNS. Це чисте розділення тунелів для імен.
Залишайте локальний DNS для локальних імен. Якщо ви хочете, щоб nas резольвився, система має використовувати резолвер, який про нього знає (домашній маршрутизатор, локальний DNS-сервер, файл hosts як останній варіант).

Жарт №1: DNS — це як телефонна книга, тільки частіше не точна, і ви все одно називаєте її «критичною інфраструктурою».

NRPT і стратегії розвʼязання імен (пригоди Windows Pro)

NRPT (Name Resolution Policy Table) дозволяє сказати: «Для цих просторів імен використовуйте ці DNS-сервери.» Це дорослий варіант сподівання, що Windows обере правильний DNS-інтерфейс.

Типовий шаблон:

Для corp.example і, можливо, кількох внутрішніх зон — використовувати корпоративні DNS-сервери, досяжні через VPN.
Для всього іншого — продовжувати використовувати локальний DNS (домашній маршрутизатор, провайдер тощо).

NRPT зазвичай управляється через групову політику в організаціях. Але для діагностики корисно переглянути, що вже там є.

cr0x@server:~$ powershell -NoProfile -Command "Get-DnsClientNrptPolicy | Select-Object Namespace,NameServers,DirectAccessDnsServers,Comment | ft -AutoSize"
Namespace      NameServers          DirectAccessDnsServers Comment
---------      ----------          ---------------------- -------
.corp.example  {10.20.30.40,10.20.30.41} {}

Що це означає: Запити для *.corp.example підуть до перерахованих корпоративних DNS-серверів.

Рішення: Якщо NRPT відсутній і ваш VPN захоплює DNS глобально, попросіть NRPT-базоване розділення DNS або налаштуйте політики DNS/маршрутів залежно від безпекової позиції організації.

Три корпоративні історії з поля бою

Міні-історія 1: Інцидент через неправильне припущення (перекриття адресного простору)

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

У понеділок черга допомоги вибухнула: «Не можу роздрукувати», «не бачу домашній NAS», «Zoom працює, а додаток розумного термостата — ні», і найцікавіше: «Ігрова консоль дитини каже, що вона в іншій країні.» Останнє не зовсім вина VPN, але не дуже підняло мораль.

Перші реагувальники шукали правила файрвола й драйвери, бо VPN підключався і корпоративні додатки працювали. Хитрість була помітити патерн: несправності завжди були до пристроїв типу 192.168.0.0-ish. У людей із домашніми мережами в 10.0.0.0/24 проблем було менше.

Таблиці маршрутів розповіли історію: великий 192.168.0.0/16 через VPN «бо корпорація використовує багато 192.168.*». Домашні маршрутизатори теж використовували 192.168.*. Пакети до домашнього принтера йшли в тунель, досягали корпоративного маршрутизатора, який не мав маршруту до «HP LaserJet Боба», і тихо загинули.

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

Міні-історія 2: Оптимізація, що повернулась бумерангом (метрики та «швидший VPN»)

Інша організація мала скаргу на продуктивність: «VPN повільний». Хтось помітив, що у VPN-адаптера вища метрика ніж у Wi‑Fi, і вирішив «оптимізувати», поставивши метрику VPN на 1. Зміна розгорнулась скриптом. Було швидко. Було неправильно.

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

Що сталося: з наднизькою метрикою VPN Windows віддавав перевагу VPN для маршрутів, що не були жорстко закріплені, особливо коли одночасно були підключені Ethernet і Wi‑Fi і деякі маршрути були однаково специфічні. Додайте трохи DHCP-хаосу — і вибір маршруту почне скакати у невдалий момент.

Відкочення зміни все виправило. Потім вони вчинили по-дорослому: залишили метрики в більшості автоналаштування, увімкнули розділення тунелів правильно і штовхнули явні корпоративні маршрути. Продуктивність покращилася з правильних причин: менше зайвого трафіку через тунель, менше повторних передач, менше зламаних локальних потоків.

Міні-історія 3: Нудна, але правильна практика, що врятувала день (стандартна діагностика та знімки маршрутів)

Команда фінансових послуг мала внутрішнє правило: кожен інцидент віддаленого доступу має мати «знімок мережі», прикріплений до тикету. Без винятків. Було нудно. Люди скаржилися. Потім це не раз окупилося.

Коли новий профіль VPN викликав розрізнені повідомлення про «LAN недоступний», інженер на виклику не гадував. Він порівняв два знімки від одного користувача: до підключення і після. Дельта була очевидною: маршрут за замовчуванням через VPN і нове блокуюче правило з імʼям, яке точно відображало, що воно робить.

Оскільки були стандартні артефакти — ipconfig /all, route print, метрики інтерфейсів, DNS-сервери — вони могли ескалувати точно: «Політика клієнта встановлює вихідні блоки до локальних підмереж під час підключення. Це не проблема маршруту користувача.»

Команда безпеки визнала це швидко, бо було вимірювано, а не емоційно. Вони створили затверджену групу винятків для користувачів, яким потрібен локальний доступ (лаби, техніки на місці) і задокументували ризики. Нудна практика — повторювана діагностика — тримала дискусію в межах фактів, а не скріншотів.

Поширені помилки: симптом → корінь → виправлення

Цей розділ — те, що зʼявляється в тикетах, Slack-потоках та ваших найменш улюблених нарадах.

1) «VPN підключено, але я не можу дістатися принтера/NAS»

Симптом: Локальний пристрій по імені не працює; іноді й по IP не працює.

Корінь: Повний тунель (маршрут за замовчуванням через VPN), або VPN блокує локальні підмережі через файрвол/WFP.

Виправлення: Якщо дозволено, увімкніть розділення тунелів і додайте явні корпоративні маршрути. Якщо політика блокує локальний LAN — запросіть налаштування «allow local LAN» або профіль винятку. Валідируйте з tracert та перевіркою правил файрвола.

2) «По IP працює, по імені не працює»

Симптом: ping 192.168.1.10 працює; ping nas — ні.

Корінь: Тепер корпоративний DNS — ваш основний резолвер, і він не знає локальних імен.

Виправлення: Використовуйте NRPT, щоб направляти корпоративні домени до корпоративного DNS. Залишайте локальний DNS для локальних імен. Або використовуйте FQDN/статичні записи, де доречно.

3) «Деякі локальні IP працюють, інші — ні»

Симптом: Можна дістатися 192.168.1.1, але не 192.168.1.10 під час VPN.

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

Виправлення: Порівняйте Find-NetRoute для робочих і не робочих адрес. Видаліть/уникайте конфліктних маршрутів VPN. Звузьте корпоративні префікси. Якщо це блокувальне правило — виправляйте політику, а не маршрути.

4) «Локальні шари зникають тільки на Wi‑Fi, а не на Ethernet»

Симптом: Поведінка змінюється залежно від середовища доступу.

Корінь: Різні локальні підмережі, різні метрики, різні DNS-сервери або різні профілі файрвола по інтерфейсу.

Виправлення: Перевірте Get-NetConnectionProfile і Get-NetIPInterface на обох інтерфейсах. Стандартизовуйте метрики і DNS по інтерфейсу. Підтвердьте маршрути для точного локального префіксу, в якому ви знаходитеся.

5) «Усе повільно після увімкнення розділення тунелів»

Симптом: Корпоративні додатки повільні, інтернет — в порядку.

Корінь: Відсутні корпоративні маршрути, тож трафік неправильно хендлиться (наприклад, виходить локально й не повертається), або DNS для корпоративних доменів йде до публічних резолверів і таймаутиться.

Виправлення: Додайте потрібні корпоративні префікси з Add-VpnConnectionRoute і впровадьте розділення DNS (NRPT). Перевірте з tracert до корпоративних кінцевих точок і nslookup для FQDN корпорації.

6) «VPN працює, але один внутрішній додаток недоступний»

Симптом: Більшість ресурсів корпорації працюють; одна підмережа ні.

Корінь: Маршрут цієї підмережі не штовхнули/не додали, або вона перекривається локальним діапазоном і програє.

Виправлення: Find-NetRoute -RemoteIPAddress x.x.x.x для серверу додатку. Додайте конкретний маршрут через VPN або виправте перекриття перенумерацією (так, реально) або NAT на VPN-концентраторі.

7) «Після підключення VPN Windows каже, що мережа — Public, і виявлення помирає»

Симптом: Пристрої не виявляються; SMB-пошук не працює; вхідні правила не застосовуються.

Корінь: Категорія мережі змінилася на Public, часто через поведінку VPN-адаптера або плутанину NLA.

Виправлення: Виправте категорію мережі, де це дозволено, або створіть явні правила файрвола для потрібних сервісів на потрібному профілі. Не вимикайте файрвол просто так, якщо вам не подобаються аудити.

Жарт №2: «Просто вимкніть файрвол» — це мережевий еквівалент фікса дряскоту в машині підвищенням гучності радіо.

Контрольні списки / покроковий план (навіть нудний навмисно)

Покроково: виправити профіль VPN Windows для розділення тунелів

Перелік того, що має йти через VPN. Складіть список корпоративних префіксів і доменів, необхідних для роботи. Якщо ваш список — «усе», ви фактично робите повний тунель і повинні це визнати.
Увімкніть розділення тунелів. Використайте Set-VpnConnection -SplitTunneling $True.
Додайте маршрути для кожного корпоративного префіксу. Використайте Add-VpnConnectionRoute для кожного префіксу.
Перепідключіть VPN. Зміни маршрутів часто застосовуються чисто після перепідключення.
Перевірте маршрути. Підтвердіть, що маршрут за замовчуванням локальний, а корпоративні префікси спрямовані в VPN.
Виправте поведінку DNS. Використайте NRPT для корпоративних зон. Переконайтеся, що локальні імена все ще розвʼязуються локально (або перейдіть на FQDN).
Фіксуйте метрики лише за потреби. Якщо відбір маршрутів нестабільний, підлаштуйте метрики інтерфейсів — але остерігайтеся скидання клієнтом.
Задокументуйте рішення. Розділення тунелів — це безпекова позиція. Зробіть ризики явними і затвердженими.

Чекліст: що зібрати для відтворюваного тикету «VPN зламав LAN»

Локальна підмережа (наприклад, 192.168.1.0/24), IP шлюзу і чи Wi‑Fi/Ethernet
ipconfig /all до та після підключення VPN
route print до та після підключення VPN
Get-NetIPInterface (метрики) і Get-NetConnectionProfile (профіль файрвола)
Один провалений тест по імені та по IP (ping nas і ping 192.168.1.10)
nslookup для корпоративного FQDN і локального імені
tracert до одного локального IP і одного корпоративного IP
Будь-яка налаштування клієнта VPN з написом «block local network» / «allow LAN access»

Поширені питання

1) Чому мій VPN вбиває доступ до пристроїв 192.168.1.x?

Або VPN стає вашим шлюзом за замовчуванням (повний тунель), або він штовхає маршрути, що перекривають вашу домашню підмережу. Перевірте route print на наявність 0.0.0.0/0 через VPN або широких маршрутів 192.168.0.0/16.

2) Чи небезпечне розділення тунелів?

Може бути, якщо ваша кінцева точка незадокументована або ви фактично мостите ненадійну мережу та доступ до корпоративних ресурсів без контролю. В управлюваних середовищах розділення тунелів поширене з компенсуючими заходами (EDR, перевірка стану пристрою, політики DNS, per-app VPN, сильна автентикація). Безпека — це дизайн, а не галочка.

3) Я увімкнув розділення тунелів, але корпоративні додатки перестали працювати. Що я пропустив?

Ймовірно ви прибрали маршрут за замовчуванням через VPN, але не додали маршрути до всіх потрібних корпоративних префіксів, або DNS для корпоративних доменів все ще йде до локальних резолверів. Додайте відсутні маршрути і впровадьте розділення DNS (NRPT).

4) Чому `\\nas` не працює, а `\\192.168.1.10` працює?

Причина — DNS (або LLMNR/mDNS). Ваш VPN, ймовірно, встановив корпоративний DNS як основний, і цей DNS не може розвʼязати ваші локальні однословні імена. Виправте це NRPT, використанням FQDN або локальними DNS-налаштуваннями.

5) Чи можу я просто додати статичний маршрут для моєї домашньої підмережі?

Іноді можна. Якщо VPN штовхає конфліктний маршрут, більш специфічний локальний маршрут може виграти. Але якщо VPN встановлює блокуючі правила файрвола або якщо конфлікт точний (той самий префікс і довжина), статичні маршрути не врятують. Також багато клієнтів VPN пере-застосовують маршрути при підключенні.

6) Чому в клієнті VPN є перемикач «Allow LAN access»?

Бо деякі клієнти навмисно блокують локальні підмережі під час підключення, щоб запобігти ризикам split-horizon (наприклад, шкідливе ПЗ, яке може дістатися корпоративної мережі через скомпрометовану LAN). Цей перемикач зазвичай керує поведінкою файрвола/WFP, а не лише маршрутами.

7) Що з IPv6 — чи варто його вимикати?

Не вимикайте IPv6 як перший крок. Спочатку перевірте IPv6-маршрути та чи підтримує VPN IPv6. Якщо у вас є IPv6 в LAN, а VPN лише IPv4, ви можете отримати дивну асиметрію. Вирішіть послідовну політику: або правильно підтримуйте IPv6, або визначте, як обробляти IPv6-трафік.

8) Як дізнатися, чи Windows відправляє трафік у VPN чи на локальний інтерфейс?

Використайте Find-NetRoute -RemoteIPAddress, щоб бачити обраний інтерфейс для призначення, і tracert, щоб підтвердити перший хоп. Якщо перший хоп — шлюз VPN/інтерфейс, трафік не залишається локальним.

9) Моя компанія забороняє розділення тунелів. Чи я приречений?

Можливо, але у вас є варіанти: попросіть офіційний виняток «allow local LAN», використайте окрему неперекривну домашню підмережу (перенумеруйте LAN), або використайте окремий пристрій для локальних ресурсів. Боротися з політикою хакнутими маршрутами зазвичай програшно — і створює гірші інциденти.

10) Чому це трапляється частіше з домашніми мережами, ніж з офісними?

Бо домашні мережі часто використовують стандартні споживчі підмережі (192.168.0.0/24, 192.168.1.0/24). Корпорації, що штовхають широкі приватні маршрути, конфліктують з цими дефолтами. Офіси зазвичай мають керований план адресації і менше перекриттів — ідеально.

Висновок: наступні кроки, які ви можете зробити сьогодні

Якщо ваш VPN блокує локальний LAN, перестаньте ставитися до цього як до примарного баґу клієнта. Це маршрутизація, DNS або політика — зазвичай у такому порядку.

Пройдіть швидку діагностику: протестуйте по IP vs імені, потім подивіться маршрути, потім перевірте на наявність файрвол/WFP-блоків, потім метрики.
Прийміть рішення: Якщо політика дозволяє, впровадьте справжнє розділення тунелів (явні корпоративні маршрути). Якщо політика забороняє — просіть винятки «allow LAN» або перенумеруйте домашню підмережу.
Виправте DNS цілеспрямовано: NRPT для корпоративних зон, локальний DNS для локальних імен і менше однословних хостнеймів у робочих процесах.
Стандартизайте докази: збирайте ipconfig /all, route print і ключові виводи PowerShell до/після підключення. Це перетворює суперечки на інженерні факти.

Зробіть це раз, задокументуйте і наступного разу, коли хтось скаже «VPN зʼїв мій принтер», у вас буде відповідь краще за зітхання.

Схожі статті

Відключення Windows IKEv2: поширені помилки та надійні виправлення