Локальна мережа недоступна при підключеному VPN? Чотири перевірки

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

Спершу подивіться на таблицю маршрутів, яку встановив клієнт

Відкрийте таблицю маршрутів клієнта, поки VPN підключений. У Linux використовуйте ip route, у Windows — route print або Get-NetRoute, а в macOS — netstat -rn. Ви шукаєте маршрут за замовчуванням через тунель і те, що сталося з фізичним маршрутом за замовчуванням.

Клієнт із повним тунелем часто додає два напівмаршрути за замовчуванням, 0.0.0.0/1 і 128.0.0.0/1, замість заміни 0.0.0.0/0. Початковий маршрут за замовчуванням залишається видимим, але програє кожен пошук, тому таблиця може виглядати цілою, поки весь трафік за межами підмережі зміщується. Якщо клієнт VPN пропонує режим роздільного тунелю і політика це дозволяє, це найчистіше виправлення.

Якщо тунель має залишитися маршрутом за замовчуванням, закріпіть натомість локальну підмережу. У Linux маршрут називає фізичний інтерфейс і шлюз; у Windows додайте -p, щоб зробити його постійним, і прочитайте номер інтерфейсу з route print, а не вгадуйте його:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Закріплений маршрут тримається лише поки названа в ньому адреса не змінюється. Ноутбук, який при кожному підключенні отримує новий номер Wi-Fi-адаптера, знову порушить правило, тому перевірте адресу інтерфейсу, перш ніж вирішити, що виправлення не вдалося.

По-друге, переконайтеся, що адреса спочатку була локальною

Якщо призначення лежить усередині підключеної підмережі, маршрут за замовчуванням через тунель ніколи не застосовується і VPN ні до чого. Принтер на 192.168.1.40 у клієнта з 192.168.1.0/24 використовує підключений маршрут; якщо ця адреса не працює, дивіться на пристрій, комутатор або міжмережевий екран клієнта, а не на VPN.

Випадок, який вводить людей в оману, — публічна адреса локального сервера. Зсередини локальної мережі дістатися до WAN-адреси роутера і повернутися назад дозволяє лише hairpin NAT, а багато роутерів його просто не реалізують для пробросу портів. Перевірте приватну адресу поруч із публічною. Якщо приватна працює, а публічна ні, VPN лише виявив обмеження NAT, яке існувало раніше.

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

По-третє, подивіться, хто тепер відповідає на імена

Корпоративний резолвер знає інтранет і зазвичай нічого не знає про ім’я хоста NAS, ім’я Bonjour принтера чи локальний псевдонім роутера. Коли VPN проштовхує свої DNS-сервери, ці імена перестають розв’язуватися, хоча їхні адреси досі доступні. Запитайте ім’я напряму і порівняйте відповідь з адресою, яку, як ви знаєте, має пристрій.

У Linux resolvectl query nas.local показує, який резолвер відповів. У Windows nslookup nas.local називає сервер, а ipconfig /all показує порядок резолверів. Якщо локальним суфіксом тепер керує корпоративний резолвер, або спрямуйте цей суфікс назад до локального резолвера, або використовуйте для пристрою IP-адресу.

Виявлення — окремий рівень. mDNS і широкомовлення не проходять через маршрутизований тунель, тому пристрій може бути доступним за адресою, поки його ім’я залишається невидимим. Це вирішує відбивач або локальний запис DNS; маршрут — ні.

По-четверте, перевірте, чи не підключена до VPN і друга машина

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

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

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

Застосуйте виправлення, що відповідає проваленій перевірці

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

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

Запишіть маршрут, адресу і резолвер, які працювали при підключеному VPN. Наступне перепідключення змінить хоча б одне з них, і нотатка перетворить наступний збій на коротке порівняння замість нового розслідування.