Kubernetes තුළ VPN සේවාලාභී IP: එය සුරකින්නද නැතිනම් SNAT කරන්නද?
Kubernetes තුළ VPN සේවාලාභියාගේ සැබෑ ලිපිනය සුරකිනවාද නැතිනම් මූලාශ්‍ර NAT භාවිත කරනවාද යන්න කොන්දේසි තුනක් මත තෝරන්න, පසුව ආපසු මාර්ගය සහ pod වෙනස්වීම පරීක්ෂා කරන්න.
කොහේ හරි ටනලය සහ backend අතර සේවාලාභියාගේ ලිපිනය එක්කෝ ඉතිරි වේ, එක්කෝ ප්‍රතිස්ථාපනය වේ, දෙකම ආරක්ෂා කළ හැකි ප්‍රතිඵල වේ. තේරීම ලැබෙන සේවාවේ හිමිකරුට අයත් වේ, CNI ස්ථාපනය කළ තැනැත්තාට නොවේ. එක් එක් සේවාලාභියා සඳහා අවසරය, කෝටා හෝ විගණන වාර්තා වැදගත් වන විට, ලිපිනය සෑම පියවරක්ම ඉතිරි විය යුතුය. හවුල් ආරෝපණය පිළිගත හැකි වන විට, මූලාශ්‍ර NAT ඔබ නොමැති නම් සදහටම නඩත්තු කරන මාර්ගගත කිරීමේ ගැටලුවක් ඉවත් කරයි.
ලිපිනය සැබවින්ම අතුරුදන් වන්නේ කොහේද
දුර සිටින සේවාලාභියාගේ පැකට්ටුව VPN pod වෙත ළඟා වේ, ටනල පරාසය තුළ ඇති අභ්‍යන්තර මූලාශ්‍රයක් සමඟ, කියමු 10.90.0.42. pod එම පැකට්ටුව ClusterIP හෝ pod IP දෙසට යවන විට, විවිධ යාන්ත්‍රණ තුනකට මූලාශ්‍රය නැවත ලිවිය හැක. node හි CNI masquerade නියමය pod ක්ලස්ටර් CIDR ට පිටතට යවන ගමනාගමනය ආවරණය කරයි. ගමනාන්ත node හි kube-proxy හි conntrack සටහන Service පියවරම ආවරණය කරයි. සම්බන්ධතාවය අවසන් කරන proxy පැකට්ටුව කිසිසේත් යවන්නේ නැත, එබැවින් අවසානයේ ඔබ දකින මූලාශ්‍රය proxy ට අයත් වේ.
ඒවායින් එකක් එක් එක් ස්තරයක ජීවත් වේ, ඒ නිසා එක් Service ක්ෂේත්‍රයක් පාහේ කිසිදා සම්පූර්ණ මාර්ගය නිවැරදි නොකරයි.
VPN හි පොදු Service මත externalTrafficPolicy තීරණය කරන්නේ බාහිර සම්බන්ධතාවයට සිදුවන දේ පමණි: Local දුර ලිපිනය එය ලබාගත් node මත තබා ගනී, Cluster kube-proxy ට පැකට්ටුව තවත් node එකකට දී එහි masquerade කිරීමට ඉඩ දෙයි. එම සැකසුම ඔබේ සේවාලාභීන් සම්බන්ධ වන listener එක පාලනය කරයි. ඔබේ 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 සංස්කරණය නොවේ. තුන්වන පේළිය proxy යැයි කියන්නේ නම්, ලිපිනය කිසිදා ඉතිරි නොවන්නට තිබුණි, ඊට විරුද්ධව කියනවා සතියක පැකට් ග්‍රහණයක් වැය කරයි.
preserve මාදිලිය ජාලයෙන් ඉල්ලා සිටින දේ
මූලාශ්‍රය සුරැකීම යනු ගමනාන්ත node ගමනාගමනය සක්‍රීය 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 එකකට හෝ තැනම රැඳී සිටින node ලිපිනයකට හරවන්න, නැතහොත් සෑම බැහැර කිරීමකින් පසු ඔබ ද්වාරය පසුපස දුවන බව පිළිගන්න. ප්‍රතිලෝම මාර්ග පෙරීම අනෙක් උගුලයි: දැඩි මාදිලිය පැමිණි අතුරුමුහුණතට නොගැලපෙන ආපසු මාර්ගයක් ඇති පැකට්ටු ඉවත දමයි, එය හරියටම සුරකින ලද VPN ප්‍රවාහයේ හැඩයයි.
ලිහිල් සත්‍යාපනය බොහෝ විට ක්‍රියාකාරී ආපසු මාර්ගයක් සහ backend හැර යාමෙන් පසු අතුරුදන් වන පිළිතුරු අතර වෙනසයි. VPN node හි masquerade නියම ද ටනල පරාසය බැහැර කළ යුතුය, එසේ නොවුනහොත් යවන ලද පැකට්ටුව pod ලිපිනය සමඟම පිටවේ, ඔබ කුමන මාර්ගයක් ගොඩනැගුවද. මෙම බැහැර කිරීම iptables අතින් සංස්කරණය කිරීම වෙනුවට CNI හිම කොන්ෆිගරේෂන් තුළ ප්‍රකාශ කරන්න, මන්ද නියෝජිතයා නැවත ආරම්භයේදී එහි දාම නැවත ලියන අතර ඔබේ අතින් ලියූ නියමය හරියටම ඊළඟ උත්ශ්‍රේණි කිරීම දක්වා පවතී.
NetworkPolicy ප්‍රවේශ පාලනයයි, මාර්ගගත කිරීම නොවේ. ප්‍රතිපත්තියක් දැඩි කිරීමෙන් masquerade දැනටමත් ප්‍රතිස්ථාපනය කළ ලිපිනයක් කිසිදා ප්‍රතිසාධනය නොවේ.
SNAT හි පිරිවැය කුමක්ද, එය ලියා තබන්නේ කෙසේද
ක්ලස්ටරය දෙසට මූලාශ්‍ර NAT ලාභදායී සැලසුමයි, එය වැරැද්දක් නොවේ. backend දකින්නේ VPN pod හෝ node ලිපිනයයි, ලොග එකිනෙකට ගැලපේ, ආපසු මාර්ගයක් තිබිය යුතු නැත. ඔබට අහිමි වන්නේ ජාල ස්තරයේ සේවාලාභීන් දෙදෙනෙකු වෙන් කර හඳුනා ගැනීමේ හැකියාවයි, එබැවින් කෝටා, තහනම් සහ විගණන සලකුණු වෙනත් තැනකින් පැමිණිය යුතුය.
සාමාන්‍යයෙන් එම වෙනත් තැන යනු යෙදුමයි: සැසි ටෝකනයක්, අත්සන් කළ ශීර්ෂයක්, හෝ ඔබ පාලනය කරන proxy එකක් ලියන PROXY ප්‍රොටොකෝල් පේළියක්. මේවා ලබන්නාට විශ්වාස කළ හැකි අනන්‍යතාවක් දෙන්නේ proxy මාර්ගයේ සිටින විට සහ ශීර්ෂය සේවාලාභී පැත්තෙන් සැකසිය නොහැකි විට පමණි. runbook තුළ කුමක් අදාළ වේදැයි පැහැදිලිව සඳහන් කරන්න, මන්ද ඊළඟ ඉංජිනේරුවා ලොගයේ ඇති ලිපිනය සේවාලාභියා යැයි උපකල්පනය කරනු ඇත. එය එසේ නොවේ, එක් සිදුවීමක් එම උපකල්පනය මිල අධික කිරීමට ප්‍රමාණවත්ය.
මෙම හුවමාරුව ලියා ඇති තාක් කල් අවංකව පවතී.
ක්‍රියාකාරී මාර්ගයක් වාසනාවන්ත මාර්ගයකින් වෙන් කරන පරීක්ෂණ
නැවුම් සම්බන්ධතාවයකින් පරීක්ෂා කරන්න, හැඹිලිගත සම්බන්ධතාවයකින් නොවේ, දිශා දෙකෙන්ම පරීක්ෂා කරන්න. බොහෝ අසාර්ථකතා කලින් කල ලෙස පෙනෙන්නේ නව ප්‍රවාහ නැවත ලියූ මාර්ගය ගන්නා නිසා පමණි.
එක් අවසර ලත් ඉල්ලීමක් අතරතුර tuple ලක්ෂ්‍ය තුනකින් ග්‍රහණය කරන්න: විසංකේතනයෙන් පසු වහාම, VPN pod හි පිටවීම් අතුරුමුහුණතේ, සහ backend මත. මූලාශ්‍රය දෙවන සහ තුන්වන ග්‍රහණය අතර වෙනස් වන්නේ නම්, හේතුව pod ට පහළින් පවතී. දෙවැන්නට පෙර වෙනස් වන්නේ නම්, pod ම පරිවර්තනය කරයි.
පසුව VPN pod මකා දමා නැවත සැලසුම් වන අතරතුර පරීක්ෂණය නැවත කරන්න. බැහැර කිරීමේදී කැඩෙන සුරකින ලද මාර්ගය අසම්පූර්ණය, එසේම තවදුරටත් නොපවතින ලිපිනයකට ඇමිණූ NAT නියමයද. අවසානයේ, ප්‍රතික්ෂේප වනු ඇතැයි ඔබ බලාපොරොත්තු වන මූලාශ්‍රයකින් ඉල්ලීමක් යවා ප්‍රතික්ෂේපය ප්‍රතිපත්තියෙන් පැමිණෙන බවත්, නැතිවූ මාර්ගයකින් නොවන බවත් තහවුරු කරන්න.