Чому ваш VPN у Windows вбиває локальний принтер і як це зупинити

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

Спершу прочитайте таблицю маршрутів

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

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

Приберіть маршрут за замовчуванням, трьома способами

У вбудованому профілі Windows керування — це прапорець. Відкрийте властивості підключення, IPv4, потім Додатково й зніміть Use default gateway on remote network; новіший застосунок Параметри ховає той самий діалог на рівень глибше. З командного рядка з підвищеними правами та сама зміна — одна команда cmdlet:

Set-VpnConnection -Name "Corp" -SplitTunneling $true

Профіль OpenVPN працює інакше, тому його поведінка збиває тих, хто чекає прапорця. Його директива redirect-gateway def1 взагалі не замінює маршрут за замовчуванням: вона встановлює два маршрути половинного діапазону, 0.0.0.0/1 і 128.0.0.0/1, які разом перемагають маршрут за замовчуванням, не видаляючи його. Оскільки початковий маршрут за замовчуванням виживає, додавання префікса, спрямованого на net_gateway, повертає локальному маршрутизатору лише цей префікс. Ця деталь пояснює, чому виправлення для профілю def1 — це маршрут префікса, а не прапорець, якого ніхто не знаходить.

Поверніть лише те, що стосується роботи

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

Add-VpnConnectionRoute -ConnectionName "Corp" -DestinationPrefix 172.20.0.0/16

Старіший підхід досі працює і досі є в кожному чек-листі: route -p add 172.20.0.0 mask 255.255.0.0 172.20.0.1 if 14, з власним індексом інтерфейсу та адресою шлюзу тунелю. Він зберігається між перезавантаженнями, у чому і сенс, і небезпека: під час наступного завантаження індекс може належати чомусь іншому.

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

Коли сервер вирішує за вас

Клієнт, який ігнорує ваш прапорець, зазвичай підкоряється політиці. Профілі Cisco несуть налаштування Allow Local LAN Access, і headend може надіслати політику tunnel-all, яка скасовує все, що клієнт обрав би; у примусовому тунелі локального перемикача немає. Читайте журнал клієнта про надіслані маршрути й рядки політики замість повторної перевірки того самого діалогу.

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

Перекриття — інша проблема

Якщо домашня LAN і офісна LAN ділять префікс на кшталт 192.168.0.0/24, жоден маршрут їх не розрізнить. Кожен пакет цього діапазону має один результат пошуку, і виправлення — перенумерувати один бік або дістатися офісу через трансльовану адресу з пулу. Додавання конкретніших маршрутів лише зсуває, яка половина мережі ламається.

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