Маршрутызатар у кліенцкім рэжыме VPN: чаму знікаюць прылады LAN
Прылады LAN знікаюць пасля пераходу маршрутызатара ў кліенцкі рэжым VPN: спачатку праверце функцыю інспекцыі ў шляху перасылкі, потым дыяпазон LAN, які змяніла прашыўка.
Думка, што кліенцкі рэжым сам забівае доступ да LAN, заганяе людзей у няправільнае меню налад, а сапраўдных прычын звычайна дзве. Тунель не выдаляе мост LAN і не перашкаджае правадным і бесправодным кліентам дасягаць адзін аднаго. Лакальны доступ ламае або функцыя інспекцыі ў шляху перасылкі маршрутызатара, або дыяпазон адрасоў LAN, які зрушыўся разам з прашыўкай. Абодва даюць адну і тую ж скаргу, і ні адзін не выпраўляецца пераўстаноўкай профілю VPN.
Міф і што насамрэч змяняе кліенцкі рэжым
Кліенцкі рэжым дадае інтэрфейс тунеля і маршрут па змаўчанні, які вядзе праз яго, а затым перасылае трафік LAN у гэты тунель. Мост паміж праваднымі партамі і бесправоднымі радыёмадулямі застаецца нязменным, як і лакальная камутацыя. Змяняецца палітыка: які трафік перасылаецца, дзе ён транслюецца і які рэзалвер атрымліваюць кліенты.
Гэта адрозненне важнае, бо зламаная LAN звычайна азначае, што змянілася адна з гэтых трох палітык, а не тое, што маршрутызатар перастаў быць камутатарам. Маршрутызатар, які ўсё яшчэ адказвае на ўласную старонку адміністравання, даказвае, што інтэрфейс LAN жывы. Маршрутызатар, які не адказвае зусім нічога, мае іншую праблему, напрыклад зменены адрас LAN або кліент у няправільнай падсетцы.
Таму карысны першы крок — знайсці, які ўзровень зламаўся, а не змяняць узровень, які вы падазраеце.
Праверце тры цэлі, перш чым чапаць наладу
З праваднога кліента праверце тры цэлі асобна і запішыце кожны вынік: уласны адрас LAN маршрутызатара, іншую прыладу на тым жа камутатары па IP і нешта, дасяжнае толькі праз тунель. Рабіце іх у такім парадку, бо кожны вынік выключае іншы ўзровень. На першым праходзе выкарыстоўвайце адрасы, а не імёны, бо збой імя дамешвае DNS у пытанне пра злучэнне.
Узор адказаў — гэта дыягназ. Маршрутызатар, які адказвае, а лакальныя прылады не, паказвае на лакальную камутацыю або функцыю фільтрацыі, а не на маршрутызацыю. Лакальныя прылады, якія адказваюць, а бок тунеля не, паказваюць на маршрут тунеля або аддалены файрвол. Калі ўсё адказвае па адрасе, а імёны не, гэта пытанне рэзалвера, і ніякае рэдагаванне маршрутаў яго не выправіць.
| What answers | What it points at |
|---|---|
| Router only | LAN-side filtering or a broken bridge |
| Router and local hosts, not remote | Tunnel route, NAT or remote firewall |
| Addresses yes, names no | DNS handed to clients by the router |
| Nothing at all | Client subnet or router LAN address changed |
Трымайце табліцу побач з вынікамі тэстаў. Яна ператварае расплывістую скаргу ў адзін радок, з якім можна дзейнічаць.
Узровень бяспекі ўнутры шляху перасылкі
Спажывецкія маршрутызатары ўсё часцей пастаўляюцца з функцыяй інспекцыі, якая назірае за перасылаемым трафікам, і яна працуе ў тым жа шляху, што нясе пакеты з LAN у тунель. Калі гэтая інспекцыя не можа класіфікаваць трафік тунеля, перасылка можа спыніцца, пакуль сам тунель застаецца ўзнятым і маршрутызатар паведамляе пра здаровае злучэнне. У журнале VPN гэтага не відаць, бо VPN сапраўды падключыўся.
Дыягназ — гэта кіраваны эксперымент, а не пастаянная змена. Запішыце бягучую наладу, выключыце функцыю на час аднаго тэсту, зноў узніміце тунель і праверце адзін лакальны хост па адрасе. Перасылка, якая вярнулася, — гэта доказ, які вам быў патрэбны, і кампраміс тады становіцца рашэннем, а не здагадкай. Калі нічога не змянілася, адразу ўключыце яе зноў і пераходзьце да прычыны ў адрасацыі.
Пакідаць платную функцыю бяспекі выключанай, каб тунель працягваў працаваць, — гэта кампраміс, які трэба рабіць свядома і запісваць. Варта таксама спытаць, ці належыць тунель іншай прыладзе, бо маршрутызатар, які павінен усё інспектаваць, і маршрутызатар, які павінен усё перасылаць, — дзве розныя працы.
Другая прычына: дыяпазон LAN зрушыўся
Абнаўленні прашыўкі рэгулярна скідваюць адрас LAN да заводскага значэння вытворцы, а некаторыя маршрутызатары маюць яўны перамыкач рэжыму, які вырашае, ці LAN захоўвае прыватны дыяпазон, ці атрымлівае яго ад вышэйшай прылады. Кліент, які чакае 192.168.8.x, можа апынуцца на 10.64.0.x, і тады сеанс SSH да хоста сканчаецца па тайм-ауце, хоць тунель цалкам здаровы.
ipconfig /all
ip addr show
ip route get 192.168.8.20
Прачытайце прэфікс і шлюз з арэнды, перш чым адкрываць старонку маршрутызатара. Першыя дзве каманды паказваюць, што кліент насамрэч атрымаў, а трэцяя — які інтэрфейс кліент выкарыстае для лакальнага адраса, і менавіта так выяўляе сябе засталы маршрут або састарэлая падсетка. Затым параўнайце гэта са старонкай LAN і рэжымам, у якім знаходзіцца маршрутызатар.
Калі дыяпазон не можа вярнуцца, абнавіце кожны аб'ект, які яго называе: рэзерваванні DHCP, любы статычны маршрут у старую падсетку і кожнае правіла файрвола з папярэднім прэфіксам. Дыяпазон, які сутыкаецца з аддаленай падсеткай тунеля, — горшы варыянт, бо лакальныя прылады застаюцца дасяжнымі, а аддаленыя прызначэнні бясшумна накіроўваюцца ў LAN.
Перападключыцеся і пераправерце ў парадку пакетаў
Пасля любой з дзвюх змен перападключыце тунель і паўтарыце праверкі ў парадку пакетаў: маршрутызатар, лакальны хост, аддалены хост, затым імёны, затым праграма. Тэставанне праграмы першай хавае, які ўзровень яшчэ зламаны, а паўторная спроба браўзера з кэшаваным імем можа выглядаць як збой маршрутызацыі.
Запішыце версію прашыўкі, прэфікс LAN і стан функцыі інспекцыі побач з профілем VPN. Усе тры — гэта канфігурацыя, якую наступнае абнаўленне можа перазапісаць, і два радкі нататак зберагаюць гадзіну, якую вы толькі што выдаткавалі.