Ինչու route -interface-ը չի հասնում կապից դուրս գտնվող հոսթին
Ինտերֆեյսի դրոշը macOS-ին ասում է, որ նպատակակետը լարի վրա է։ Տեղական կապից այն կողմ գտնվող ամեն ինչի համար պետք է հասանելի դարպաս, և թունելը դեռ կարող է արգելել այն։
route-ը ընդունում է Wi-Fi ինտերֆեյսի անունը, դուրս է գալիս առանց բողոքի, և հոսթը մնում է անհասանելի։ Ոչինչ չի վնասվել. երթուղու հարաբերությունը պարզապես սխալ է՝ ինտերֆեյսի դրոշը ասում է, թե նպատակակետը որ կապի վրա է, ոչ թե որ երթուղիչը պետք է ստանա երթևեկությունը այլ տեղ գտնվող նպատակակետի համար։ Հրամանը հաջողվում է, որովհետև այն շարահյուսորեն վավեր է, ոչ թե որովհետև նկարագրում է աշխատող ուղի։
Այդ տարբերությունը որոշում է՝ VPN-ի կողքի երթուղու բացառությունը կաշխատի, թե միայն հավաստի կթվա։
Ինտերֆեյսը ելքն է, հաջորդ ցատկը՝ հանձնումը
192.168.50.20 հասցեով Mac-ի և 192.168.50.1-ում երթուղիչի դեպքում նույն կապի վրա գտնվող մեկ այլ մեքենա ուղղակիորեն հասանելի է։ Շրջանակը հասցեագրվում է այդ մեքենային և դրվում լարի վրա։ Ոչ մի երթուղիչ չի մասնակցում, և ինտերֆեյսով սահմանափակված երթուղին հենց դա է արտահայտում։ Փոխեք հեռավոր ծայրը մեկ այլ շենքում գտնվող հոսթով, և նույն հրամանը կորցնում է իմաստը։ Mac-ը լարի վրա դնելու երկրորդ շերտի հասցե չունի, ուստի ինտերֆեյսի դրոշը նկարագրելու բան չունի։
Կապից դուրս նպատակակետն այլ է։ Mac-ը չի կարող լարի վրա դնել շրջանակ, որը հասցեագրված է հոսթին, որին երկրորդ շերտում չի հասնում. այն փաթեթը հանձնում է երթուղիչի, որը կարող է։ Ուստի երթուղուն դարպաս է պետք, և դարպասն ինքը պետք է հասանելի լինի միացված կապի վրա։
Կապից դուրս նպատակակետի համար ինտերֆեյսի դրոշն օգտագործելը macOS-ին ասում է վերաբերվել այդ նպատակակետին այնպես, կարծես այն լարի վրա է։ Այնուհետև միջուկը չի կարողանում դրա համար երկրորդ շերտի հասցե լուծել, և փաթեթը դեն է նետվում՝ սխալի մեջ ոչ մի օգտակար բան չթողնելով։
Ինչ է իրականում պնդում ինտերֆեյսի դրոշը
Apple-ի երթուղիների տեղեկատուն սահմանում է ինտերֆեյսի ձևը միջնորդառանց ուղղակիորեն հասանելի նպատակակետերի համար։ Սա հայտարարություն է կապի մոդելի մասին, ոչ թե նախընտրություն, թե որ ադապտերն օգտագործել։ Wi-Fi-ով ինտերնետ հոսթին հասնելը դեռ պահանջում է երթուղիչ այդ Wi-Fi կապում, և երթուղին պետք է անվանի այն։
Ինտերֆեյսի շրջանակը առանձին ատրիբուտ է։ Այն երթուղին կապում է որոշակի ինտերֆեյսի հետ շրջանակի որոշումների համար, օրինակ՝ որ աղբյուրի հասցեն է գործում, բայց հասանելիություն չի ստեղծում այնպիսի նպատակակետի համար, որին ինտերֆեյսն ինքնուրույն չի հասնում։ Երկու ատրիբուտները տարբեր հարցերի պատասխանում են։
Այդ պատճառով հրամանը կարող է ընդունվել, հայտնվել աղյուսակում և դեռ ձախողվել։ Միջուկը չի վավերացնում ձեր մտադրությունը. այն գրանցում է, ինչ դուք պնդել եք, և պնդումն այն էր, որ նպատակակետը կապի վրա է։ Լուռ հաջողությունը, որին հաջորդում է լուռ դեն նետելը, սպասված արդյունքն է, ոչ թե սխալ։ Նախքան ցանցին մեղադրելը, պնդումը կրկին կարդացեք ինքներդ ձեզ։
Երթուղին, որ պետք է կապից դուրս նպատակակետին
LAN երթուղիչով 198.51.100.25-ի նման փաստաթղթային հասցեին հաստատված ուղու համար նախատեսված հարաբերությունը նպատակակետ, 192.168.50.1-ի հաջորդ ցատկ և այդ հաջորդ ցատկին հասնող LAN ինտերֆեյսն է։ Ինտերֆեյսը բխում է հաջորդ ցատկի որոնումից, այլ ոչ թե պարտադրվում է երթուղու հրամանով։
macOS-ում միայն կարդալու ստուգումը route -n get 198.51.100.25-ն է։ Կարդացեք դարպասի և ինտերֆեյսի տողերը միասին և ստուգեք, որ դարպասը հասցե է, որին Mac-ը իսկապես հասնում է։ Այլ ենթացանցում գտնվող դարպասը կամ վերջին ցանցային փոփոխությունից ի վեր անհետացածը ստեղծում է երթուղի, որը ճիշտ է թվում և ոչինչ չի փոխանցում։
Մի՛ կոշտ կոդավորեք en0-ը մշտական հրահանգում։ Ինտերֆեյսի անունները փոխվում են ադապտերների, դոկերի և VPN հաճախորդների հետ, և սխալը նշող երթուղին ձախողվում է այնպես, որ հեշտ է սխալ կարդալ որպես ավելի լայն ցանցային անսարքություն։
Կարդացեք ընթացիկ ընտրությունը նախքան այն փոխարինելը
Նախքան որևէ բան ավելացնելը, ուսումնասիրեք, թե համակարգն արդեն ինչ է ընտրել և ինչու։ Այդ ելքը ասում է՝ երթևեկությունը գնում է թունելով, LAN երթուղիչով, թե ոչ մի տեղ, և տալիս է բազային գիծ փոփոխությունից հետո համեմատելու համար։ Առանց դրա չեք կարող ասել՝ նոր երթուղին ուժի մեջ է մտել, թե ոչ։
Այնուհետև ստուգեք հասցեների ընտանիքը։ IPv4-ի համար ավելացված երթուղին ոչինչ չի անում IPv6 նպատակակետի համար, և երկու ընտանիքներին լուծվող ծառայությունը կարող է ընդհատումներով հասանելի թվալ։ Երթուղիների աղյուսակը և լուծիչը տարբեր հարցերի պատասխանում են, և երկուսն էլ պետք է համապատասխանեն նախատեսված ուղուն։
Վերջապես, հիշեք, որ երթուղին ընտրություն է, ոչ թե թույլտվություն։ Կառավարվող VPN պրոֆիլը կամ հաճախորդի զտիչը դեռ կարող է արգելել ուղիղ ուղին, նույնիսկ երբ աղյուսակը ցույց է տալիս դրան, ուստի փորձարկեք իրական հավելվածով, այլ ոչ թե ենթադրեք, որ հաջող աղյուսակային գրառումը ավարտում է հետաքննությունը։
Թունելները և քաղաքականությունը փոխում են ձևը
Կետ-կետ ինտերֆեյսները իրենց առանձին դեպքն են։ Թունելը կարող է երթուղի կրել առանց Ethernet ոճի դարպասի հասցեի, և դա ինքնաբերաբար սխալ չէ։ Կիրառեք ինտերֆեյսի իրական կապի մոդելը՝ Wi-Fi օրինակը ձեր տեսած յուրաքանչյուր աղյուսակային գրառման վրա տարածելու փոխարեն։
Փոփոխության հարցումների համար գրեք նպատակակետը, հաստատված ցանցային ուղին, ընթացիկ դարպասը և ինտերֆեյսը, և թե ով է ակնկալվում պահպանել բացառությունը։ Սեփականատերը կարևոր է, որովհետև հուշման մեջ մուտքագրված միանվագ երթուղին քաղաքականություն չէ, և հաջորդ վերամիացումը կջնջի այն։
Եթե պահանջը VPN-ի միացված ժամանակ այս հոսթին հասնելն է, ազնիվ պատասխանը սովորաբար տեղական երթուղիչով անցնող կոնկրետ հոսթի երթուղին է, որը տեղադրում է ինտերֆեյսին տիրապետող ցանցի կառավարիչը։ Եթե պահանջը ուղղակիորեն ամեն ինչի հասնելն է, ապա պահանջն ինքը քաղաքականության վերանայման կարիք ունի նախքան երթուղու հրամանի կարիքը։