VPN հաճախորդի IP-ն Kubernetes-ում. պահե՞լ, թե՞ SNAT անել։
Ընտրեք VPN հաճախորդի իրական հասցեն պահելու և Kubernetes-ում աղբյուրի NAT-ի միջև երեք պայմանի հիման վրա, ապա ստուգեք վերադարձի ուղին և պոդերի փոփոխությունը։
Թունելի և backend-ի միջև ինչ-որ տեղ հաճախորդի հասցեն կամ գոյատևում է, կամ փոխարինվում, և երկու ելքերն էլ պաշտպանելի են։ Ընտրությունը պատկանում է ընդունող ծառայության տիրոջը, ոչ թե նրան, ով տեղադրել է CNI-ն։ Երբ կարևոր են հաճախորդով պայմանավորված լիազորումը, քվոտաները կամ աուդիտի գրառումները, հասցեն պետք է գոյատևի յուրաքանչյուր ցատկում։ Երբ համատեղ վերագրումը ընդունելի է, աղբյուրի NAT-ը վերացնում է երթուղային խնդիր, որը հակառակ դեպքում հավերժ կպահեիք։
Որտեղ է իրականում անհետանում հաճախորդի հասցեն
Հեռավոր հաճախորդի փաթեթը հասնում է VPN պոդին թունելի տիրույթում գտնվող ներքին աղբյուրով, ասենք 10.90.0.42։ Երբ պոդը փոխանցում է այդ փաթեթը դեպի ClusterIP կամ պոդի IP, աղբյուրը կարող են վերաշարադրել երեք տարբեր մեխանիզմներ։ Հանգույցի CNI-ի masquerade կանոնը ծածկում է այն երթևեկությունը, որը պոդը ուղարկում է կլաստերի CIDR-ից դուրս։ Նպատակակետ հանգույցի kube-proxy-ի conntrack գրառումը ծածկում է հենց Service ցատկը։ Պրոքսին, որը ավարտում է կապը, փաթեթը ընդհանրապես չի փոխանցում, ուստի վերջում ձեր տեսած աղբյուրը պատկանում է պրոքսիին։
Նրանցից յուրաքանչյուրը ապրում է տարբեր շերտում, այդ պատճառով Service-ի մեկ դաշտը գրեթե երբեք չի վերանորոգում ամբողջ ուղին։
VPN-ի հանրային Service-ի externalTrafficPolicy-ը որոշում է միայն արտաքին կապի ճակատագիրը. Local-ը պահում է հեռավոր հասցեն այն հանգույցում, որը ստացել է այն, մինչդեռ Cluster-ը թույլ է տալիս kube-proxy-ին փաթեթը հանձնել այլ հանգույցի և այնտեղ masquerade անել։ Այդ կարգավորումը կառավարում է այն լսիչը, որին միանում են ձեր հաճախորդները։ Այն ոչինչ չի ասում ապակոդավորված փաթեթի մասին, որը ձեր VPN գործընթացը հետո ուղղորդում է կլաստեր։
Երեք պայման, որոնք լուծում են վեճը
Ես տալիս եմ նույն երեք հարցերը նույն հերթականությամբ ամեն անգամ, երբ սա առաջանում է, որովհետև առաջինը սովորաբար ավարտում է քննարկումը։ Պատասխանեք դրանց կոնկրետ աշխատանքային բեռի համար, ոչ թե ամբողջ կլաստերի։ Մեկ ընկերության ներսում երկու կլաստեր կարող են հանգել տարբեր պատասխանների, և երկուսն էլ ճիշտ լինել։
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
Եթե backend-ը պատասխանում է այո առաջին հարցին և ոչ երկրորդին, դուք ցանցային աշխատանք ունեք անելու, ոչ թե manifest խմբագրելու։ Եթե երրորդ տողը ասում է պրոքսի, հասցեն երբեք չէր գոյատևի, և հակառակը պնդելը արժե մեկ շաբաթ փաթեթների որսորդություն։
Ինչ է preserve ռեժիմը պահանջում ցանցից
Աղբյուրը պահելը նշանակում է, որ նպատակակետ հանգույցը պետք է երթևեկությունը վերադարձնի 10.90.0.42-ին ակտիվ VPN դարպասի միջոցով։ VPN լողավազանը կլաստերի CIDR չէ, ուստի ոչ մի CNI այն ձեր փոխարեն չի երթուղավորում լռելյայն։ Դուք ինքներդ ավելացնում եք երթուղին, ապա համոզվում, որ դարպասի այն վերջնակետը, որին այն ուղղված է, գոյատևում է վերապլանավորումից։
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2Այդ հաջորդ ցատկը պոդի հասցե է, և պոդերի հասցեները տեղաշարժվում են։ Ուղղեք երթուղին Service-ի VIP-ին կամ հանգույցի հասցեի, որը մնում է տեղում, կամ ընդունեք, որ յուրաքանչյուր վտարումից հետո կհետապնդեք դարպասին։ Հակադարձ ուղու զտումը մյուս թակարդն է. խիստ ռեժիմը մերժում է փաթեթները, որոնց վերադարձի ուղին չի համապատասխանում այն ինտերֆեյսին, որով նրանք եկել են, և դա հենց պահպանված VPN հոսքի ձևն է։
Թույլ վալիդացիան հաճախ տարբերությունն է աշխատող վերադարձի ուղու և այն պատասխանների միջև, որոնք անհետանում են backend-ից դուրս գալուց հետո։ VPN հանգույցի masquerade կանոնները նույնպես պետք է բացառեն թունելի տիրույթը, այլապես փոխանցված փաթեթը դուրս է գալիս պոդի հասցեով, անկախ նրանից, թե ինչ երթուղի եք կառուցել։ Ավելի լավ է այդ բացառությունը արտահայտել հենց CNI-ի կոնֆիգուրացիայում, քան ձեռքով խմբագրել iptables-ը, որովհետև գործակալը վերագործարկման ժամանակ վերաշարադրում է իր շղթաները, և ձեր ձեռքով գրված կանոնը գոյատևում է ուղիղ մինչև հաջորդ թարմացումը։
NetworkPolicy-ը մուտքի վերահսկում է, ոչ թե երթուղավորում։ Քաղաքականությունը խստացնելը երբեք չի վերականգնի հասցե, որը masquerade-ն արդեն փոխարինել է։
Ինչ արժե SNAT-ը, և ինչպես այն գրի առնել
Դեպի կլաստեր աղբյուրի NAT-ը ավելի էժան ձևավորում է, և դա սխալ չէ։ Backend-ը տեսնում է VPN պոդի կամ հանգույցի հասցեն, գրանցամատյանները համընկնում են միմյանց հետ, և վերադարձի երթուղի պետք չէ, որ գոյություն ունենա։ Ինչ կորցնում եք, երկու հաճախորդներին ցանցային մակարդակում տարբերելու ունակությունն է, ուստի քվոտաները, արգելքները և աուդիտի հետքերը պետք է գան այլ տեղից։
Սովորաբար այդ այլ տեղը հավելվածն է. սեսիայի թոքեն, ստորագրված վերնագիր կամ PROXY արձանագրության տող, որը գրում է ձեր կողմից վերահսկվող պրոքսին։ Դրանք ստացողին տալիս են ինքնություն, որին նա կարող է վստահել միայն այն ժամանակ, երբ պրոքսին գտնվում է ուղու վրա և վերնագիրը հնարավոր չէ սահմանել հաճախորդի կողմից։ Եղեք հստակ runbook-ում, թե որն է կիրառվում, որովհետև հաջորդ ինժեները կենթադրի, որ գրանցամատյանում եղած հասցեն հաճախորդն է։ Այդպես չէ, և մեկ միջադեպը բավական է, որպեսզի այդ ենթադրությունը թանկ դառնա։
Փոխանակումը մնում է ազնիվ, քանի դեռ այն գրի է առնված։
Ստուգումներ, որոնք առանձնացնում են աշխատող ուղին հաջողակից
Փորձարկեք թարմ կապով, ոչ թե քեշավորվածով, և փորձարկեք երկու ուղղություններով։ Մի քանի խափանումներ թվում են ընդհատվող միայն այն պատճառով, որ նոր հոսքերը գնում են վերաշարադրված ուղիով։
Բռնեք tuple-ը երեք կետում մեկ լիազորված հարցման ընթացքում. ապակոդավորումից անմիջապես հետո, VPN պոդի ելքի ինտերֆեյսում և backend-ում։ Եթե աղբյուրը փոխվում է երկրորդ և երրորդ բռնելու միջև, պատճառը պոդից ներքև է։ Եթե փոխվում է երկրորդից առաջ, պոդն ինքն է թարգմանում։
Ապա ջնջեք VPN պոդը և կրկնեք թեստը, մինչ այն վերապլանավորվում է։ Պահպանված ուղին, որը կոտրվում է վտարման ժամանակ, անավարտ է, և նույնը վերաբերում է NAT կանոնին, որը կապված է այլևս գոյություն չունեցող հասցեին։ Վերջում ուղարկեք մեկ հարցում մի աղբյուրից, որից ակնկալում եք մերժում, և հաստատեք, որ մերժումը գալիս է քաղաքականությունից, ոչ թե բացակայող երթուղուց։