OpenVPN հաճախորդներն անցկացնե՞լ Cloudflare-ով. նախ ստուգեք դերը
Սարքի հաճախորդը երթուղիչ չէ։ Հաստատեք, որ Cloudflare-ի դերը փոխանցում է այլ հոսթերի փաթեթները, ապա սերվերի սեփական թունելը թողեք իր հին ուղու վրա։
Դուք ունեք աշխատող OpenVPN սերվեր և հոսթ, որը նաև գործարկում է Cloudflare-ի սարքի ծրագրակազմը, և հաջորդ ակնհայտ քայլը կարծես հաճախորդների երթևեկությունն այնտեղ ուղղելն է։ Մեկ մեքենայի վրա երկու աշխատող կապ չեն կազմում տրանզիտ դարպաս։ Պակասում է ուրիշին պատկանող փաթեթներ փոխանցելու համար փաստաթղթավորված դեր, և քաղաքականություն, որը դասակարգում է այդ փաթեթները, երբ դրանք ժամանում են։
Ցանկացած կանոնից առաջ չորս հարց կա. ինչ երթևեկություն է մտնում, ուր է այն գնում հետո, ինչպես են պատասխանները գտնում վերադարձի ուղին, և ինչ է անում դիզայնը, երբ այդ երկրորդ ուղին ձախողվում է։ Առաջին երկուսը կարողության հարցեր են։
Մեկ հոսթի վրա երկու ծառայություն տրանզիտ ուղի չեն
Սարքի հաճախորդը կառուցված է այն մեքենայում ծագող երթևեկությունը մշակելու համար, որտեղ ինքը գործում է։ Այն որսում է անունների լուծումը կամ ընտրված հավելվածային երթևեկությունը և ուղարկում է այն իր սեփական թունելով, իսկ նրա քաղաքականությունը գրված է այդ սարքի օգտվողի և այդ սարքի գործընթացների համար։ OpenVPN հաճախորդից փոխանցված փաթեթը տեղական ելք չէ, ուստի նույն կանոնները չեն դասակարգում այն։ Սա կոնֆիգուրացիայի մանրուք չէ, որը կարելի է ծածկել ավելի լայն կանոնով, որովհետև հենց այն է որոշում՝ ծրագրակազմն ընդհանրապես տեսնում է փաթեթը, թե ոչ։
Այդ պատճառով դիզայնի հարցը կարողության հարց է։ Կա՞ տեղադրված արտադրանքի մոտ փաստաթղթավորված դեր, որը փոխանցում է երթևեկություն այլ ցանցերի համար, թե՞ տրանզիտ գործառույթը բոլորովին այլ տեղ է պատկանում։
Cloudflare-ի ո՞ր դերին է թույլատրվում փոխանցել
Cloudflare-ի սարքի հաճախորդը առաջարկում է տարբեր ծավալի ռեժիմներ՝ միայն անունների լուծում, երթևեկություն սարքից, և երբեմն երկուսը միասին։ Այդ ռեժիմներից ոչ մեկը հոսթը չի դարձնում երթուղիչ մեկ այլ թունելով եկող մասնավոր միջակայքի համար։ Հատուկ երթուղավորման դերը առանձին արտադրանք է՝ իր միակցիչով, գրանցմամբ և ցանցային մոդելով։
| Question | What has to answer it |
|---|---|
| Does the installed product forward packets from other hosts? | A documented routing or connector role, not a device mode |
| Which prefixes does the connector advertise? | Its own configuration and status output |
| Does the server's own transport still take the old path? | ip route get for the endpoint, before and after |
| Do replies return through the same path? | Connection tracking counters on the forward rule |
Ստուգեք տեղադրված դերը նախքան դրա շուրջ երթուղիներ նախագծելը։ Կարդացեք, թե միակցիչը որ ինտերֆեյսն է ստեղծում, արդյոք այն հայտարարում է հատուկ նախածանցներ կամ լռելյայն երթուղի, և արդյոք տեղական քաղաքականությունը տարածվում է նաև փոխանցված փաթեթների վրա, ոչ միայն տեղականների։ Եթե մշակվում է միայն տեղական երթևեկությունը, OpenVPN սերվերը չի կարող լինել տրանզիտ կետ՝ անկախ նրանից, թե ինչպես է գրված թարգմանության կանոնը։
Այստեղ է, որ հանրային ելքի պահանջը պետք է ձևակերպվի ճշգրիտ։ Cloudflare-ի տրամադրած ելքը փոխանցված հաճախորդային երթևեկության համար կոնկրետ օգտագործման դեպք է, և այն պետք է հաստատվի ձեր իրականում ունեցած ծառայության դեմ։
Արտաքին թունելը պահեք անկախ նոր երթուղուց
Այն պահին, երբ լռելյայն երթուղի եք ավելացնում դեպի նոր ինտերֆեյս, սերվերի սեփական ելքային երթևեկությունը սկսում է մրցել դրա համար, և դա ներառում է OpenVPN հաճախորդներին ուղղված պատասխանները և ձեր SSH նստաշրջանը դեպի այդ տուփը։ Սովորական ախտանիշը թունելն է, որը հաստատվում է, ապա մահանում, կամ ադմինիստրատորը, որը դրսից կողպվում է, մինչ փոփոխությունը կարծես աշխատել է։ Համեմատեք ip route get-ը վերջնակետի համար առաջ և հետո, և օգտագործեք քաղաքականությամբ երթուղավորում կամ հոսթի երթուղի՝ սերվերի սեփական փոխադրումը նույն տեղում պահելու համար։ Այդ համեմատությունն անցկացրեք հենց տուփից, որովհետև սերվերի սեփական տեսակետն իր երթուղու մասին է, որ կարևոր է։
Սերվերի հանրային հասցեի համար բացառությունը ինքնին բավարար չէ, որովհետև յուրաքանչյուր հեռավոր ադմինիստրատորի վերադարձի ուղին առանձին հոսք է։ Որոշեք, թե այդ հոսքերից որոնք պետք է վերապրեն փոփոխությունը, ապա ստուգեք յուրաքանչյուրը՝ փոխարենը ենթադրելու, որ առաջինը ծածկում է մնացածը։
Սահմանափակեք փոխանցումն ու թարգմանությունը մեկ հոսքով
Ստացված փաթեթները հետևում են փոխանցման ուղուն, ոչ տեղական ելքի ուղուն, ուստի կարևոր կանոնը ապրում է forward կեռիկում։ Այնտեղ, որտեղ հաջորդ ինտերֆեյսին թարգմանություն է պետք, աղբյուրը սահմանափակեք հաճախորդների լողավազանով, նպատակակետը՝ թույլատրելիով, և ելքը՝ այդ մեկ ինտերֆեյսով։ Միայն ինտերֆեյսին կապված masquerade կանոնն ինքնուրույն երթուղի չի ընտրում և թույլ չի տալիս փոխանցում որևէ այլ զտիչից այն կողմ։
Ձախողման դեպքում փակվելու վարքը որոշեք նախապես, ապա ստուգեք այն։ Կանգնեցրեք հաջորդ ուղին և հաստատեք, որ հաճախորդները կորցնում են նախատեսված ելքը՝ փոխարենը լուռ վերադառնալու սովորական վերին կապին, որովհետև սա է այն արդյունքը, որը ոչ ոք չի նկատում, քանի դեռ երթևեկությունը սկսում է դուրս գալ սխալ դռնով։ Կրկնեք ստուգումը անունների լուծման և IPv6-ի համար, որովհետև միայն v4-ի համար կանոնների հավաքածուն բաց է թողնում v6 ուղին։
Գրեք այն չորս պատասխանները, որոնց վրա կանգնեցիք, և դիտարկումը, որը ցույց է տալիս յուրաքանչյուրը։ Տրանզիտ ուղին, որը կարող եք նկարագրել, այն է, որը կկարողանաք պաշտպանել հաջորդ միջադեպի վերանայմանը։