VPN Windows-та жергілікті LAN-ды бөгейді: маршрут па, әлде клиент саясаты ма?

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

Кез келген команда алдында үш сұрақ

Бірінші: жергілікті префикс үшін жазба бар ма, және ол физикалық адаптерге меңзей ме? Екінші: қосылу кезінде клиент gateway-ден жергілікті желіге рұқсат немесе тыйым ала ма? Үшінші: сізге тек LAN-ға шығатын қатынау керек пе, әлде интернеттегі бірдеңе де сіздің машинаңызда жұмыс істейтін қызметке жетуі керек пе?

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

Бірінші сұрақ: маршрут, сүзгі ме, әлде ат

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

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

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

Мекенжай бойынша және ат бойынша бөлек сынаңыз. Егер ping 192.168.1.50 жауап берсе, ал net view 192.168.1.50 бермесе, маршруттау кестесі ешқашан мәселе болған емес: туннель resolver-ді өзгертті және жергілікті ат енді шешілмейді. Ол үшін маршрут қосу — бос жұмыс.

Екінші сұрақ: gateway жергілікті LAN-ға қатынауға рұқсат бере ме?

Коммерциялық клиент тек маршруттарды орнатпайды. Ол қосылу кезінде саясат алады, және бұл саясат жергілікті желіге айқын рұқсатты қамтуы мүмкін. Cisco IPsec орналастыруларында топтық саясат split-tunneling параметрін және жергілікті LAN-ға қатынаудың бөлек жалаушасын алып жүреді; клиенттегі құсбелгі — gateway қабылдамауы мүмкін сұрау. AnyConnect-те профиль split-тің қосу және алып тастау тізімдерін және сол рұқсатты басқарады. Windows RRAS-та баламалары — профильдегі әдепкі gateway опциясы және сервер беретін статикалық маршруттар.

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

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

Үшінші сұрақ: сізге қай бағыт керек?

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

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 маскасы бар хост мекенжайы. Subnet маршруты үшін желі мекенжайын, ал бір хост үшін хост маскасын қолданыңыз.

Кіретін трафик басқаша. Сол машинадағы VNC немесе SSH сервері кіретін қосылымға жауаптар VPN gateway-і арқылы шығып, ешқашан қайтпағанда қолжетімсіз болады. Маршруттарға тиіспес бұрын қызметтің не тыңдайтынын тексеріңіз:

netstat -ano | findstr :5900

Бір нақты мекенжайға байланған тыңдаушы екінші интерфейсте жауап бермейді. Оны барлық интерфейстерге байлау — саналы шешім, ол сіз сенетін желімен шектелген firewall ережесімен бірге қабылданады. Тек содан кейін ғана маршрутты жөндеу қайту жолын қалпына келтіреді.

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

Тағы бір жиі қадам — IPv4 кеңейтілген қасиеттерінде «Қашықтағы желіде әдепкі gateway-ді пайдалану» белгісін алу. Бұл интернет трафигін жергілікті ұстайды, бірақ бірден екі нәрсе жасайды: VPN әдепкі жол болудан қалады, және клиент қашықтағы желі үшін маршруттарды, multicast-ты қоса, алуды тоқтатады. Белгіні алсаңыз, сервер әр клиентке қажет нақты қашықтағы префикстерді итермесе, қашықтағы LAN жоғалады.

Бұл асимметрия жұмыс ретін анықтайды. Егер қашықтағы жақ толық қолжетімді болып қалуы керек болса, қашықтағы subnet-терді серверден итеріңіз және жергілікті әдепкіге тиіспеңіз. Серверді өзгерте алмасаңыз, туннель берген мекенжай арқылы қашықтағы префикске тұрақты маршрут қосыңыз, және route print арқылы префикстің VPN интерфейсіне, ал әдепкінің әлі де физикалық gateway-ге меңзейтінін тексеріңіз.

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