Windows VPN-ում ինտերնետ չկա՞. Հասցեների պահոցն է կասկածելին

Windows-ը թունելը ցույց է տալիս որպես միացված և պիտակավորում է որպես Ինտերնետ հասանելիություն չկա, ինչը մարդիկ ընկալում են որպես Windows-ի առանձնահատկություն։ Սա հայտարարություն է այն մասին, թե ինչ է ստացել հաճախորդը՝ օգտագործելի լռելյայն դարպաս չկա, աշխատող լուծիչ չկա, կամ թունելի ներսի հասցեների համար վերադարձի ուղի չկա։ Երբ սերվերը Windows Incoming Connection-ն է, մեկ կարգավորում բացատրում է նման զեկույցների մեծ մասը։ Պիտակը ախտորոշում չէ, բայց որոնումը նեղացնում է երեք տեղի։

Կարդացեք վարձույթը նախքան այն փոխելը

Գործարկեք ipconfig /all հաճախորդի վրա և գտեք VPN ադապտերը գրառումների մեջ։ Նրա թվարկած հասցեն, լռելյայն դարպասը և DNS սերվերը ձեզ անհրաժեշտ փաստերն են, և հաճախ տարբերվում են նրանից, ինչ ադմինիստրատորը ենթադրում է, թե տրամադրվել է։

Երեք օրինակ համապատասխանում են երեք խափանումների։ 169.254.0.0/16-ում հասցեն նշանակում է, որ հաճախորդը ընդհանրապես ոչինչ չի ստացել և ինքն իրեն տվել է հղում-լոկալ հասցե։ Առանց դարպասի հավանական հասցեն նշանակում է, որ պահոցը մատուցվել է առանց այն ընտրանքի, որը հաճախորդին տալիս է լռելյայն երթուղի։ Ամբողջական վարձույթը, որը դեռ ոչ մի տեղ չի հասնում, մատնանշում է սերվերի կողմի փոխանցմանը կամ թարգմանությանը։

Գրեք արժեքները նախքան սերվերին դիպչելը։ Հաջորդ քայլը դրանք համեմատում է այն տիրույթի հետ, որը սերվերը կարծում է, թե բաժանում է, և հիշողությունը վարձույթի վատ փոխարինող է։

Ինչու ավտոմատ նշանակումը կարող է թողնել առանց դարպասի

Incoming Connections գրառումն ունի իր սեփական IPv4 հատկությունները՝ առանձին ֆիզիկական ադապտերից։ Այնտեղի լռելյայնը առաջարկում է հասցեներ նշանակել ավտոմատ, ինչը հենվում է կապի ներկառուցված բաշխիչի վրա՝ հասցե, դիմակ, դարպաս և DNS տրամադրելու համար։

Առանձին աշխատանքային կայանում այդ բաշխիչը տիրույթ չունի, որտեղից քաշի, եթե մեքենայի վրա այլ բան մեկը չտրամադրի, ուստի հաճախորդը կարող է հայտնվել հղում-լոկալ հասցեով կամ հասցեով, բայց առանց դարպասի։ Կապը երևում է հաստատված, որովհետև հղումը բարձրացել է, մինչդեռ դրա հետևի կարգավորումը թերի է։

Ահա թե ինչու նշված տիրույթին անցնելը շտկում է այս զեկույցներից շատերը։ Դուք դադարում եք ծառայությունից, որը գուցե չի աշխատում, վարձույթ հորինել խնդրել և սկսում եք ինքներդ հայտարարել վարձույթը։

Նույն շփոթությունը հայտնվում է, երբ ինչ-որ մեկը ակնկալում է, որ LAN երթուղիչի DHCP սերվերը կսպասարկի թունելի հաճախորդներին։ Հեռարձակման հայտնաբերումը չի անցնում երթուղավորված թունելով, ուստի այդ սերվերը երբեք չի տեսնում հարցումը։ Հակառակը ենթադրելը ամենատարածված պատճառն է, որ պահոցին մեղադրում են մի հաճախորդի համար, որը երբեք ոչինչ չի հարցրել նրանից։

Սահմանեք բացահայտ տիրույթ, որը սերվերը կարող է երթուղավորել

Ընտրեք փոքր բլոկ ենթացանցի ներսում, որին սերվերը կարող է հասնել՝ LAN երթուղիչի բաժանած տիրույթից դուրս և ցանցի ցանկացած այլ պահոցից դուրս։ Եթե սերվերը նստած է 172.20.10.0/24-ի վրա, իսկ երթուղիչը պահում է 172.20.10.1-ը, ապա այդ ենթացանցի վերևի մասում կարճ բլոկը, ասենք 172.20.10.201-ից 172.20.10.209, թունելի վարձույթները հեռու է պահում երթուղիչի արդեն կառավարած բաշխումից։

Մուտքագրեք այն Incoming Connection-ի IPv4 հատկություններում, նորից միացրեք հաճախորդը և նորից կարդացեք ադապտերը նախքան որևէ այլ բան փոխելը։ Երկրորդ ընթերցումն է ասում, թե պահոցն էր խափանումը, թե ընդամենը մեկը մի քանիսից։

Այս հրամանները տպում են ստացված կոնֆիգուրացիան և այն երթուղիները, որոնք հաճախորդն այժմ ունի՝

ipconfig /all
route print -4
Get-NetIPConfiguration -InterfaceAlias \"Incoming Connection\"

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

Հասցեն ինտերնետի ուղի չէ

Վարձույթ ստանալը միայն փաթեթները տեղափոխում է հաճախորդից սերվեր։ Ինտերնետ հասանելիության համար սերվերը պետք է փոխանցի այդ փաթեթները և թարգմանի դրանք դեպի իր սեփական uplink-ը, և դա առանձին կոնֆիգուրացիա է՝ իր սեփական խափանման ձևերով։

Internet Connection Sharing-ը կարճ ճանապարհն է։ Այն ինտերնետին ուղղված ադապտերը դարձնում է ընդհանուր դարպաս և վարում է իր սեփական հասցեավորումը, ինչը կարող է վերագրել այդ ադապտերի հասցեն և թողնել գոյություն ունեցող NAT կանոնը՝ ուղղված մի արժեքի, որն այլևս չկա։ Գրանցեք սկզբնական կարգավորումները նախքան այն միացնելը։

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

Նախ բացառեք արտաքին ուղին

Ոչ մի պահոց չի օգնի, եթե թունելը երբեք չձևավորվի։ Արձանագրությունը որոշում է, թե ինչ պետք է կրի ուղին. PPTP-ն ուզում է TCP 1723 և GRE, որը IP արձանագրություն 47 է, ոչ թե պորտ. L2TP/IPsec-ը ուզում է UDP 1701 գումարած 500 և 4500. SSTP-ն ուզում է TCP 443։

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

Փորձարկեք նույն LAN-ից և հեռավոր ցանցից։ Եթե LAN-ի փորձը աշխատում է, իսկ հեռավորն երբեք չի հասնում նույնականացմանը, արտաքին ուղին է խնդիրը։ Եթե երկուսն էլ նույնականացվում են, և միայն հեռավոր հաճախորդն ինտերնետ չունի, վերադարձեք պահոցին և ելքին։