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, а значэнне па змаўчанні па-ранейшаму паказвае на фізічны шлюз.

Затым пераканайцеся, што рамонт перажывае перападключэнне, бо непастаянныя маршруты гінуць разам з адаптарам, і скрыпт, які запускаецца пасля кожнага падключэння, — сумленнае месца для іх. Праверце адну лакальную прыладу і адзін аддалены рэсурс у адной сесіі, адключыцеся, падключыцеся зноў і праверце яшчэ раз. Калі лакальная прылада ўсё яшчэ збягае, пакуль маршрут выглядае правільным, вярніцеся да другога пытання: кліент фільтруе, і адказ — змена палітыкі, а не другі канкуруючы маршрут.