Պահպանել կամ SNAT անել VPN հաճախորդների IP հասցեները ամպի սահմանին

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

Երեք պայման են որոշում

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

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

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

Երթուղին կեղծիքի թույլտվություն չէ

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

Անջատեք այն միայն այն ինստանսի համար, որի փաստաթղթավորված աշխատանքը փոխանցումն է, և ոչ այլ բանի համար։ Յուրաքանչյուր հավելվածային VM, որը ստուգումը թողնում է միացված, մեկ մեքենա պակաս է, որը կարելի է օգտագործել փոխառված աղբյուրով երթևեկություն ուղարկելու համար։ Եթե ձեր հարթակը AWS չէ, փնտրեք համարժեք հակակեղծիքի կամ թույլատրված հասցեների կարգավորումը՝ փոխարենը չենթադրելով, որ վարքագիծը կտեղափոխվի։

Փաթեթների արագ որսումը հարցը լուծում է ավելի արագ, քան կոնսոլը կարդալը։ Եթե պատասխանները դուրս են գալիս, և հաճախորդը դրանք երբեք չի տեսնում, ապա հյուսվածքն է դեն նետում կեղծված աղբյուրը, և ոչ թե հավելվածն է ձախողվում։

Ինչ է գնում թարգմանությունը և ինչ արժե

Աղբյուրը դարպասում վերաշարադրելը վերացնում է վերադարձի ուղու խնդիրը։ Հավելվածը տեսնում է մեկ հասցե, որին արդեն գիտի ինչպես հասնել, հաճախորդի նախածանցը երբեք պետք չէ հայտնվի ամպային երթուղային աղյուսակում, իսկ Linux-ում կանոնը մեկ տող է՝ արժե գրել ամենանեղ տարբերակը, որը կարող եք։

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

Ռելեն այլ ինտերֆեյս է

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

Այդ վերնագիրը վստահելի է միայն այն ժամանակ, երբ backend-ն այն ընդունում է պրոքսիից և ոչ մի այլ բանից, և nginx-ի տերմիններով դա նշանակում է բացահայտ նշել վստահելի գործընկերոջը՝ փոխարենը հավատալով ամեն ինչի, ինչ գալիս է։

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

Ցանկացած հաճախորդ, որը կարող է ուղղակիորեն հասնել backend-ին, կարող է կեղծել նույն վերնագիրը, ուստի backend-ը պետք է անհասանելի լինի բացի պրոքսիից։ Սա firewall-ի փաստ է, ոչ կարգավորման կարծիք, և հենց այդ ենթադրությունն են մարդիկ բաց թողնում, երբ պատճենում են հատվածը։

Ռելեն նաև փոխում է, թե ինչ եք գնում։ Դուք ստանում եք հավելվածի մակարդակի ինքնություն և բնական տեղ այն գրանցելու համար՝ դուք զիջում եք ընդհանրությունը, քանի որ յուրաքանչյուր նոր արձանագրություն ունի իր պրոքսի աջակցության կարիքը։ HTTP ծառայությունների համար այդ փոխանակումը սովորաբար լավ է, իսկ այն ամենի համար, ինչ HTTP չէ, սովորաբար ընդհանրապես հասանելի չէ։

Գրեք, թե ինչ է տեսնում յուրաքանչյուր սահման

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

Ապա ընտրեք։ Պահպանեք աղբյուրը, երբ հավելվածի լիազորումը իսկապես կախված է հաճախորդի հասցեից, և դուք կարող եք ստանձնել երթուղին։ Թարգմանեք, երբ այդպես չէ, և դուք կարող եք ինքնությունը կրել ժապավենից դուրս, և օգտագործեք AWS-ի փոխանցող ինստանսների ուղեցույցը հարթակին հատուկ փոխանցման կարգավորումների համար։ Դիմեք ռելեի, երբ ծառայությունը խոսում է HTTP, և դուք ուզում եք, որ ինքնությունը վերջապես հասցե չլինի։