Лакальная сетка недасяжная пры падключаным 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 быў падключаны. Наступнае перападключэнне зменіць хаця б адзін з іх, і нататка ператворыць наступны збой у кароткае параўнанне замест новага расследавання.