Kubernetes இல் OpenVPN pod எதையும் அனுப்பவில்லையா? ip_forward ஐ சரிபார்க்கவும்
வாடிக்கையாளர்கள் VPN pod-ஐ ping செய்கிறார்கள், அதற்கு அப்பால் எதுவும் இல்லை. namespace இல் அனுப்புதல் அணைக்கப்பட்டுள்ளது, மேலும் சரிசெய்தல் admission, மறுதொடக்கம் மற்றும் திரும்பும் பாதையை கடக்க வேண்டும்.
உங்கள் மடிக்கணினி பச்சை சுரங்கத்தைக் காட்டுகிறது, வாடிக்கையாளர் பதிவு பாதைகள் தள்ளப்பட்டதாகக் கூறுகிறது, மேலும் பதிலளிக்கும் ஒரே முகவரி VPN சேவையகத்தின் சொந்த சுரங்க IP. அதற்கு அப்பால் உள்ள ping நீங்கள் எதை இலக்காகக் கொண்டாலும் இறக்கின்றன, அது ClusterIP ஆகவோ, மற்றொரு pod இன் முகவரியாகவோ அல்லது பொது ஹோஸ்ட்பெயராகவோ இருந்தாலும். இந்தக் கலவை தெளிவற்றதல்ல, நோயறிதல் ஆகும்: டீகேப்சுலேஷன் வேலை செய்கிறது, இரண்டாவது தாவல் செய்யவில்லை.
chart மூலம் நிறுவப்பட்ட OpenVPN இமேஜை இயக்கும் Debian node இல் இதைக் கண்டேன், சுரங்கம் எளிதான பகுதியாக இருந்தது. வாடிக்கையாளர் 10.8.0.x குத்தகையைப் பெற்றார், 10.8.0.1 பதிலளித்தது, 10.96.0.10, cluster 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 ஆகும். node இல் அதை மாற்றுவது கொள்கலனைப் பற்றி எதையும் சொல்லாது, தவறான இயந்திரத்தில் பிற்பகலைக் கழிக்க இது நம்பகமான வழி.
kubectl exec -it deploy/openvpn -- sysctl net.ipv4.ip_forward
# net.ipv4.ip_forward = 0
பூஜ்ஜியம் நோயறிதலை உறுதிப்படுத்துகிறது. மதிப்பு node இன் இயக்க நேர கட்டமைப்பிலிருந்தும் வாரிசாக வரவில்லை: கொள்கலன் உருவாக்கப்படும் ஒவ்வொரு முறையும் அது இமேஜின் இயல்புநிலையிலிருந்து தொடங்குகிறது. எனவே 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 இயக்கும் cluster சிறப்புரிமை பெற்ற init கொள்கலனை முற்றிலும் மறுக்கலாம். admission pod ஐ மறுத்தால், உருவாக்கும் நேரத்திலேயே தெரியும், அது குறைந்தபட்சம் நேர்மையானது மற்றும் படிக்க எளிதானது.
தூய்மையான மாற்று pod நிலை securityContext.sysctls பட்டியல், இது எந்தக் கொள்கலனுக்கும் சிறப்புரிமை வழங்காமல் kubelet இற்கு namespace sysctl களைப் பயன்படுத்த அனுமதிக்கிறது. இது cluster இன் அனுமதிப்பட்டியலில் உள்ள பெயர்களை மட்டுமே உள்ளடக்குகிறது. net.ipv4.ip_forward அந்தப் பட்டியலில் உள்ளதா என்பது kubelet எவ்வாறு கட்டமைக்கப்பட்டது என்பதைப் பொறுத்தது, அதற்கு வெளியே sysctl கேட்கும் pod admission இல் மறுக்கப்படும் அல்லது sandbox மீண்டும் முயற்சிக்கும்போது CreateContainerConfigError இல் சிக்கும். புலம் உடைந்துவிட்டது என்று கருதுவதற்கு முன் அனுமதிப்பட்டியலைச் சரிபார்க்கவும்.
இரு அணுகுமுறைகளில் ஒன்றைக் கையால் உருவாக்குவதற்கு முன், chart ஏற்கனவே சுவிட்சை வெளிப்படுத்துகிறதா என்று பாருங்கள், பெரும்பாலும் ipForwardInitContainer: true போன்ற ஒன்றாக. chart மதிப்பைப் பயன்படுத்துவது உங்கள் override கோப்பைச் சிறியதாக வைத்து அடுத்த மேம்படுத்தலைக் கடக்கிறது, கையால் பேட்ச் செய்யப்பட்ட Deployment மாற்றங்கள் அதைச் செய்வதில்லை.
இரண்டாம் பாதி: திரும்பும் பாதை மற்றும் கொள்கை
அனுப்புதல் இயக்கத்தில் இருப்பது அவசியம், போதுமானதல்ல. வாடிக்கையாளர்கள் cluster நெட்வொர்க்கிற்கு வழி இல்லாத தனியார் குளத்தைப் பயன்படுத்தினால், பதில்கள் சுரங்கத்திற்குத் திரும்பும் வழியைக் கண்டுபிடிக்காது, மேலும் pod அந்த ட்ராஃபிக்கை அதன் இலக்கை நோக்கி மறைக்க வேண்டும்.
கொள்கை அதன் மேல் அமர்ந்துள்ளது. NetworkPolicy பொருட்கள் மற்றும் கிளவுட் ஃபயர்வால் விதிகள் மொழிபெயர்ப்புக்குப் பிறகு பாக்கெட் சுமக்கும் மூல முகவரிக்கு எதிராக மதிப்பிடப்படுகின்றன, எனவே வாடிக்கையாளர் குளத்திற்காக எழுதப்பட்ட விதி மறைத்தல் இயக்கப்பட்டதும் அமைதியாகப் பொருந்துவதை நிறுத்தலாம்.
வாடிக்கையாளர்கள் cluster இற்குள் உள்ள சேவைகளை மட்டும் அடைய வேண்டியிருந்தால், VPN ஐ சேவை VIP இல் முடிப்பது pod நெட்வொர்க்கிற்கு வழிமாற்றம் செய்வதை விடச் சிறிய வடிவமைப்பு. இது வாடிக்கையாளர் குளத்தை CNI இன் வழிமாற்ற அட்டவணையிலிருந்து முற்றிலும் வெளியே வைக்கிறது.
தோல்வியடையும் தாவலை வாடிக்கையாளரிடமிருந்து தனிமைப்படுத்துதல்
வெளிப்புறமாக வேலை செய்து முதல் அமைதியான படியில் நிறுத்துங்கள். VPN peer இலிருந்து தொடங்கி, பின்னர் ஏதேனும் pod இன் முகவரியை முயற்சிக்கவும், பின்னர் சேவை VIP, அதன் பிறகே பொது இலக்கு. ஒவ்வொரு வெற்றியும் எல்லையை ஒரு தாவல் நகர்த்துகிறது, ஒவ்வொரு தோல்வியும் பரிசீலிக்கத் தகுந்த அடுக்கைப் பெயரிடுகிறது. எந்தவொரு வெளியீட்டிற்குப் பிறகும் exec செய்து உள்ளே சென்று sysctl ஐ மீண்டும் படியுங்கள், ஏனெனில் மாற்றப்பட்ட pod இமேஜின் இயல்புநிலையிலிருந்து தொடங்குகிறது, manifest இல் ஒருபோதும் இல்லாத சரிசெய்தல் ஏற்கனவே போய்விட்டது.
Kubernetes ஆவணம் cluster இல் sysctl பயன்பாடு பற்றி எந்தப் பெயர்களை pod பாதுகாப்பு சூழல் மூலம் அமைக்கலாம் என்று பட்டியலிடுகிறது, admission மாற்றத்தை மறுக்கும்போது முதலில் பார்க்க வேண்டிய இடம் அதுவே.