Kubernetes માં VPN ક્લાયન્ટ IP: તેને સાચવવો કે SNAT કરવું?
Kubernetes માં VPN ક્લાયન્ટના વાસ્તવિક સરનામા અને સ્રોત NAT વચ્ચે ત્રણ શરતોના આધારે પસંદ કરો, પછી પરત માર્ગ અને pod ફેરફાર ચકાસો.
ક્યાંક ટનલ અને backend વચ્ચે ક્લાયન્ટનું સરનામું ક્યાં તો ટકી રહે છે અથવા બદલાઈ જાય છે, અને બંને પરિણામો વાજબી છે. પસંદગી પ્રાપ્ત કરતી સેવાના માલિકની છે, CNI સ્થાપિત કરનારની નહીં. જ્યારે પ્રતિ-ક્લાયન્ટ અધિકૃતિ, કોટા અથવા ઓડિટ રેકોર્ડ મહત્વના હોય, ત્યારે સરનામું દરેક હોપ પસાર કરવું પડે. જ્યારે સહિયારું આરોપણ સ્વીકાર્ય હોય, ત્યારે સ્રોત NAT એ રાઉટિંગ સમસ્યા દૂર કરે છે જે અન્યથા તમે કાયમ સાચવતા.
સરનામું ખરેખર ક્યાં અદૃશ્ય થાય છે
દૂરના ક્લાયન્ટનું પેકેટ VPN pod સુધી ટનલ શ્રેણીની અંદર આંતરિક સ્રોત સાથે પહોંચે છે, ધારો કે 10.90.0.42. જ્યારે pod તે પેકેટને ClusterIP અથવા pod IP તરફ આગળ મોકલે છે, ત્યારે ત્રણ જુદી વ્યવસ્થાઓ સ્રોતને ફરીથી લખી શકે છે. નોડનો CNI masquerade નિયમ તે ટ્રાફિકને આવરે છે જે pod ક્લસ્ટર 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 મોડ નેટવર્ક પાસેથી શું માંગે છે
સ્રોત સાચવવાનો અર્થ છે કે લક્ષ્ય નોડે ટ્રાફિક સક્રિય VPN ગેટવે દ્વારા 10.90.0.42 પર પાછો મોકલવો પડે. 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તે આગળનો હોપ pod નું સરનામું છે, અને pod નાં સરનામાં ખસે છે. માર્ગને Service VIP અથવા સ્થિર રહેતા નોડ સરનામા તરફ વાળો, અથવા સ્વીકારો કે દરેક બહિષ્કાર પછી તમે ગેટવે પાછળ દોડશો. ઊલટા માર્ગનું ફિલ્ટરિંગ બીજી ફાંસો છે: કડક મોડ તે પેકેટ કાઢી નાખે છે જેમનો પરત માર્ગ જે ઇન્ટરફેસ પરથી આવ્યા તેની સાથે મેળ ખાતો નથી, અને આ બરાબર સાચવેલા VPN પ્રવાહનો આકાર છે.
ઢીલી ચકાસણી ઘણી વાર કાર્યરત પરત માર્ગ અને backend છોડ્યા પછી અદૃશ્ય થતા જવાબો વચ્ચેનો ફરક હોય છે. VPN નોડ પરના masquerade નિયમોએ પણ ટનલ શ્રેણી બાકાત રાખવી પડે, નહીં તો આગળ મોકલેલું પેકેટ pod ના સરનામા સાથે જ નીકળશે, તમે ગમે તે માર્ગ બનાવો. આ બાકાત iptables હાથથી સંપાદિત કરવાને બદલે CNI ના પોતાના રૂપરેખાંકનમાં વ્યક્ત કરો, કારણ કે એજન્ટ પુનઃપ્રારંભ વખતે તેની સાંકળો ફરી લખે છે અને તમારો હાથે લખેલો નિયમ બરાબર આગલા અપગ્રેડ સુધી ટકે છે.
NetworkPolicy પ્રવેશ નિયંત્રણ છે, રાઉટિંગ નથી. નીતિ કડક કરવાથી masquerade પહેલેથી બદલી નાખેલું સરનામું કદી પુનઃસ્થાપિત થશે નહીં.
SNAT નો શું ખર્ચ છે, અને તેને કેવી રીતે લખવું
ક્લસ્ટર તરફ સ્રોત NAT સસ્તું ડિઝાઇન છે, અને તે ભૂલ નથી. backend VPN pod કે નોડનું સરનામું જુએ છે, લોગ એકબીજા સાથે મેળ ખાય છે, અને કોઈ પરત માર્ગ હોવો જરૂરી નથી. તમે જે ગુમાવો છો તે નેટવર્ક સ્તરે બે ક્લાયન્ટને અલગ પાડવાની ક્ષમતા છે, તેથી કોટા, પ્રતિબંધો અને ઓડિટ નિશાનો બીજે ક્યાંકથી આવવા જોઈએ.
સામાન્ય રીતે તે બીજે ક્યાંક એટલે એપ્લિકેશન: સત્ર ટોકન, સહી કરેલો હેડર, અથવા PROXY પ્રોટોકોલની લાઇન જે તમારા નિયંત્રણ હેઠળની પ્રોક્સી લખે છે. આ પ્રાપ્તકર્તાને એવી ઓળખ આપે છે જેના પર તે ફક્ત ત્યારે જ ભરોસો કરી શકે જ્યારે પ્રોક્સી માર્ગ પર હોય અને હેડર ક્લાયન્ટ તરફથી સેટ કરી શકાય નહીં. runbook માં સ્પષ્ટ કહો કે કઈ લાગુ પડે છે, કારણ કે આગલો ઇજનેર ધારશે કે લોગમાંનું સરનામું ક્લાયન્ટ છે. એવું નથી, અને એક ઘટના તે ધારણાને મોંઘી બનાવવા માટે પૂરતી છે.
આ અદલાબદલી ત્યાં સુધી પ્રામાણિક રહે છે જ્યાં સુધી લખેલી રહે.
કાર્યરત માર્ગને નસીબદાર માર્ગથી અલગ પાડતી ચકાસણીઓ
તાજા કનેક્શનથી ચકાસો, કેશ થયેલા કનેક્શનથી નહીં, અને બંને દિશામાં ચકાસો. ઘણી નિષ્ફળતાઓ ફક્ત એટલા માટે અટકી-અટકીને લાગે છે કારણ કે નવા પ્રવાહ ફરી લખેલો માર્ગ લે છે.
એક અધિકૃત વિનંતી દરમિયાન tuple ત્રણ બિંદુઓ પર પકડો: ડિક્રિપ્શન પછી તરત, VPN pod ના નિકાસ ઇન્ટરફેસ પર, અને backend પર. જો સ્રોત બીજી અને ત્રીજી પકડ વચ્ચે બદલાય, તો કારણ pod ની નીચે છે. જો બીજી પહેલાં બદલાય, તો pod પોતે ભાષાંતર કરે છે.
પછી VPN pod ડિલીટ કરો અને ફરી-ગોઠવણી દરમિયાન પરીક્ષણ ફરીથી કરો. બહિષ્કારમાં તૂટતો સાચવેલો માર્ગ અધૂરો છે, અને તે NAT નિયમ પણ જે હવે અસ્તિત્વમાં ન હોય તેવા સરનામા સાથે બંધાયેલો હોય. અંતે એવા સ્રોતથી એક વિનંતી મોકલો જેનો અસ્વીકાર અપેક્ષિત હોય અને ખાતરી કરો કે અસ્વીકાર નીતિમાંથી આવે છે, ગુમ થયેલા માર્ગથી નહીં.