RADIUS-ի Framed-IP-Address՝ կայուն VPN հաճախորդի հասցեի համար

RADIUS-ը կարող է պատասխանել որոշակի օգտվողի համար նախատեսված հասցեով. թունելը այն իրականում ստանում է, թե ոչ՝ կախված է դարպասից։ Հենց վերադարձվածի և կիրառվածի միջև այս ճեղքում են ձախողվում կայուն հասցեի ծրագրերի մեծ մասը։ Փորձնական պատասխանում առկա հատկանիշը վկայում է, որ սերվերը կարող է այն ուղարկել, այլ ոչ թե որ հեռավոր մուտքի ծառայությունը կիրառում է այն։ Ստորև ներկայացված հաջորդականությունը ստուգում է երկու կեսերն էլ, մինչև հասցեն հայտնվի հրակարմրիչի կանոններում։

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

Հեռավոր մուտքի դարպասները սովորաբար ունենում են տեղական լողավազան, և շատերը կարող են նաև ընդունել հասցե նույնականացման պատասխանից։ Թե որն է հաղթում, կախված է հարթակից, արձանագրությունից և ծառայության կոնֆիգուրացիայից, ուստի կարդացեք առաջնահերթության կանոնը օգտագործվող ճշգրիտ տարբերակի համար։ Այնտեղ, որտեղ առաջնահերթություն ունի տեղական լողավազանը, հատկանիշը միայն զարդարանք է, և հաճախորդը միևնույն է հայտնվում է պատահական հասցեում։ Գրի առեք որոշումը, ներառյալ՝ արդյոք վերադարձված արժեքը պետք է լինի լողավազանի սահմաններում, թե կարող է դուրս լինել։

RFC 2865-ը սահմանում է Framed-IP-Address որպես օգտվողի համար կարգավորվող հասցե և ոչինչ չի ասում կոնկրետ դարպասի՝ այն հարգելու պատրաստակամության մասին։ Առաջնահերթության հարցում հեղինակավոր է արտադրողի փաստաթղթերը, այլ ոչ թե հատկանիշի սահմանումը։

Ուղարկեք փորձնական հարցում և կարդացեք պատասխանը

Նախ առանձին փորձարկեք սերվերը, որպեսզի բացակայող հատկանիշը չշփոթվի դարպասի խնդրի հետ։ radtest-ը ուղարկում է մեկ Access-Request և տպում է վերադարձվող հատկանիշները։

radtest alice 'S3cret' 127.0.0.1 0 testing123

Փնտրեք Framed-IP-Address-ը Access-Accept-ում և հաստատեք, որ արժեքը նախատեսվածն է, այլ ոչ թե պահուստային կանոնից լողավազանի հասցե։ Երբ հատկանիշը բացակայում է, օգտվողի գրառումը կամ լիազորման քաղաքականությունը չեն համապատասխանում, և դարպասի կարգավորումը չի կարող տրամադրել այն, ինչ սերվերը երբեք չի ուղարկել։ Կրկնեք հարցումը, երբ սերվերն աշխատում է վրիպազերծման ռեժիմում, եթե պատասխանը դժվար է կապել կոնկրետ կանոնի հետ։ Ընդհանուր գաղտնիքը պահեք shell-ի պատմությունից և տոմսերից դուրս, քանի որ վերևի տեղապահը մուտքի տվյալ չէ։

Հաստատեք, որ դարպասը հարգել է արժեքը

Ճիշտ պատասխանը պայմանագրի միայն կեսն է։ Թունելի ինտերֆեյսում հայտնված հասցեն էական դիտարկումն է, և այն կարդացվում է հաճախորդի վրա, այլ ոչ թե եզրակացվում դարպասի կոնֆիգուրացիայից։

ip -4 addr show tun0

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

Պլանավորեք զուգահեռությունը և չեղարկումը

Մեկ օգտանունը երկու սարքերում չի կարող համապատասխանել մեկ հասցեի, եթե դարպասը սեսիաները չի տարբերում մուտքից բացի այլ բանով։ Որոշեք՝ քարտեզագրումը պատկանում է անձի, գրանցված սարքի, թե վկայագրի ինքնությանը, և այդ ընտրությունը հստակ նշեք քաղաքականության պահոցում։ Փորձարկեք երկրորդ միաժամանակյա հաճախորդին և համեմատեք տրված երկու հասցեները, քանի որ այստեղ բախումը ավելի ուշ նորից ի հայտ է գալիս որպես երթուղավորման սխալ։ Նույն խնամքը վերաբերում է չեղարկման պլանին, քանի որ վերանշանակված հասցեն, երբ հին հրակարմրիչի կանոնները դեռ հղում են անում նրան, վերածվում է լիազորման սխալի։

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