Kubernetes හි OpenVPN pod එකක් කිසිවක් ඉදිරියට නොයවයිද? ip_forward පරීක්ෂා කරන්න

ඔබේ ලැප්ටොප් එක හරිත උමගක් පෙන්වයි, සේවාදායක ලොගය කියන්නේ මාර්ග තල්ලු කර ඇති බවයි, සහ පිළිතුරු දෙන එකම ලිපිනය VPN සේවාදායකයේම උමං IP ය. එයින් ඔබ්බට ping ඔබ ඉලක්ක කරන දේ කුමක් වුවත් මිය යයි, එය ClusterIP එකක් වුවත්, වෙනත් pod එකක ලිපිනයක් වුවත්, හෝ පොදු සත්කාරක නාමයක් වුවත්. එම සංයෝගය අපැහැදිලි නොවේ, රෝග විනිශ්චයක් ය: විකේතනය ක්රියා කරයි, දෙවන පිම්ම ක්රියා නොකරයි.

chart මගින් ස්ථාපනය කළ OpenVPN රූපයක් ධාවනය කරන Debian නෝඩයක මට මෙය හමු විය, සහ උමඟ පහසු කොටස විය. සේවාදායකයා 10.8.0.x බද්දක් ගත්තේය, 10.8.0.1 පිළිතුරු දුන්නේය, සහ 10.96.0.10, පොකුරේ DNS සේවාව, කාලය ඉකුත් විය. සේවාදායක ලොගයේ කිසිවක් රෝගාතුර ලෙස පෙනුණේ නැත, සහ මිනිසුන් කිසිදා ස්පර්ශ කිරීමට අවශ්ය නොවූ iptables නීති නැවත ලිවීමට පටන් ගන්නේ එහෙයින්ය.

VPN pod එකක් යනු රවුටරයකි, සහ එය පැහැදිලිව කීම වටී. සංකේතනය කළ පැකට් පැමිණේ, pod එකේම ජාල namespace තුළ විවෘත වේ, පසුව වෙනත් අතුරුමුහුණතක් හරහා පිටවිය යුතුය. Linux එම දෙවන පියවර ප්රතික්ෂේප කරයි, එම namespace තුළම ඉදිරියට යැවීම සක්රීය නොවන්නේ නම්.

සේවාදායකයාට ළඟා විය හැකි දේ සහ නොහැකි දේ

පිළිතුරු දෙන ලිපිනය උමඟේ අන්ත ලක්ෂ්යයට අයත් වන අතර, VPN ක්රියාවලිය එය දේශීයව හිමිකර ගනී, එබැවින් ඉදිරියට යැවීම කිසිසේත් සම්බන්ධ නොවේ. අනෙක් සියල්ල, තවත් pod එකක්, සේවා VIP එකක් හෝ අන්තර්ජාලය ඇතුළුව, කර්නලයට පැකට් එකක් tun0 සිට eth0 දක්වා ගෙන යාම අවශ්ය වේ. එම ගෙන යාම ප්රතික්ෂේප වූ විට, රෝග ලක්ෂණය ප්රතික්ෂේපයක් නොව ඒකාකාර නිහඬතාවයකි, මන්ද උමඟ පහළට ආපසු ICMP දෝෂයක් කිසිවක් නිපදවන්නේ නැත. ඔබට කාල ඉකුත්වීම් ලැබේ, ළඟා නොවන පණිවිඩ නොවේ, සහ කිසිවෙකු කිසිසේත් මාර්ග නොකරන බවට එයයි සලකුණ.

මිනිත්තු දෙකක වර්ගීකරණය ස්තරය පටු කරයි. DNS නාම අසාර්ථක වන අතර සේවා IP එකකට අමු ping සාර්ථක වන්නේ නම්, ගැටලුව ඉදිරියට යැවීමේ නොව, DNS ජලනලයේ ය. peer ලිපිනයෙන් ඔබ්බට සෑම ගමනාන්තයක්ම කාලය ඉකුත් වන්නේ නම්, නිරුවත් IP එකක් ඇතුළුව, namespace එකෙන් පටන් ගන්න.

namespace තුළ ඇති සැකසුම කියවන්න

සෑම pod එකකටම තමන්ගේම ජාල namespace එකක් ලැබේ, සහ net.ipv4.ip_forward යනු සෑම namespace එකකටම sysctl එකකි. නෝඩයේ එය වෙනස් කිරීම බහාලුම ගැන කිසිවක් නොකියයි, සහ වැරදි යන්ත්රයේ සවසක් ගත කිරීමට එය විශ්වාසදායක මාර්ගයකි.

kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0

ශුන්යය රෝග විනිශ්චය තහවුරු කරයි. අගය නෝඩයේ ධාවන වින්යාසයෙන්ද උරුම නොවේ: බහාලුමක් සෑදූ සෑම විටම එය රූපයේ පෙරනිමියෙන් ආරම්භ වේ. එබැවින් kubectl exec ... sysctl -w සමඟ අතින් යෙදූ නිවැරදි කිරීම ඊළඟ නැවත ආරම්භයේදී අතුරුදහන් වී ඉඳහිට පෙනෙන දෝෂයක් ලෙස ආපසු පැමිණේ.

manifest එය රඳවා ගන්නා පරිදි සක්රීය කිරීම

කල් පවතින විකල්පය වන්නේ එම pod sandbox තුළ ධාවනය වන සහ VPN බහාලුම ආරම්භ වීමට පෙර අගය ලියන init බහාලුමකි. pod එකක බහාලුම් එකම ජාල namespace එකක් බෙදා ගනී, එබැවින් සැකසුම ප්රධාන බහාලුමට ගෙන යයි.

