Защо 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 е маршрут за префикс, а не квадратче, което никой не намира.

Върнете само това, което принадлежи на работата

С премахнатия маршрут по подразбиране тунелът не носи нищо, затова префиксите за работа трябва да се назоват изрично. Cmdlet-ът, който обвързва префикс с връзката, е по-безопасен от постоянен маршрут, защото се инсталира само докато връзката е активна и не зависи от номер на интерфейс:

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 към вътрешен хост и към публичен. Първият хоп трябва да е различен и ако не е, разделянето не е налице, независимо какво съобщава клиентът. После се свържете отново веднъж и повторете, защото изпратените маршрути се връщат с всяка сесия.