VPN блокира локалната LAN в Windows: маршрут или политика на клиента?

Принтер, NAS или машина за разработка на собственото ви бюро спират да отговарят в момента, в който работният VPN се свърже. Понякога една команда за маршрут го оправя за секунди; понякога същият маршрут е правилен, а пакетите все пак изчезват, което означава, че гледате друг проблем с подобен симптом. Решението се свежда до три въпроса и точно грешният им ред е причината хората да прекарват цяла вечер в изтриване и повторно добавяне на маршрути.

Три въпроса преди всяка команда

Първо: има ли запис за локалния префикс и сочи ли той към физическия адаптер? Второ: получава ли клиентът разрешение или забрана за локалната мрежа от шлюза при свързване? Трето: нужен ли ви е само изходящ достъп до LAN, или нещо в интернет също трябва да достига до услуга, работеща на вашата машина?

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

Въпрос първи: маршрут, филтър или име

Прочетете таблицата, преди да добавите нещо към нея. Индексът на интерфейса е важен, защото всяка команда за маршрут по-долу е закотвена към него:

route print -4
Get-NetRoute -DestinationPrefix 192.168.1.0/24 | Format-Table InterfaceIndex,NextHop,RouteMetric

Директно свързана подмрежа обикновено запазва маршрут на връзката дори докато тунелът е активен, така че запис може да съществува, а трафикът все пак да се проваля. Тази комбинация е подписът на филтър, който работи след маршрутизацията, и това е случаят, в който втори, по-конкретен маршрут не променя нищо.

Тествайте отделно по адрес и по име. Ако ping 192.168.1.50 отговаря, а net view 192.168.1.50 не, таблицата за маршрутизация никога не е била проблемът: тунелът смени резолвера и локалното име вече не се разрешава. Добавянето на маршрут за това е похабена работа.

Въпрос втори: позволява ли шлюзът достъп до локалната LAN?

Търговският клиент инсталира повече от маршрути. Той получава политика при свързване и тази политика може да включва изрично разрешение за локалната мрежа. В разгръщанията на Cisco IPsec груповата политика носи настройката за split-tunneling и отделен флаг за достъп до локалната LAN; отметката в клиента е заявка, която шлюзът може да откаже. В AnyConnect профилът управлява списъците за включване и изключване на split и същото разрешение. В Windows RRAS еквивалентите са опцията за шлюз по подразбиране в профила плюс статичните маршрути, които сървърът задава.

Когато флагът е изключен, документираното поведение е, че клиентът блокира трафика към директно свързаната подмрежа, въпреки че съществува валиден, по-конкретен маршрут. Затова и маршрути, които клиентът не притежава, могат да изчезнат секунди след като ги добавите: клиентът преизгражда състоянието, което му е наредено да изгради, а не се бори с вас.

Журналът на клиента записва решението при свързване и четенето му е по-бързо от всеки експеримент на машината. Ако журналът казва, че локалният достъп е блокиран, спрете: никаква поправка от командния ред не оцелява след това и остават само промяна на политиката, достъп до ресурса през тунела или затваряне на клиента във виртуална машина и оставяне на хоста в локалната мрежа.

Въпрос трети: коя посока ви трябва?

Изходящият трафик към близко устройство е въпрос на маршрутизация. Насочете LAN префикса към локалния шлюз с метрика, достатъчно ниска, за да победи маршрута по подразбиране на тунела:

route add 192.168.1.0 mask 255.255.255.0 192.168.1.1 metric 1 if 12
route add 192.168.1.50 mask 255.255.255.255 192.168.1.1 -p

Втората форма заковава едно устройство, което е точно това, което искате, когато един адрес е цялото изискване. Еквивалентът netsh записва същото решение по име на интерфейс, а не по индекс:

netsh interface ipv4 add route prefix=192.168.1.0/24 interface=12 nexthop=192.168.1.1 store=persistent

Командите за маршрут се провалят с Параметърът е неправилен, когато адресът и маската не съвпадат, например адрес на хост с маска /24. Използвайте адреса на мрежата за маршрут към подмрежа и маска за хост за един хост.

Входящият е различен. VNC или SSH сървър на същата машина става недостъпен, когато отговорите на входяща връзка излизат през VPN шлюза и никога не се връщат. Проверете на какво слуша услугата, преди да пипате маршрути:

netstat -ano | findstr :5900

Слушател, вързан към един конкретен адрес, няма да отговаря на другия интерфейс. Свързването му към всички интерфейси е съзнателно решение, взето заедно с правило на защитната стена, ограничено до мрежата, на която вярвате. Едва след това ремонтът на маршрута възстановява обратния път.

Приложете най-малката промяна, която пасва

Другият често срещан ход е премахване на отметката на „Използване на шлюз по подразбиране в отдалечената мрежа“ в разширените свойства на IPv4. Това запазва интернет трафика локален, но прави две неща наведнъж: VPN спира да бъде пътят по подразбиране и клиентът спира да получава маршрути за отдалечената мрежа, включително multicast. Премахнете отметката и отдалечената LAN изчезва, освен ако сървърът не изпрати конкретните отдалечени префикси, от които се нуждае всеки клиент.

Тази асиметрия решава реда на работа. Ако отдалечената страна трябва да остане напълно достъпна, изпращайте отдалечените подмрежи от сървъра и оставете локалното по подразбиране на мира. Ако не можете да промените сървъра, добавете постоянен маршрут към отдалечения префикс през адреса, който тунелът е задал, и проверете с route print, че префиксът сочи към VPN интерфейса, докато по подразбиране все още сочи към физическия шлюз.

След това потвърдете, че ремонтът оцелява след повторно свързване, защото непостоянните маршрути умират с адаптера и скрипт, който се изпълнява след всяко свързване, е честното място за тях. Тествайте едно локално устройство и един отдалечен ресурс в една и съща сесия, прекъснете, свържете се отново и тествайте пак. Ако локалното устройство все още се проваля, докато маршрутът изглежда правилен, върнете се към втория въпрос: клиентът филтрира и отговорът е промяна на политиката, а не втори конкурентен маршрут.