Տեղական ցանցն անհասանելի է VPN-ի միացված վիճակում. չորս ստուգում

Թունելը բարձրանում է, ինտրանեթը հայտնվում է, և տպիչը դադարում է պատասխանել։ LAN-ում ոչինչ չի խափանվել. հաճախորդը փոխել է, թե որ ուղին է օգտագործում այն հասցեների համար, որոնք այլևս տեղական չի համարում։ Անցեք ստորև բերված չորս ստուգումները հերթականությամբ և կանգ առեք, երբ մեկը ցույց տա կոնկրետ անհամապատասխանություն, որովհետև նույն ախտանիշն ունի չորս տարածված պատճառ, և դրանցից միայն մեկն է շտկվում 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 ցանցով հաճախորդի վրա օգտագործում է միացված երթուղին. եթե այդ հասցեն ձախողվում է, նայեք սարքին, անջատիչին կամ հաճախորդի firewall-ին՝ VPN-ի փոխարեն։

Այն դեպքը, որը մոլորեցնում է մարդկանց, տեղական սերվերի հրապարակային հասցեն է։ LAN-ի ներսից երթուղիչի WAN հասցեին հասնելը և հետ վերադառնալը պահանջում է hairpin NAT, և շատ երթուղիչներ պարզապես չեն իրականացնում այն port forwarding-ի համար։ Փորձարկեք մասնավոր հասցեն հրապարակայինի կողքին։ Եթե մասնավոր հասցեն աշխատում է, իսկ հրապարակայինը՝ ոչ, ապա VPN-ը միայն մերկացրել է NAT-ի սահմանափակում, որը եղել է արդեն իսկ։

Հոսթանունը սա ավելի է վատացնում։ Եթե տեղական անունը այժմ լուծվում է հրապարակային հասցեի, հաճախորդը կշարունակի փորձել այն ուղին, որը չի կարող հետ վերադառնալ։ Փորձարկման համար օգտագործեք մասնավոր հասցեն, ապա ուղղեք անունը, այլ ոչ թե ավելացնեք ևս մեկ port forwarding։

Երրորդ՝ տեսեք, թե ով է հիմա պատասխանում անուններին

Կորպորատիվ լուծիչը գիտի ինտրանեթը և սովորաբար ոչինչ չգիտի NAS-ի հոսթանվի, տպիչի Bonjour անվան կամ երթուղիչի տեղական այլանունի մասին։ Երբ VPN-ը հրում է իր DNS սերվերները, այդ անունները դադարում են լուծվել, թեև դրանց հասցեները դեռ հասանելի են։ Հարցրեք անունը ուղղակիորեն և համեմատեք պատասխանը այն հասցեի հետ, որը գիտեք, որ սարքն ունի։

Linux-ում resolvectl query nas.local-ը ցույց է տալիս, թե որ լուծիչը պատասխանեց։ Windows-ում nslookup nas.local-ը նշում է սերվերը, իսկ ipconfig /all-ը ցույց է տալիս լուծիչների հերթականությունը։ Եթե տեղական վերջածանցն այժմ ղեկավարում է կորպորատիվ լուծիչը, ապա կա՛մ այդ վերջածանցը հետ ուղղեք տեղական լուծիչին, կա՛մ սարքի համար օգտագործեք IP հասցեն։

Հայտնաբերումը առանձին շերտ է։ mDNS-ը և broadcast-ը չեն անցնում երթուղավորված թունելով, ուստի սարքը կարող է հասանելի լինել հասցեով, մինչ անունը մնում է անտեսանելի։ Reflector-ը կամ տեղական DNS գրառումը լուծում են դա. երթուղին՝ ոչ։

Չորրորդ՝ ստուգեք, թե արդյոք մյուս մեքենան նույնպես VPN-ի վրա է

Երբ այն մեքենան, որին ուզում եք հասնել, նույնպես VPN-հաճախորդ է աշխատեցնում, ձեր սեսիան կարող է ժամանել, մինչ նրա պատասխանը դուրս է գալիս մյուս թունելով։ Դրանից ստացվում է կապ, որը հաստատվում է և հետո կանգ է առնում, կամ RDP և SSH փորձ, որը ձեր կողմում առանց սխալի ժամկետանց է լինում։ Ստուգեք մյուս հոսթի երթուղային աղյուսակը և նրա լռելյայն ուղին նախքան ձեր հաճախորդին մեղադրելը։

Ստուգեք նաև այն հասցեն, որի վրա լսում է ծառայությունը։ Միայն թունելի հասցեին կապված listener-ը ընդունում է կապերը VPN-ից և մերժում դրանք LAN-ից, նույնիսկ երբ երթուղավորումը կատարյալ է։ Դա ծառայության կազմաձև է, ոչ թե ցանցային ուղի, և սովորական է այն կառավարման ինտերֆեյսների վրա, որոնք կողպվել են VPN հասցեին։

Պահպանեք կառավարման ուղի, որը կախված չէ թունելից. ստատիկ երթուղի, որը նշում է ձեր աղբյուրի ցանցը, LAN-ին միացված մեկ այլ ինտերֆեյս, կամ վահանակ, որն ամբողջովին շրջանցում է թունելը։ Այդ ուղին սեսիայի կտրվելուց հետո նախագծելը շատ ավելի դժվար է, քան այն հաջորդ միացումից առաջ ավելացնելը։

Կիրառեք այն շտկումը, որը համապատասխանում է ձախողված ստուգմանը

Եթե երթուղային աղյուսակը ցույց տվեց կիսալռելյայն զավթում, ընտրեք բաժանված թունել, երբ քաղաքականությունը թույլ է տալիս, և ամրացված տեղական երթուղի, երբ՝ ոչ։ Եթե հասցեն հրապարակային է, փոխեք փորձարկումը և անունը մասնավոր հասցեի։ Եթե լուծիչը փոխվել է, ամրագրեք տեղական վերջածանցը կամ օգտագործեք հասցեն։ Եթե մյուս հոսթը թունելի տակ է, շտկեք նրա վերադարձի ուղին կամ listener-ի կապումը։

Փոխեք մեկ բան, ապա կրկնեք նույն ստուգումը։ Սխալ ենթացանցի համար ավելացված երթուղին, լուծիչի վերջածանցի տառասխալը և այնպիսի ինտերֆեյսի վրա ամրացված երթուղին, որը նոր համար է ստանում, բոլորը նման են սկզբնական խափանմանը։ Կրկնությունն է, որ տարբերում է շտկումը պատահականությունից։

Գրի առեք այն երթուղին, հասցեն և լուծիչը, որոնք աշխատել են VPN-ի միացված վիճակում։ Հաջորդ վերամիացումը կփոխի դրանցից առնվազն մեկը, և գրառումը հաջորդ ընդհատումը կդարձնի կարճ համեմատություն՝ նոր հետաքննության փոխարեն։