NFS clientaddr VPN-ի վրայով. որոշումը՝ ըստ փոքր տարբերակի, ոչ թե սովորության
clientaddr-ը հայտարարում է հետկանչի հասցե միայն NFSv4.0-ի համար։ Կարդացեք պայմանավորված փոքր տարբերակը, ստուգեք վերադարձի ուղին և առանձնացրեք այն մոնտաժի ձախողումներից։
clientaddr-ը մոնտաժի այն ընտրանքներից է, որոնք պատճենվում են հրամանի տողում այն բանից շատ ավելի ուշ, երբ դրա պատճառն արդեն անհետացել է։ Այն NFSv4.0 սերվերին ասում է, թե որտեղ պետք է հետ կանչել հաճախորդին։ Այն չի ընտրում սերվերը, չի կապում ամեն հարցում աղբյուրի հասցեին և չի մղում երթևեկությունը թունելի մեջ։ Մի քանի հասցե ունեցող նոթբուքում որոշելու համար, թե արդյոք այն ընդհանրապես կիրառելի է, պետք է երեք հարց։
Երեք պայման են որոշում՝ արդյոք ընտրանքը կարևոր է
Առաջինը պայմանավորված փոքր տարբերակն է, քանի որ 4.1-ը և 4.2-ը հետկանչերին տարբեր կերպ են վերաբերվում։ Երկրորդը՝ կարո՞ղ է սերվերը հասնել այն հասցեին, որը դուք կհայտարարեիք. երթուղավորված թունելը դա սովորաբար թույլ է տալիս, իսկ թարգմանված ուղին՝ սովորաբար ոչ։ Երրորդը՝ արդյոք ձեր հետապնդած ձախողումն ընդհանրապես հետկանչի ձախողում է։
| Condition | If yes | If no |
|---|---|---|
| Version is 4.0 | The option can matter | Skip it; inspect the session instead |
| Server can reach the address | Advertise it | Fix reachability first |
| Failure is a callback | Diagnose callback path | Look at mount and export |
Նրանց սխալ հերթականությամբ պատասխանելն այն ուղին է, որով մարդիկ 4.2 մոնտաժին ավելացնում են հետկանչի հասցե և եզրակացնում, որ ընտրանքը փչացած է։
Նախ կարդացեք փոքր տարբերակը
nfsstat -mԳոյություն ունեցող մոնտաժի համար սա տպում է մոնտաժի տեղեկությունները և դրոշները, ներառյալ գործող տարբերակը՝ vers=4.0, vers=4.1 կամ vers=4.2 տեսքով։ Միայն «NFSv4» ասող նշումը բաց է թողնում այն միակ մանրամասնությունը, որը որոշում է՝ արդյոք այս ընտրանքը համապատասխան է։ Կարդացեք թիվը, ոչ թե բառը։
Եթե տարբերակի տողը եկել է սերվերի լռելյայն կարգավորումից, ոչ թե ձեր հրամանի տողից, հարցրեք՝ որ փոքր տարբերակն է պայմանավորվվել։ Սերվերը կարող է մերժել ավելի բարձր փոքր տարբերակը և հետ ընկնել, և հենց այդ հետընկնումն է այն դեպքը, երբ հետկանչը հանկարծ կարևորվում է։ Ձեր գրած մոնտաժի տողը կարող է չնկարագրել ձեր ունեցած մոնտաժը։
4.0-ի համար հայտարարեք հասցե, որին սերվերը կարող է հասնել
NFSv4.0 սերվերին կարող է անհրաժեշտ լինել առանձին կապ հաճախորդի հետ, օրինակ՝ երբ այն հետ է կանչում պատվիրակումը։ Մի քանի ինտերֆեյսի կամ անսովոր երթուղային աղյուսակի դեպքում հետկանչի հասցեի ավտոմատ հայտնաբերումը կարող է ընտրել մեկը, որը սերվերը չի կարող օգտագործել։
mount -t nfs -o vers=4.0,clientaddr=10.8.0.6 10.8.0.1:/export /mnt/shareԵրկու կետից առաջ հասցեն սերվերն է և մնում է նպատակակետը։ Հետկանչի հասցեն պատկանում է հաճախորդին, և այն պետք է հասանելի լինի թունելի սերվերի կողմից։ Loopback հասցեն սերվերին հետ է դարձնում դեպի ինքն իրեն։ Առանց վերադարձի երթուղու մասնավոր հաճախորդի հասցեն նույնքան անօգտագործելի է, թեև հաճախորդի վրա այն ճիշտ է թվում։
Օգտագործեք սա որպես օրինակ, ոչ որպես աշխատող մոնտաժն իջեցնելու պատճառ։ Փոխարինեք հասցեները և արտահանման ուղին, և պահեք նույնականացումը և սերվերի պահանջած մյուս ընտրանքները։ Դրանք բաց թողնելը, որպեսզի մեկ օրինակ տեղավորվի, այլ փոփոխություն է այլ արդյունքով, և անվտանգության տեսակ պարտադրող սերվերի վրա այն ձախողվում է ցանկացած հետկանչ փորձելուց առաջ։
4.1-ը և 4.2-ը չեն օգտագործում այս ընտրանքը
Linux NFSv4.1-ը և 4.2-ը հետկանչերը տեղափոխում են հաճախորդի հաստատած կապերի վրայով, և 4.1-ը այդ միջոցը կոչում է backchannel։ Նրանք կախված չեն նրանից, թե սերվերը նոր կապ կբացի հայտարարված հասցեին, ուստի clientaddr-ը չի վերանորոգում 4.1-ի կամ 4.2-ի հետկանչի ուղին։
Դա չի նշանակում, որ 4.1-ը և 4.2-ը հետկանչի խնդիրներ չունեն։ Դա նշանակում է, որ ախտորոշումն այլ է. զննեք հաստատված նստաշրջանը և դրա backchannel վիճակը՝ փոխարենը չփնտրելով մուտքային հետկանչի պորտ, որը երբեք չպետք է գոյություն ունենար։ Բացակայող մուտքային կանոնը սպասվող վիճակն է, ոչ թե ուղղման ենթակա խնդիր։
Առանձնացրեք մոնտաժի ձախողումը հետկանչի ձախողումից
Նախ պարզեք՝ արդյոք հաճախորդը հասնում է NFS ծառայությանը և արդյոք սերվերն ընդունում է արտահանումը և նույնականացման հայտը։ Այդ փոխանակումից առաջ ժամկետի լրանալը ոչինչ չի ասում հետկանչի հասցեի մասին։ Մեկը փոխելը, մինչ մոնտաժը դեռ ձախողվում է, հետազոտությունը չի մոտեցնում և թաքցնում է սկզբնական սխալը նոր մոնտաժի ընտրանքի հետևում։
Միայն այն ժամանակ, երբ ապացույցները ցույց են տալիս ձախողված 4.0 հետկանչ, հայտարարված հասցեն կարևոր է դառնում՝ սերվերի վերադարձի ուղու, հաճախորդի կողմի լսողի և նրանց միջև ցանկացած զտման հետ միասին։ Մոնտաժի ընտրանքի թիվը փոխելը չի կարող ստեղծել այդ ուղիները. այն կարող է միայն մատնանշել արդեն գոյություն ունեցողին։ Գրեք, թե այդ չորսից որն եք ստուգել, որովհետև հաջորդ զեկույցը կգա դրանցից ոչ մեկի առանց։
Վաղ բեռնման NFS արմատը առանձին միջավայր է իր նախապայմաններով. initramfs-ին անհրաժեշտ են գործիքներն ու ցանցը, նախքան մոնտաժը կկարողանա տեղի ունենալ։ Մուտքից հետո աշխատող մոնտաժը ոչինչ չի ապացուցում այդ հաջորդականության մասին, և բեռնման ժամանակ ձախողումը հազվադեպ է հիշատակում initramfs-ը կամ ցանցը։