VPN-ն արգելափակում է տեղական LAN-ը Windows-ում. երթուղի, թե հաճախորդի քաղաքականություն
Windows-ում տեղական LAN-ի հասանելիությունը կտրվում է երկու տարբեր պատճառով՝ բացակայող երթուղի, կամ gateway-ի քաղաքականություն, որը գցում է ենթացանցը։ Երեք ստուգում ասում են՝ որը։
Ձեր սեփական սեղանին դրված տպիչը, NAS-ը կամ մշակման մեքենան դադարում են պատասխանել այն պահին, երբ աշխատանքային VPN-ը միանում է։ Երբեմն մեկ երթուղու հրամանը շտկում է դա վայրկյանների ընթացքում. երբեմն նույն երթուղին ճիշտ է, և փաթեթները դեռ անհետանում են, ինչը նշանակում է, որ տեսնում եք այլ խնդիր՝ նման ախտանիշով։ Որոշումը հանգում է երեք հարցի, և դրանք սխալ հերթականությամբ տալը պատճառն է, որ մարդիկ ամբողջ երեկոն անցկացնում են երթուղիներ ջնջելով ու նորից ավելացնելով։
Երեք հարց ցանկացած հրամանից առաջ
Առաջին՝ կա՞ գրառում տեղական նախածանցի համար, և արդյոք այն ուղղված է ֆիզիկական ադապտերին Երկրորդ՝ միանալիս հաճախորդը gateway-ից ստանու՞մ է տեղական ցանցի թույլտվություն, թե մերժում Երրորդ՝ ձեզ պետք է միայն ելքային հասանելիություն դեպի LAN, թե՞ ինտերնետում ինչ-որ բան նույնպես պետք է հասնի ձեր մեքենայում աշխատող ծառայությանը
Առաջին հարցը բաժանում է երթուղային խափանումը զտման խափանումից։ Երկրորդն ասում է՝ արդյոք երթուղու շտկումն ընդհանրապես թույլատրված է աշխատել։ Երրորդը փոխում է վերանորոգումը. երթուղին շտկում է ելքային երթևեկությունը, մինչդեռ անհասանելի մուտքային ծառայությունը սովորաբար լսողի կապակցման և վերադարձի ուղու խնդիր է, որը երթուղին ավելի է վատացնում։
| What you see | What it points at |
|---|---|
| No local prefix in the table | Missing route |
| Correct prefix, no reply | Client filter or gateway policy |
| Works by IP, fails by name | Resolver changed by the tunnel |
| Inbound service dies, outbound fine | Return path or listener binding |
Հարց առաջին՝ երթուղի, զտիչ, թե անուն
Կարդացեք աղյուսակը, նախքան դրան որևէ բան ավելացնելը։ Ինտերֆեյսի ինդեքսը կարևոր է, որովհետև ներքևի յուրաքանչյուր երթուղու հրաման խարսխված է դրան.
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-ը՝ ոչ, ապա երթուղային աղյուսակը երբեք խնդիր չի եղել. թունելը փոխել է լուծիչը, և տեղական անունն այլևս չի լուծվում։ Դրա համար երթուղի ավելացնելը վատնված աշխատանք է։
Հարց երկրորդ՝ թույլատրու՞մ է gateway-ը տեղական LAN-ի հասանելիությունը
Առևտրային հաճախորդը տեղադրում է ավելին, քան երթուղիները։ Այն միանալիս ստանում է քաղաքականություն, և այդ քաղաքականությունը կարող է պարունակել տեղական ցանցի բացահայտ թույլտվություն։ Cisco IPsec տեղակայումներում խմբային քաղաքականությունը կրում է split-tunneling-ի կարգավորումը և առանձին դրոշակ՝ տեղական LAN-ի հասանելիության համար. հաճախորդի վանդակը հարցում է, որը gateway-ը կարող է մերժել։ AnyConnect-ում պրոֆիլը կառավարում է split-ի ներառման և բացառման ցանկերը և նույն թույլտվությունը։ Windows RRAS-ում համարժեքներն են պրոֿիլի լռելյայն gateway-ի ընտրանքը և սերվերի կողմից տրված ստատիկ երթուղիները։
Երբ դրոշակը անջատված է, փաստաթղթավորված վարքագիծն այն է, որ հաճախորդը արգելափակում է երթևեկությունը դեպի ուղղակիորեն միացված ենթացանցը, թեև գոյություն ունի վավեր, ավելի կոնկրետ երթուղի։ Սա է նաև պատճառը, որ հաճախորդին չպատկանող երթուղիները կարող են անհետանալ ավելացնելուց վայրկյաններ անց. հաճախորդը վերակառուցում է այն վիճակը, որն իրեն ասել են կառուցել, և չի պայքարում ձեր դեմ։
Հաճախորդի մատյանը գրանցում է որոշումը միանալիս, և այն կարդալն ավելի արագ է, քան մեքենայի վրա ցանկացած փորձ։ Եթե մատյանն ասում է, որ տեղական հասանելիությունը արգելափակված է, կանգ առեք. հրամանի տողի ոչ մի շտկում չի գոյատևում դրանից հետո, և մնում են միայն քաղաքականության փոփոխությունը, ռեսուրսին թունելով հասնելը, կամ հաճախորդը վիրտուալ մեքենայի մեջ պահելը և հյուրընկալողին տեղական ցանցում թողնելը։
Հարց երրորդ՝ ո՞ր ուղղությունն է ձեզ հարկավոր
Ելքային երթևեկությունը դեպի մոտակա սարք երթուղավորման հարց է։ Ուղղեք 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 դիմակով հյուրընկալողի հասցե։ Ցանցի հասցեն օգտագործեք ենթացանցի երթուղու համար, իսկ հյուրընկալողի դիմակը՝ մեկ հյուրընկալողի։
Մուտքայինը տարբեր է։ Նույն մեքենայի VNC կամ SSH սերվերը դառնում է անհասանելի, երբ մուտքային կապի պատասխանները դուրս են գալիս VPN gateway-ով և երբեք չեն վերադառնում։ Ստուգեք, թե ինչի է լսում ծառայությունը, նախքան երթուղիներին դիպչելը.
netstat -ano | findstr :5900Մեկ կոնկրետ հասցեին կապված լսողը չի պատասխանի մյուս ինտերֆեյսում։ Այն բոլոր ինտերֆեյսերին կապելը գիտակցված որոշում է՝ կայացված ձեր վստահած ցանցով սահմանափակված firewall-ի կանոնի հետ միասին։ Միայն դրանից հետո է երթուղու վերանորոգումը վերականգնում վերադարձի ուղին։
Կիրառեք ամենափոքր համապատասխան փոփոխությունը
Մյուս սովորական քայլը IPv4-ի լրացուցիչ հատկություններում «Օգտագործել լռելյայն gateway-ը հեռավոր ցանցում»-ի նշումը հանելն է։ Սա ինտերնետային երթևեկությունը պահում է տեղական, բայց միաժամանակ երկու բան է անում. VPN-ը դադարում է լինել լռելյայն ուղին, և հաճախորդը դադարում է ստանալ հեռավոր ցանցի երթուղիներ, ներառյալ multicast-ը։ Հանեք նշումը, և հեռավոր LAN-ը կանհետանա, եթե սերվերը չմղի յուրաքանչյուր հաճախորդի անհրաժեշտ կոնկրետ հեռավոր նախածանցերը։
Այդ ասիմետրիան որոշում է աշխատանքի հերթականությունը։ Եթե հեռավոր կողմը պետք է մնա ամբողջությամբ հասանելի, սերվերից մղեք հեռավոր ենթացանցերը և տեղական լռելյայնը թողեք հանգիստ։ Եթե չեք կարող փոխել սերվերը, ավելացրեք մշտական երթուղի դեպի հեռավոր նախածանցը թունելի տված հասցեով, և route print-ով ստուգեք, որ նախածանցը ցույց է տալիս VPN ինտերֆեյսին, մինչ լռելյայնը դեռ ցույց է տալիս ֆիզիկական gateway-ին։
Ապա հաստատեք, որ վերանորոգումը գոյատևում է վերամիացումից, որովհետև ոչ մշտական երթուղիները մահանում են ադապտերի հետ, և յուրաքանչյուր միացումից հետո աշխատող սկրիպտը նրանց ազնիվ տեղն է։ Նույն նստաշրջանում փորձարկեք մեկ տեղական սարք և մեկ հեռավոր ռեսուրս, անջատեք, նորից միացեք և նորից փորձարկեք։ Եթե տեղական սարքը դեռ ձախողվում է, մինչ երթուղին ճիշտ է թվում, վերադարձեք երկրորդ հարցին. հաճախորդը զտում է, և պատասխանը քաղաքականության փոփոխությունն է, ոչ թե երկրորդ մրցակից երթուղին։