Ինչու net.ipv4.conf.default.forwarding-ը անփոփոխ է թողնում tun0-ն

Դուք սահմանել եք net.ipv4.conf.default.forwarding=1, վերագործարկել եք VPN-ը, և թունելը դեռ գցում է այն փաթեթները, որոնք դարպասը պետք է երթուղավորեր։ Կարգավորումը ֆայլում ճիշտ է թվում, և ինտերֆեյսը դեռ հաղորդում է, որ փոխանցումն անջատված է։ Ոչինչ չի կոտրվել. դուք փոխել եք այն արժեքը, որը ժառանգելու են ապագա ինտերֆեյսները, ոչ թե այն, որն օգտագործում է գործող թունելը։

Անցեք սա այն հոսթի վրա, որը տիրապետում է թունելին, այն ցանցային namespace-ում, որտեղ թունելն իրականում գոյություն ունի։ Կոնտեյները կամ ցանցային namespace-ը կարող են պահել ինտերֆեյսը, մինչ հոսթը ցույց է տալիս այլ թվեր։

Կարդացեք երեք արժեքները միասին

Սկսեք համեմատել դարպասի մակարդակի անջատիչը, նոր ինտերֆեյսների ձևանմուշը և ձեզ հետաքրքրող ինտերֆեյսը։ Փոխարինեք tun0 իրական մուտքային ինտերֆեյսով և կարդացեք նաև վերադարձի ինտերֆեյսը, քանի որ փոխանցումը գնահատվում է հենց այն կետում, որտեղ փաթեթը հասնում է։

sysctl net.ipv4.ip_forward
sysctl net.ipv4.conf.default.forwarding
sysctl net.ipv4.conf.tun0.forwarding

Սովորական արդյունք է ip_forward = 0, default.forwarding = 1 և tun0.forwarding = 0։ Առաջին երկուսը համաձայն չեն հոսթի դերի շուրջ, իսկ երրորդը ցույց է տալիս, թե ինտերֆեյսն ինչ է իրականում անում։ Այդ համակցությունը համապատասխանում է հոսթի, որը երբեք չի կարգավորվել որպես երթուղիչ, այլ ստացել է միայն ձևանմուշային արժեք։ Երեք թվերը չեն հակասում միմյանց. դրանք պատասխանում են երեք տարբեր հարցերի։ Ձևանմուշային արժեքը գրելը նույնպես չի որոշում հոսթի դերը։

Ինչու է շարժվում հենց գլոբալ անջատիչը

net.ipv4.ip_forward դարպասի մակարդակի կառավարումն է։ Այն փոխելը թարմացնում է ինտերֆեյս առ ինտերֆեյս փոխանցման կարգավորումները նույն գործողության մասով, այդ պատճառով մեկ գրառումը կարող է ստիպել գոյություն ունեցող թունելին սկսել փոխանցել։ default.forwarding սերմանում է միայն այն ինտերֆեյսները, որոնք սկզբնավորվում են դրանից հետո, ուստի արդեն գոյություն ունեցող թունելը պահպանում է այն արժեքը, որով ծնվել է։

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

Ինտերֆեյս առ ինտերֆեյս արժեքները նույնպես պատճառ ունեն։ Դիտավորյալ կառավարվող դարպասը կարող է փոխանցումը անջատված պահել այն ինտերֆեյսի վրա, որը երբեք չպետք է երթուղավորի, նույնիսկ երբ հոսթն այլ տեղ է փոխանցում։ Այդ պատճառով է կարևոր կարդալ գործող ինտերֆեյսը և այդ պատճառով է, որ միայն գլոբալ արժեքը ամբողջ պատասխանը չէ։ Նման բացառությունը կարդացեք որպես գիտակցված որոշում և գրեք, թե ինչու է այդ ինտերֆեյսը տարբեր։ Հակառակ դեպքում հաջորդ ինժեները հոժարությամբ կ«ուղղի» այն։

Կարգավորումը մշտական դարձրեք ճիշտ տեղում

Հաջող միանվագ sysctl -w ապացուցում է, որ միջուկն ընդունում է արժեքը։ Այն չի գոյատևում վերագործարկումից և չի գոյատևում այն ցանցային կառավարիչից, որը վերամիանալիս նորից կիրառում է ինտերֆեյսի կարգավորման իր պատկերացումը։ Դրեք դարպասի դերը sysctl-ի կարգավորման ֆայլում կամ այն ցանցային կառավարչում, որը տիրապետում է հոսթին, ապա վերագործարկեք այն ծառայությունը, որը կիրառում է այն։

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

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

Մի՛ վերանորոգեք սա սխալ գործիքով

Երբ փոխանցումը կոտրված էր թվում, գայթակղությունը firewall-ը դատարկելն է կամ masquerading ավելացնելը։ Ոչ մեկը չի լուծում փոխանցման անջատիչը։ Փոխանցման վիճակը, փոխանցելու թույլտվությունը, դեպի նպատակակետ երթուղին և վերադարձի ուղին չորս առանձին պահանջներ են, և միայն առաջինն է sysctl-ը։

Փորձարկեք նաև ճիշտ հոսքով։ Հենց դարպասի վրա արված հարցումն ընդհանրապես չի վարժեցնում փոխանցումը. դա տեղում գեներացված տրաֆիկ է։ Հարցն այն է՝ արդյոք VPN հաճախորդից կամ LAN հոսթից եկող փաթեթն ընդունվում և առաջ է երթուղավորվում, ուստի թեստը պետք է սկսվի դարպասի հետևից։

Առանձին պահեք IPv6 դեպքը

Այստեղ ամեն ինչ IPv4 է։ IPv6 փոխանցումը, երթուղիչի հայտարարությունները և accept_ra վարքը ունեն իրենց կառավարումը, և ipv4 ուղին ipv6 կարգավորման մեջ պատճենելը ստեղծում է ֆայլ, որը հավատալի է թվում և ոչ մի օգտակար բան չի անում։ Կրկնակի ստեկով դարպասին պետք է, որ երկու հավաքածուներն էլ գիտակցաբար կարգավորվեն։

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