OpenVPN-ի ստատիկ հաճախորդների հասցեները OPNsense-ի հետևում

Անունները պահանջում են հասցեներ, որոնք չեն շարժվում, իսկ OpenVPN-ի pool ֆայլը հասցեն դարձնում է միայն կպչուն։ Կորցրեք այդ ֆայլը կամ վերաթողարկեք վկայականն այլ ընդհանուր անունով, և վերադարձող հաճախորդը հայտնվում է pool-ի այլ տեղում, մինչ նրա DNS գրառումը դեռ ցույց է տալիս հին հասցեն։ Կայուն պատասխանը հաճախորդին բնորոշ override-ն է, որը ամրացնում է հասցեն, գումարած ավելի լայն թունելային ցանց, որպեսզի ամրացված հասցեները լինեն դինամիկ տիրույթից դուրս։ Այդ լայնացման հետևում ընկած թվաբանությունն է, որտեղ ապրում է շփոթության մեծ մասը։

OPNsense-ը պահում է այդ override-ները սերվերի հաճախորդին բնորոշ կարգավորումներում՝ վկայականի ընդհանուր անվամբ բանալիով, ինչը ընդհանուր անունը դարձնում է հասցեների պլանի մաս։

Կպչուն վարձակալությունը ստատիկ հասցե չէ

Pool ֆայլը գրում է հասցե-հաճախորդ համապատասխանություններ և վերադարձնում դրանք, երբ հայտնի հաճախորդը նորից միանում է։ Սա հարմարավետություն է, ոչ պայմանագիր․ ֆայլը կարելի է վերականգնել, համապատասխանությունը անհետանում է, երբ փոխվում է հաճախորդի ինքնությունը, և մեկ pool կիսող երկու սերվեր չեն համաձայնի դրա շուրջ։ Հաճախորդին բնորոշ override-ը այլ կերպ է աշխատում, որովհետև հասցեն գալիս է կազմաձևից, ոչ պատմությունից։ Այն նաև դիմանում է սարքի վերագործարկմանը և վերատեղադրմանը, պայմանով, որ override-ը պահուստավորված է մնացած կազմաձևի հետ։

Դինամիկ այլընտրանքը, այն է՝ VPN-ը DNS-ին միացնելը client-connect սկրիպտով և դինամիկ թարմացումներով, աշխատում է և պահանջում է resolver, որն ընդունում է թարմացումներ, գումարած սկրիպտ յուրաքանչյուր միացման ժամանակ։ Սարքի վրա դուք սահմանափակված եք մատակարարի տրամադրած փաթեթներով, և սովորաբար հենց այնտեղ է կանգնում այդ պլանը։

Այն /30 թվաբանությունը, որից ոչ ոք չի հիանում

Լռելյայն net30 տոպոլոգիայում յուրաքանչյուր հաճախորդ ստանում է իր /30-ը․ առաջին օգտագործելի հասցեն գնում է սերվերի կողմին, երկրորդը՝ հաճախորդին։ Ուստի override-ները պետք է լինեն սերվերի դինամիկ թունելային ցանցից դուրս, ինչը նշանակում է նախ լայնացնել այդ ցանցը։ 10.8.0.0/24-ի վրա գտնվող սերվերը կարող է տեղափոխվել 10.8.0.0/23-ի՝ հին տիրույթի կեսը թողնելով դինամիկ հաճախորդներին, իսկ մյուս կեսը՝ override-ներին։ Ավելացրեք բնօրինակ /24-ը որպես լրացուցիչ IPv4 տեղական ցանց, որպեսզի երկու կեսերի երթևեկությունը ուղղորդվի թունել։

Յուրաքանչյուր override հասցե պետք է ընկնի /30 սահմանի վրա, ուստի վերջին օկտետը չորսի բազմապատիկ է։ 10.8.1.0-ի վրա /30-ը հաճախորդին տալիս է 10.8.1.2, և հենց այդ հասցեն է կրում DNS գրառումը։ 10.8.1.3-ի ընտրությունը դրա փոխարեն ստեղծում է հաճախորդ, որը միանում է և չի կարող անցկացնել երթևեկություն, որովհետև հասցեն պատկանում է ենթացանցի, որը տոպոլոգիան երբեք չի հատկացրել նրան։

Պլանը ավելի հեշտ է պահել, եթե override-ները հատկացվում են լայնացված տիրույթի գագաթից ներքև, որպեսզի դինամիկ pool-ը ընդարձակվի ազատ տարածության մեջ, այլ ոչ թե ֆիքսված կղզիների շուրջ։

Տեղական ցանցերը և այն զոնան, որը հարցնում են հաճախորդները

Հաճախորդից հաճախորդ երթևեկությունը պահանջում է իր սեփական թույլտվությունը։ Սերվերի IPv4 տեղական ցանցերի ցանկը պետք է ներառի տիրույթի երկու կեսերը՝ դինամիկ և ստատիկ․ առանց դրա սերվերը ընդունում է փաթեթ մի հաճախորդից և չունի քաղաքականություն, որը թույլ է տալիս այն անցկացնել մյուսին։ Ախտանիշը նման է DNS ձախողման, որովհետև անունը լուծվում է, և կապը միևնույն է ձախողվում է։ Միևնույն ժամանակ ստուգեք հաճախորդից հաճախորդ կարգավորումը, քանի որ միայն տեղական ցանցի գրառումը չի միացնում փոխանցումը հավասարների միջև։

Հրապարակեք գրառումները այն զոնայում, որը հեռավոր հաճախորդները փաստացի հարցնում են։ Գրառումը զոնայում, որը սպասարկվում է միայն LAN resolver-ի կողմից, անտեսանելի է այն հաճախորդի համար, ում հրված resolver-ը ցույց է տալիս այլ տեղ, և սխալ զոնայում ավելի շատ գրառումներ ավելացնելը երբեք չի ուղղում դա։ Նախքան որևէ բան ավելացնելը հաստատեք հրված DNS ընտրանքը և որոնման դոմենը։

Ինչ ստուգել նոր միացման ժամանակ

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

Այլ ընդհանուր անունով վերաթողարկված վկայականը դադարում է համապատասխանել իր override-ին և հաճախորդին վերադարձնում է դինամիկ pool։ Սպասեք դրան ցանկացած ինքնության փոփոխությունից հետո։