Թունելը միանում է, դուք բացում եք ադապտերի մանրամասները և դիմակը ցույց է տալիս 255.255.255.255։ Համեմատած գրասենյակի LAN-ի 255.255.255.0-ի հետ այն կարծես կոտրված է, և սխալը սովորաբար սկսվում է հենց այնտեղից։ Կետ-կետ կապում հոսթի դիմակը տեղական ծայրի ճիշտ նկարագրությունն է, իսկ հեռավոր ցանցերը գալիս են որպես երթուղիներ, ոչ թե որպես միացված ենթացանց։ Ստորև ներկայացված ընթացակարգը բաժանում է երկու հարցերը, որպեսզի չվերակառուցեք աշխատող DHCP տիրույթը միայն ցուցադրվող արժեքը շտկելու համար։

Կետ-կետ կապը Ethernet հատված չէ

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

Այդ մոդելի հասցեային բանակցությունը սահմանված է RFC 1332-ում, որը նկարագրում է, թե ինչպես են երկու ծայրերը համաձայնում իրենց հասցեների շուրջ։ Սակայն այն չի հանձնում գրասենյակի LAN-ը հաճախորդին որպես ուղղակիորեն միացված ցանց։ Հաճախորդը սովորում է, թե որտեղ է գրասենյակը՝ կապի միջով երթուղիներ տեղադրելով, և հենց այդ երթուղիներն են իրականում որոշում հասանելիությունը։

Սա չի նշանակում, որ ձեր տեսած ամեն դիմակ ճիշտ է։ Սխալ կարգավորված հաճախորդը նույնպես կարող է տարօրինակ հասցեավորում ստեղծել։ Խնդիրն ավելի նեղ է. այս տեսակի ադապտերում հոսթի դիմակը սպասելի է, ուստի ինքնին վթարի ապացույց չէ։

Քայլ 1. հաստատեք ինտերֆեյսի մոդելը

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

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

Երրորդ հրամանն է, որ լուծում է վեճերի մեծ մասը։ Ցածր առավելագույն փոխանցման միավորը բնորոշ է փաթեթավորված կապին, մինչդեռ Ethernet-ին նման արժեքը հուշում է վիրտուալ ադապտերի այլ մոդել։ Եթե նկարագրությունը նշում է PPP կամ RAS դրայվեր, և նախածանցը 32 է, դուք տեսնում եք հենց վերը նկարագրված ձևավորումը և կարող եք դադարել անհանգստանալ դիմակի համար։

ObservationWhat it meansReasonable next step
/32 on a PPP or RAS adapterPoint-to-point endpoint addressingLook at routes, not the mask
/32 on an Ethernet-like adapterClient chose host addressing deliberatelyConfirm against the server's push policy
Mask differs from the office LANUsually irrelevant to reachabilityTest the destination instead

Քայլ 2. կարդացեք ձախողվող նպատակակետի երթուղին

Հասանելիությունը որոշվում է յուրաքանչյուր նպատակակետի համար, և մեկ միացված ինտերֆեյս ոչինչ չի ասում դրա մասին։ Ուղղակի հարցրեք երթուղիների աղյուսակին այն հասցեի մասին, որին օգտատերը իրականում փորձում է հասնել։

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute ուղղակի պատասխանն է. այն նշում է ինտերֆեյսը և աղբյուրի հասցեն, որը համակարգը կօգտագործեր այդ նպատակակետի համար։ Եթե այն վերադարձնում է թունելը, ապա այդ հոսթի երթևեկությունն անցնում է թունելով, և դիմակը երբեք խնդիր չի եղել։

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

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

Քայլ 3. առանձնացրեք անունների լուծումը ծառայության հասանելիությունից

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

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Հաջողված հասցեի թեստը ձախողված անվան թեստի հետ միասին տեղայնացնում է խնդիրը լուծման մեջ, իսկ երկրորդ հրամանը ցույց է տալիս՝ թունելի ինտերֆեյսը ընդհանրապես սերվեր ստացե՞լ է։ Շատ հաճախորդներ DNS-ը հրում են որպես թունելի կարգավորման մաս, և պրոֆիլը, որն անտեսում է այդ հրող ընտրանքները, մեքենային կթողնի լուծիչ, որը չի տեսնում մասնավոր գոտին։

Աշխատող հասցեն մի ընդունեք որպես մշտական շտկում։ Հասցեով միանալը շրջանցում է անունների լուծումը և կարող է թուլացնել սերվերի ինքնության ստուգումը, որը ծրագիրը հակառակ դեպքում կկատարեր։ Սա անվտանգության անկում է՝ քողարկված որպես ժամանակավոր լուծում։ Օգտագործեք այն վթարը տեղայնացնելու համար, ապա շտկեք լուծումը։

Վերադարձ. մի վերակառուցեք DHCP-ն ցուցադրվող արժեքի պատճառով

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

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Գործարկեք այս երեքը ցանկացած նպատակային փոփոխությունից հետո և համեմատեք նախորդ գործարկման հետ։ Օգտակար արդյունքը ռեսուրս տանող փաստաթղթավորված ուղին է, ոչ թե ադապտեր, որի դիմակը նման է գրասենյակի LAN-ին։

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

Առնչվող հոդվածներ