initContainers:
- name: enable-forwarding
  image: busybox:1.36
  command: ["sysctl", "-w", "net.ipv4.ip_forward=1"]
  securityContext:
    privileged: true

එම privileged: true යනු සමාලෝචකයන් විරුද්ධ වන පේළියයි, සහ ඔවුන් නිවැරදිය. sysctl එකක් ලිවීමට වරප්රසාදයක් හෝ පටු ව්යාප්තියක් ඇති හැකියාවක් අවශ්ය වේ, සහ සීමිත Pod Security Standard ධාවනය කරන පොකුරක් වරප්රසාද ලත් init බහාලුමක් සම්පූර්ණයෙන්ම ප්රතික්ෂේප කළ හැකිය. admission pod එක ප්රතික්ෂේප කරන්නේ නම්, එය නිර්මාණය වන විටම දැන ගනී, එය අවම වශයෙන් අවංක සහ කියවීමට පහසුය.

වඩා පිරිසිදු විකල්පය වන්නේ pod මට්ටමේ securityContext.sysctls ලැයිස්තුවයි, එය kubelet ට කිසිදු බහාලුමකට වරප්රසාද නොදී namespace සහිත sysctl යෙදීමට ඉඩ දෙයි. එය පොකුරේ අවසර ලැයිස්තුවේ ඇති නාම පමණක් ආවරණය කරයි. net.ipv4.ip_forward එම ලැයිස්තුවේ තිබේද යන්න රඳා පවතින්නේ kubelet වින්යාස කළ ආකාරය මතය, සහ ඉන් පිටත sysctl ඉල්ලන pod එකක් admission හි ප්රතික්ෂේප වේ හෝ sandbox නැවත උත්සාහ කරන අතරතුර CreateContainerConfigError හි සිරවේ. ක්ෂේත්රය කැඩී ඇතැයි උපකල්පනය කිරීමට පෙර අවසර ලැයිස්තුව පරීක්ෂා කරන්න.

ක්රම දෙකෙන් එකක් අතින් තැනීමට පෙර, chart දැනටමත් ස්විචය නිරාවරණය කරන්නේදැයි බලන්න, බොහෝ විට ipForwardInitContainer: true වැනි දෙයක් ලෙස. chart අගය භාවිතා කිරීම ඔබේ override ගොනුව කුඩාවට තබා ඊළඟ උත්ශ්රේණි කිරීම ජය ගනී, අතින් පැච් කළ Deployment වෙනස්කම් එය නොකරයි.

දෙවන භාගය: ආපසු මාර්ගය සහ ප්රතිපත්තිය

ඉදිරියට යැවීම සක්රීය වීම අවශ්යය, ප්රමාණවත් නොවේ. සේවාදායකයන් පොකුරු ජාලයට මාර්ගයක් නැති පෞද්ගලික තටාකයක් භාවිතා කරන්නේ නම්, පිළිතුරු උමඟට ආපසු මාර්ගය සොයා ගත නොහැක, සහ pod එක එම ගමනාගමනය එහි ගමනාන්තය දෙසට ආවරණය කළ යුතුය.

ප්රතිපත්තිය ඊට ඉහළින් වාඩි වේ. NetworkPolicy වස්තූන් සහ ක්ලවුඩ් ෆයර්වෝල් නීති ඇගයෙන්නේ පරිවර්තනයෙන් පසු පැකට් එකක් දරන මූල ලිපිනයට එරෙහිව ය, එබැවින් සේවාදායක තටාකය සඳහා ලියූ නීතියක් ආවරණය සක්රීය වූ පසු නිහඬව ගැලපීම නතර කළ හැකිය.

සේවාදායකයන්ට පොකුර තුළ ඇති සේවා වෙත පමණක් ළඟා විය යුතු විට, VPN එක සේවා VIP එකේ අවසන් කිරීම pod ජාලයට මාර්ග කිරීමට වඩා කුඩා නිර්මාණයකි. එය සේවාදායක තටාකය CNI හි මාර්ග සටහනින් සම්පූර්ණයෙන්ම පිටත තබයි.

අසාර්ථක පිම්ම සේවාදායකයාගෙන් හුදකලා කිරීම

පිටතට වැඩ කරන්න සහ පළමු නිහඬ පියවරේදී නවතින්න. VPN peer එකෙන් පටන් ගන්න, පසුව යම් pod එකක ලිපිනය උත්සාහ කරන්න, පසුව සේවා VIP එකක්, සහ ඉන් පසුව පමණක් පොදු ගමනාන්තයක්. සෑම සාර්ථකත්වයක්ම මායිම පිම්මක් ගෙන යයි, සහ සෑම අසාර්ථකත්වයක්ම පරීක්ෂා කිරීම වටිනා ස්තරය නම් කරයි. ඕනෑම දියත් කිරීමකින් පසු exec කර ඇතුළට ගොස් sysctl නැවත කියවන්න, මන්ද ප්රතිස්ථාපනය කළ pod එකක් රූපයේ පෙරනිමියෙන් ආරම්භ වන අතර manifest එකේ කිසිදා නොතිබූ නිවැරදි කිරීමක් දැනටමත් ගොස් ඇත.

Kubernetes ලේඛනය පොකුරක sysctl භාවිතය පිළිබඳව pod ආරක්ෂක සන්දර්භය හරහා සැකසිය හැකි නාම ලැයිස්තුගත කරයි, සහ admission වෙනස්කම් ප්රතික්ෂේප කරන විට මුලින්ම බැලිය යුතු තැන එයයි.