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 தாவலையே மூடுகிறது. இணைப்பை முடிக்கும் ப்ராக்ஸி பாக்கெட்டை அனுப்பவே செய்யாது, எனவே இறுதியில் நீங்கள் பார்க்கும் மூலம் ப்ராக்ஸிக்கு உரியது.
ஒவ்வொன்றும் வெவ்வேறு அடுக்கில் வாழ்கிறது, அதனால்தான் ஒரு 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 திருத்த வேலை அல்ல. மூன்றாவது வரிசை ப்ராக்ஸி என்று சொன்னால், முகவரி ஒருபோதும் தப்பிப்பிழைத்திருக்காது, அதற்கு மாறாகச் சொல்வது ஒரு வாரம் பாக்கெட் பிடிப்புச் செலவு.
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 நெறிமுறை வரி. இவை பெறுபவருக்கு, ப்ராக்ஸி பாதையில் இருக்கும்போதும் தலைப்பைக் கிளையண்ட் பக்கத்திலிருந்து அமைக்க முடியாதபோதும் மட்டுமே நம்பக்கூடிய அடையாளத்தைத் தருகின்றன. runbook-இல் எது பொருந்துகிறது என்பதைத் தெளிவாகக் கூறுங்கள், ஏனெனில் அடுத்த பொறியாளர் பதிவில் உள்ள முகவரியே கிளையண்ட் என்று கருதுவார். அது இல்லை, ஒரு சம்பவம் அந்தக் கருத்தை விலை உயர்ந்ததாக்கப் போதும்.
இந்தப் பரிமாற்றம் எழுதப்பட்டிருக்கும் வரை நேர்மையாகவே இருக்கும்.
வேலை செய்யும் பாதையை அதிர்ஷ்டமான பாதையிலிருந்து பிரிக்கும் சோதனைகள்
புதிய இணைப்புடன் சோதியுங்கள், தற்காலிகச் சேமிப்பில் உள்ள இணைப்புடன் அல்ல, இரண்டு திசைகளிலும் சோதியுங்கள். பல தோல்விகள் இடைவிட்டதாகத் தோன்றுவதற்குக் காரணம் புதிய ஓட்டங்கள் மீண்டும் எழுதப்பட்ட பாதையை எடுப்பதே.
ஒரு அங்கீகரிக்கப்பட்ட கோரிக்கையின் போது tuple-ஐ மூன்று இடங்களில் பிடியுங்கள்: மறைகுறியாக்கத்திற்குப் பிறகு உடனே, VPN pod-இன் வெளியேற்ற இடைமுகத்தில், மற்றும் backend-இல். இரண்டாவது மற்றும் மூன்றாவது பிடிப்புக்கு இடையே மூலம் மாறினால், காரணம் pod-க்குக் கீழே உள்ளது. இரண்டாவதற்கு முன் மாறினால், pod-தானே மொழிபெயர்க்கிறது.
பின்னர் VPN pod-ஐ நீக்கி, மறுஅட்டவணையின்போது சோதனையை மீண்டும் செய்யுங்கள். வெளியேற்றத்தில் உடையும் பாதுகாக்கப்பட்ட பாதை முழுமையற்றது, இப்போது இல்லாத முகவரியில் பொருத்தப்பட்ட NAT விதியும் அப்படியே. கடைசியாக, மறுக்கப்படும் என்று எதிர்பார்க்கும் மூலத்திலிருந்து ஒரு கோரிக்கையை அனுப்பி, மறுப்பு கொள்கையிலிருந்து வருகிறதா, காணாமல் போன வழியிலிருந்து அல்லவா என்பதை உறுதிசெய்யுங்கள்.