Դարձրեք IPv4 փոխանցումը կայուն VPN դարպասի վերագործարկումից հետո

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

Դարպասին հասնելը նույնը չէ, ինչ փոխանցելը

Միջուկի ներսում երկու առանձին որոշում է կայացվում։ Տեղական հասցեին առաքումը ավարտում է փաթեթի ճանապարհը. փոխանցումը նորից ուղարկում է այն դուրս մեկ այլ ինտերֆեյսով, և այդ երկրորդ որոշումը կառավարվում է ըստ ցանցային անվանատարածքի։ Դարպասը կարող է լիովին հասանելի լինել, մինչ փոխանցումը անջատված է, և ping-ի հրամանի տողից այդ երկու խափանումները նույնն են թվում։

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

Կարդացեք արժեքը այնտեղ, որտեղ փաթեթներն իրականում կան

Այն դարպասի վրա, որը երթուղավորում է հոսթի անվանատարածքում, մեկ հրաման պատասխանում է հարցին՝ sysctl net.ipv4.ip_forward։ Երբ ներգնա և հետագա ուղիներն ապրում են անվանված անվանատարածքում, հարցրեք այդ անվանատարածքին՝ ip netns exec vpn-gw sysctl net.ipv4.ip_forward։ Հոսթի արժեքը անվանատարածքի արժեքի փոխարինիչ չէ, և հոսթի վրա մեկը որևէ բանի ապացույց չէ։

Ոչ բոլոր երթուղավորման համատեքստերն ունեն պիտակ, որը կարող եք տալ ip netns-ին։ Կոնտեյներների կատարման միջավայրերը և ծառայությունները ստեղծում են անվանատարածքներ, որոնք երբեք չեն գրանցվում ընկերական անվան տակ, և դրանց համար օգտագործում եք կատարման միջավայրի ստուգման գործիքները։ Փոխարինեք vpn-gw-ը իրական անվամբ կամ նույն համատեքստին հասնող միջավայրի մեխանիզմով, և դադարեցրեք գուշակել հոսթի մակարդակում։

Տվեք կարգաբերմանը մեկ սեփականատեր

Սովորական systemd հոսթ-դարպասի վրա կայուն ձևը drop-in ֆայլն է՝ ադմինիստրատորի ընտրած անունով, օրինակ՝ /etc/sysctl.d/60-vpn-forwarding.conf, որը պարունակում է net.ipv4.ip_forward = 1։ Գրեք ֆայլը, ապա բեռնեք հենց այդ ֆայլը, որպեսզի կենդանի վիճակը նույնպես փոխվի՝ sudo sysctl -p /etc/sysctl.d/60-vpn-forwarding.conf, որին հաջորդում է հետընթերցում։ Ֆայլի անունը օրինակ է, ոչ թե վերապահված VPN ուղի, և սկզբի համարը կարևոր է, քանի որ ավելի ուշ տեսակավորված ֆայլերը հաղթում են։

Առաջնահերթությունը այն տեղն է, որտեղ կայունությունը հանգիստ կոտրվում է։ Ստուգեք և՛ բաշխման բեռնիչը, և՛ ձեր սեփական drop-in-ը, քանի որ procps sysctl --system-ը վերջում կարդում է նաև /etc/sysctl.conf-ը, մինչդեռ systemd-ի sysctl.d հերթականությունը բոլորովին այլ հաջորդականություն է։ Ավելի ուշ նշանակումը կարող է նույն բանալին անմիջապես վերադարձնել՝ թողնելով ձեր ֆայլը ճիշտ, իսկ արդյունավետ արժեքը՝ սխալ։ Մի գրեք գոյություն ունեցող ադմինիստրատորի ֆայլի վրա այդ վեճը հաղթելու համար. գտեք սեփականատիրոջը և փոխեք այնտեղ։

Բեռնումից հետո ստեղծված անվանատարածքը բոլորովին չի կառավարվում հոսթի drop-in-ով։ Նրա կարգաբերումը պատկանում է նրան, ինչ ստեղծում է այն՝ լինի դա կոնտեյներների կատարման միջավայրը, թե անվանատարածքի ապահովման միավորը։ Կոնտեյներին լայն հոսթ-արտոնություններ տալը հարցից խուսափելու համար ավելի վատ գործարք է, քան տասը րոպե ծախսել ճիշտ սեփականատիրոջը բացահայտելու վրա։

Իմացեք, թե ինչ արժե անջատիչը, նախքան այն շրջելը

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

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

Ապացուցեք կայունությունը, ապա փորձարկեք ուղու մնացած մասը

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

Միացված փոխանցումը դեռևս թողնում է երեք բան ստուգելու։ Հաճախորդին պետք է երթուղի դեպի նպատակակետ, դարպասին՝ հետագա երթուղի գումարած այն օգտագործելու թույլտվություն, իսկ նպատակակետին՝ վերադարձի ուղի դեպի հաճախորդի թունելի հասցեն։ Մասնավոր երթուղավորված LAN-ը ավտոմատ կերպով NAT չի պահանջում, այնպես որ մի ավելացրեք masquerading, մինչև չիմանաք, թե երեքից որն է պակասում, և փորձարկեք նախատեսված հաճախորդից, ոչ թե հենց դարպասից, քանի որ դարպասի վրա սկսված հարցումը երբեք չի դիպչում այն փոխանցման ուղուն, որը դուք հենց նոր միացրեցիք։ IPv6-ն ունի իր սեփական փոխանցման և երթուղավորման քաղաքականությունը, այնպես որ աշխատող IPv4 թեստը դրա մասին ոչինչ չի ասում։

Միասին պահեք runbook-ում drop-in-ի ուղին, անվանատարածքի սեփականատերը և հետընթերցման հրամանը։ Ով հաջորդը վերցնի սա, պետք է կարողանա կարդալ արժեքը, տեսնել, թե ով է տիրապետում դրան, և մեկ րոպեի ընթացքում որոշել՝ խնդիրը կայունության մեջ է, թե ուղու մնացած մասում։