Երթուղին մերժվել է հոսթի բիտերի պատճառով? Գտեք նախատեսված նախածանցը

Ձեր երթուղու տողը վերադառնում է մերժված, և գտնված խորհուրդն ասում է միացնել IP փոխանցումը։ Այս երկու բաները խնդրի տարբեր փուլերում են։ Փոխանցումը որոշում է՝ արդյոք հոսթը կարող է փաթեթներ տեղափոխել ինտերֆեյսների միջև, բայց կարծիք չունի՝ ձեր գրած նպատակակետը վավեր ցանց է, թե ոչ։ Նախ ուղղեք նախածանցը, որովհետև փոխանցումը չի փրկի հակասող հասցեն ու մասկը։

Ինչի՞ց է իրականում բողոքում վերլուծիչը

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

Գործիքները տարբեր կերպ են վարվում այդ հակասության հետ։ Խիստ վերլուծիչները մերժում են տողը և նշում հոսթի բիտերը։ Մեղմ վերլուծիչները մասկավորում են հասցեն և տեղադրում ինչ-որ բան, որը դուք չեք խնդրել, ինչն ավելի վատ է, որովհետև կարգավորումն այժմ երթուղավորում է մի տիրույթ, որը երբեք չեք նախատեսել։ Python-ի ipaddress մոդուլը ընտրությունը ցույց է տալիս ուղղակիորեն. խիստ ցանցային վերլուծությունը սխալ է առաջացնում, իսկ strict=False-ը մասկավորում է հոսթի բիտերը։ Ձեր հաճախորդը կարող է լինել խիստ, մեղմ կամ տարբերակների միջև անհամապատասխան, ուստի կարդացեք հաղորդագրությունը, այլ ոչ թե վստահեք սովորույթին։

Անցեք օրինակը ձեռքով

Վերցրեք թունել, որը պետք է հասնի 172.20.130.0-ին /20 մասկով։ /20-ը չորս բիտ է վերցնում երրորդ օկտետից, ուստի այդ օկտետը հաշվվում է միայն 16-ի քայլերով՝ 0, 16, 32 և այդպես շարունակ մինչև 240։ 130 արժեքը ընկնում է 128-ի և 143-ի միջև, ինչը նշանակում է, որ ընդգրկող ցանցը սկսվում է 172.20.128.0-ից, ոչ թե 172.20.130.0-ից՝ վերջին օկտետը զրոյացված։

Գրավոր ձևով բլոկը ձգվում է 172.20.128.0-ից մինչև 172.20.143.255 և պարունակում է 4,096 հասցե։ Նույն արժեքները ոչ խիստ վերլուծիչին տալը ցույց է տալիս այն փոխարինումը, որը նա կաներ ձեր փոխարեն։

$ python3 -c "import ipaddress; n=ipaddress.ip_network('172.20.130.0/20', strict=False); print(n, n.num_addresses)"
172.20.128.0/20 4096

Որոշեք, թե որ նպատակակետն էիք իրականում նկատի ունեցել

Մերժված տողը սովորաբար թաքցնում է երեք մտադրություններից մեկը, և ընտրել կարող եք միայն դուք։ Եթե թունելին պետք է ամբողջ բլոկը, գրեք 172.20.128.0/20՝ կանոնական ցանցային հասցեն։ Եթե թունելին պետք է միայն 130 սեգմենտը, մասկը սխալ էր, և 172.20.130.0/24-ը ազնիվ ձևն է։ Եթե նպատակը մեկ մեքենա է, IPv4 հոսթի երթուղին /32 է և ոչ մի մասկային թվաբանություն ներգրավված չէ։

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

Ինչու փոխանցումը երբեք լուծում չէր

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

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

Ստուգեք տեղադրված երթուղին և այն ուղին, որը նա հաղթում է

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

Հարցրեք և՛ անդամ հասցե, և՛ մեկը բլոկից դուրս, որպեսզի համեմատությունը իմաստալից լինի, այլ ոչ թե մեկ հանգստացնող տող։

ip -4 route show 172.20.128.0/20
ip -4 route get 172.20.140.10
ip -4 route get 172.20.200.10

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