Արդյո՞ք Pi-ի դարպասի հոսթի անունը ինքն իրեն թարմացնում է ստատիկ երթուղիները։

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

DNS պատասխանը և երթուղին տարբեր օբյեկտներ են

Ասենք՝ ձեր Pi-ն պատասխանում է vpn-gw.lan-ին և 10.44.0.0/16-ը փոխանցում թունել։ 192.168.30.0/24-ի հաճախորդները հասնում են դրան ստատիկ երթուղու միջոցով։ Երբ Pi-ի հասցեն 192.168.30.4-ից տեղափոխվեց 192.168.30.11, գրառումը հետևեց իր TTL-ի սահմաններում, իսկ երթուղիները՝ ոչ։

Երկու տեսքերը հակասում են այնպես, որ հեշտ է բաց թողնել, որովհետև առանձին հարցնելիս երկուսն էլ հավանական են թվում՝

$ ip route get 10.44.0.1
10.44.0.1 via 192.168.30.4 dev eth0 src 192.168.30.20
$ dig +short vpn-gw.lan
192.168.30.11

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

Ինչ է մնում աղյուսակում հրամանի ավարտից հետո

Linux-ի երթուղին գրանցում է երկու բան, որոնք այստեղ նշանակություն ունեն՝ հաջորդ ցատկը որպես արձանագրային հասցե, և ելքի ինտերֆեյսը որպես ինդեքսի համար։ rtnetlink-ի երթուղու ատրիբուտները անվանում են այդ առաջին դաշտը RTA_GATEWAY, և այն պարունակում է բայթեր։ Հենց գրառումը տեղում է, դրան ոչ մի TTL կցված չէ և ոչ մի ֆոնային որոնում այն չի թարմացնում։

Ահա թե ինչու ip route add 10.44.0.0/16 via vpn-gw.lan կարող է թվալ, թե աշխատում է։ Գործիքը լուծում է անունը հրամանի ընթացքում, գրում է ստացված հասցեն և ամբողջովին մոռանում անունը։ Գործարկեք ip route show 10.44.0.0/16 դրանից հետո և հետ կստանաք բառացի հասցե։

Այս վարքագիծը արժե իմանալ նախքան թունելին մեղադրելը։

Գործիքներ, որոնք անունը լուծում են ձեր փոխարեն, և երբ

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

Կառավարվող տեղադրումները սովորաբար բաժանում են աշխատանքը։ DHCP վերապահումը կամ ստատիկ վարձույթը Pi-ն պահում է մեկ հասցեի վրա, և DNS գրառումը պարզապես հետևում է վարձույթին։ Ոչինչ պետք չէ հետևի շարժվող թիրախի, որովհետև թիրախը չի շարժվում։

Հսկվող թարմացնողը մյուս օրինական ձևն է, և այն տեր է պահանջում։

Գամփոփեք հասցեն կամ ինքներդ գործարկեք թարմացնողը

Փոքր LAN-ի համար DHCP սերվերի վրա վերապահումը ամենաէժան լուծումն է։ Ընտրեք հասցե դինամիկ լողավազանից դուրս, կապեք այն Pi-ի MAC հասցեին և հաստատեք ip -4 addr show dev eth0-ով հաջորդ վարձույթի թարմացումից հետո։ Այնուհետև մեկ անգամ ուղղեք հաճախորդների հաջորդ ցատկը դեպի այդ հասցեն։ Այժմ դուք ունեք կայուն դարպաս և գրառում, որը նկարագրում է այն, և դա այն կարգն է, որով հարաբերությունը իրականում աշխատում է։

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

new=$(dig +short vpn-gw.lan | head -n1)
cur=$(ip route get 10.44.0.1 | awk '{print $3}')
if [ "$new" != "$cur" ]; then
  ip route replace 10.44.0.0/16 via "$new"
fi
ip route get 10.44.0.1

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

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