VPN қосылып тұрғанда жергілікті желіге қол жетпей ме? Төрт тексеру

Туннель көтеріледі, интранет көрінеді, ал принтер жауап беруді тоқтатады. LAN желісінде ештеңе бұзылмаған; клиент өзі енді жергілікті деп санамайтын мекенжайлар үшін қандай жолды қолданатынын өзгерткен. Төмендегі төрт тексеруді ретімен орындап, біреуі нақты сәйкессіздік көрсеткенде тоқтаңыз, өйткені бір симптомның төрт таралған себебі бар және олардың тек біреуі VPN-нің баптауын өзгерту арқылы емделеді.

Алдымен клиент орнатқан маршрут кестесін қараңыз

VPN қосылып тұрғанда клиенттің маршрут кестесін ашыңыз. Linux жүйесінде ip route, Windows жүйесінде route print немесе Get-NetRoute, ал macOS жүйесінде netstat -rn қолданыңыз. Сіз туннель арқылы өтетін әдепкі маршрутты және физикалық әдепкі маршруттың не болғанын іздейсіз.

Толық туннельді клиент 0.0.0.0/0 маршрутын алмастырудың орнына көбіне екі жартылай әдепкі маршрут қосады: 0.0.0.0/1 және 128.0.0.0/1. Бастапқы әдепкі маршрут көрініп тұрады, бірақ әрбір іздеуден ұтылады, сондықтан кесте бүтін болып көрінгенімен, ішкі желіден тыс барлық трафик жылжиды. Егер 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.0/24 желісіндегі клиентте 192.168.1.40 мекенжайындағы принтер қосылған маршрутты пайдаланады; егер бұл мекенжай жұмыс істемесе, VPN емес, құрылғыны, коммутаторды немесе клиенттің firewall-ін қараңыз.

Адамдарды шатастыратын жағдай — жергілікті сервердің жария мекенжайы. LAN ішінен роутердің WAN мекенжайына шығып, қайта оралу үшін hairpin NAT қажет, ал көптеген роутер оны порттарды қайта бағыттау үшін мүлдем іске асырмайды. Жеке мекенжайды жария мекенжайдың жанында сынап көріңіз. Егер жеке мекенжай жұмыс істеп, жариясы істемесе, VPN бұрыннан бар NAT шектеуін ғана әшкереледі.

Хост атауы мұны одан әрі нашарлатады. Егер жергілікті ат енді жария мекенжайға шешілсе, клиент қайта орала алмайтын жолды сынауды жалғастырады. Сынақ үшін жеке мекенжайды қолданыңыз, содан кейін тағы бір порт қайта бағыттау қосудың орнына атауды түзетіңіз.

Үшіншіден, қазір аттарға кім жауап беріп жатқанын қараңыз

Корпоративтік шешуші интранетті біледі, ал NAS хост атауы, принтердің Bonjour атауы немесе роутердің жергілікті бүркеншік аты туралы әдетте ештеңе білмейді. VPN өз DNS серверлерін итеріп жібергенде, бұл аттар шешілуді тоқтатады, ал мекенжайлары әлі де қолжетімді. Атты тікелей сұрап, жауапты құрылғыда бар деп білетін мекенжаймен салыстырыңыз.

Linux жүйесінде resolvectl query nas.local қай шешушінің жауап бергенін көрсетеді. Windows жүйесінде nslookup nas.local серверді атайды, ал ipconfig /all шешушілердің ретін көрсетеді. Егер жергілікті жұрнақты енді корпоративтік шешуші өңдесе, сол жұрнақты жергілікті шешушіге қайта бағыттаңыз немесе құрылғы үшін IP мекенжайын қолданыңыз.

Анықтау — жеке қабат. mDNS пен broadcast маршрутталған туннельден өтпейді, сондықтан құрылғы мекенжайымен қолжетімді болып, аты көрінбей қалуы мүмкін. Мұны рефлектор немесе жергілікті DNS жазбасы шешеді; маршрут шешпейді.

Төртіншіден, екінші машина да VPN-де ме, соны тексеріңіз

Егер жеткіңіз келетін машина да VPN клиентін іске қосып жатса, сессияңыз келіп, ал оның жауабы басқа туннельден шығып кетуі мүмкін. Осыдан қосылым орнап, содан кейін тұрып қалады немесе RDP мен SSH әрекеті сіз жақта қатесіз уақыт шегінен шығады. Өз клиентіңізді кінәлаудың алдында екінші хосттың маршрут кестесін және оның әдепкі жолын тексеріңіз.

Сондай-ақ қызмет тыңдайтын мекенжайды тексеріңіз. Тек туннель мекенжайына байланған listener VPN-нен келетін қосылымдарды қабылдап, LAN-нан келгендерін қабылдамайды, тіпті маршруттау мінсіз болса да. Бұл қызметтің конфигурациясы, желілік жол емес, және VPN мекенжайына жабылған басқару интерфейстерінде жиі кездеседі.

Туннельге тәуелді емес басқару жолын ұстаңыз: бастауыш желіңізді атайтын статикалық маршрут, LAN-ға қосылған басқа интерфейс немесе туннельді толық айналып өтетін консоль. Сол жолды сессия үзілгеннен кейін жобалау келесі қосылымның алдында қосуға қарағанда әлдеқайда қиын.

Сәтсіз тексеруге сәйкес келетін жөндеуді қолданыңыз

Егер маршрут кестесі жартылай әдепкі маршруттың басып алынғанын көрсетсе, саясат рұқсат етсе бөлінген туннельді, рұқсат етпесе бекітілген жергілікті маршрутты таңдаңыз. Егер мекенжай жария болып шықса, сынақ пен атты жеке мекенжайға ауыстырыңыз. Егер шешуші қол ауыстырса, жергілікті жұрнақпен шектеліңіз немесе мекенжайды қолданыңыз. Егер екінші хост туннельде болса, оның қайту жолын немесе listener байлауын түзетіңіз.

Бір нәрсені өзгертіп, содан кейін сол тексеруді қайталаңыз. Қате ішкі желі үшін қосылған маршрут, қате жазылған шешуші жұрнағы және жаңа нөмір алатын интерфейске бекітілген маршрут — барлығы бастапқы ақауға ұқсайды. Жөндеуді кездейсоқтықтан ажырататын нәрсе — қайталау.

VPN қосылып тұрғанда жұмыс істеген маршрутты, мекенжайды және шешушіні жазып алыңыз. Келесі қайта қосылу олардың кемінде біреуін өзгертеді, ал жазба келесі үзілісті жаңа тергеудің орнына қысқа салыстыруға айналдырады.