kubectl-ஆல் OpenVPN வழியாக தனியுரிமைக் கிளஸ்டரின் API-ஐ தீர்க்க முடியாது
இயங்கும் சுரங்கப்பாதை தனியுரிமை மண்டலத்தை தீர்க்கக்கூடியதாக ஆக்காது. VNet தீர்ப்பானை hosts அல்லது ஃபார்வர்டர் பதிவுகளுடன் அனுப்புவதை ஒப்பிடுங்கள், பின்னர் API முனைப்புள்ளியை சோதிக்கவும்.
சுரங்கப்பாதை இயங்கும்போது API-இன் தனியுரிமை முகவரி இன்னும் ping-க்கு பதிலளிக்கும்போது kubectl பெயர் தேடலில் தோல்வியடைகிறது. பாதை சரியாக உள்ளது; வாடிக்கையாளர் கிளஸ்டரின் தனியுரிமை மண்டலத்தைப் பற்றி ஒருபோதும் கேளாத ஒரு தீர்ப்பானிடம் கேட்கிறது. இரண்டு திருத்தங்கள் அதிகம் பயன்படுத்தப்படுகின்றன: மெய்நிகர் பிணையத்தின் தீர்ப்பானை ஒவ்வொரு VPN வாடிக்கையாளருக்கும் அனுப்புவது, அல்லது பெயரை உள்ளூரில் hosts பதிவு அல்லது நிபந்தனை ஃபார்வர்டர் மூலம் பின் செய்வது. இரண்டும் ஒரே அறிகுறியை வெவ்வேறு பொறுப்புடன் தீர்க்கின்றன, அவற்றை கலப்பதே குழுக்கள் ஒவ்வொரு முறையும் முனைப்புள்ளி மீண்டும் கட்டப்படும்போது hosts கோப்புகளைத் திருத்தக் காரணம்.
தீர்வும் அடைவும் வெவ்வேறு அடுக்குகளில் தோல்வியடைகின்றன
எதையும் மாற்றுவதற்கு முன் தேடலை நீங்களே இயக்குங்கள். Linux-இல் getent hosts அல்லது Windows-இல் nslookup வாடிக்கையாளருக்கு பதில் கிடைக்கிறதா என்று சொல்கிறது; நேரம் முடிவது அல்லது NXDOMAIN தீர்ப்பானைச் சுட்டுகிறது, தவறான முகவரியுடைய பதில் பழைய பதிவு அல்லது பொது வழியைச் சுட்டுகிறது.
பின்னர் kubectl உண்மையில் எந்த சேவையகத்துடன் இணைகிறது என்பதை உறுதிசெய்யுங்கள். kubeconfig சூழல் ஒரு URL-ஐ சேமிக்கிறது, VPN பாதை அதை மீண்டும் எழுதுவதில்லை: சூழல் பொது முனைப்புள்ளியைக் குறிப்பிட்டால் DNS சரியாக இருக்கலாம், கட்டளை இன்னும் தோல்வியடையும்.
getent hosts api.internal.example
kubectl config view --minify -o jsonpath='{.clusters[0].cluster.server}'
kubectl -v=8 get nodes 2>&1 | head -40
மூன்றாவது சமிக்ஞை தேடலுக்குப் பின் தோல்வியின் வடிவம். தனியுரிமை முகவரிக்குத் தீர்க்கப்பட்டு பின்னர் TCP நேரம் முடிவடையும் பெயர் தீப்பச்சை அல்லது அங்கீகரிக்கப்பட்ட பிணையப் பிரச்சினை. பொது முகவரிக்குத் தீர்க்கப்படும் பெயர் என்பது வினவல் தனியுரிமை மண்டலத்திலிருந்து வெளியேறியது என்று பொருள். இந்த மூன்று முடிவுகளையும் தனித்தனியாக வைத்திருங்கள்; ஒவ்வொன்றும் உங்களை வேறு பொறுப்பாளரிடம் அழைத்துச் செல்கிறது.
விருப்பம் A: மெய்நிகர் பிணையத்தின் தீர்ப்பானை சுரங்கப்பாதைக்குள் அனுப்புங்கள்
VPN சேவையகம் மெய்நிகர் பிணையத்திற்குள் இயங்கும்போது, வாடிக்கையாளர்கள் சேவையக ஹோஸ்ட் பயன்படுத்தும் அதே தீர்ப்பானைப் பயன்படுத்தலாம். OpenVPN Community-இல் சேவையகம் DNS விருப்பத்தை அனுப்புகிறது; Access Server அதே அமைப்பை நிர்வாக இடைமுகத்தில் காட்டுகிறது, மேலும் DNS வழிமுறை அதற்குள் பயணிப்பதால் வாடிக்கையாளர்கள் சுயவிவரத்தை மீண்டும் பதிவிறக்க வேண்டும்.
# server.conf
push "dhcp-option DNS 10.0.0.4"
push "route 10.0.0.4 255.255.255.255"
பாதை வரி split tunnel சுயவிவரங்களில் முக்கியம். தீர்ப்பான் முகவரியை அனுப்புவது அதை அடையக்கூடியதாக ஆக்குவதற்கு சமமில்லை: சுரங்கப்பாதை வழியாக கிளஸ்டரின் துணைப்பிணையம் மட்டும் சென்றால், 10.0.0.4-க்கான வினவல் உள்ளூர் LAN வழியாக வெளியேறி இறக்கிறது. தீர்ப்பானுக்கு ஹோஸ்ட் பாதையை அனுப்புங்கள், அல்லது அதன் துணைப்பிணையத்தை சுரங்கப்பாதையில் சேர்க்கவும்.
பெறும் பக்கத்திற்கும் கொள்கை உண்டு. வாடிக்கையாளரின் முகவரி வரம்பிலிருந்து அடையக்கூடிய தீர்ப்பான் அங்கிருந்து வரும் வினவல்களை இன்னும் மறுக்கலாம், மெய்நிகர் பிணையத்துடன் இணைக்கப்பட்ட தனியுரிமை மண்டலம் அந்த பிணையத்தின் DNS பாதை வழியாக வரும் வாடிக்கையாளர்களுக்கு மட்டுமே பதிலளிக்கிறது. அனுப்பியபின் தேடல் நேரம் முடிந்தால், வாடிக்கையாளரை மீண்டும் தொடுவதற்கு முன் தீர்ப்பானின் சொந்த பதிவுகளைப் பாருங்கள்.
வாடிக்கையாளரில் என்ன பயன்படுத்தப்பட்டது என்பதைச் சரிபார்க்கவும்: systemd-resolved Linux-இல் resolvectl status, macOS-இல் scutil --dns, Windows-இல் ipconfig /all. அனுப்பப்பட்ட DNS சேவையகம் ஒருபோதும் தெரியவில்லை என்றால் சுயவிவரம் மீண்டும் ஏற்றப்படவில்லை என்று பொருள்.
விருப்பம் B: hosts பதிவுகள் மற்றும் நிபந்தனை ஃபார்வர்டிங்
hosts பதிவு மிகச் சிறிய சாத்தியமான திருத்தம் மற்றும் மிகவும் பலவீனமானது. இது ஒரு பெயரை ஒரு இயந்திரத்தில் ஒரு முகவரிக்கு பொருத்துகிறது, எனவே விளக்கக்காட்சிக்கு வேலை செய்கிறது, தனியுரிமை முனைப்புள்ளி அல்லது அதன் IP மீண்டும் கட்டப்படும்போது உடைகிறது. இது உண்மையான இடைவெளியை மீதமுள்ள குழுவிலிருந்து மறைக்கிறது.
நிபந்தனை ஃபார்வர்டர் ஒவ்வொரு வாடிக்கையாளருக்கும் DNS அனுப்பாமல் சிறப்பாக அளவாகிறது. dnsmasq ஒரு மண்டலத்தை VNet தீர்ப்பானுக்கு அனுப்பி மற்ற அனைத்தையும் அமைதியாக விடலாம்: server=/cluster.internal/10.0.0.4. Windows DNS-இல் நிபந்தனை ஃபார்வர்டர்கள் உள்ளன, Windows வாடிக்கையாளர்கள் அதே பிரிவுக்கு NRPT விதியைப் பயன்படுத்தலாம். ஃபார்வர்டருக்கு இன்னும் VNet தீர்ப்பானுக்கு பாதை தேவை.
ஃபார்வர்டிங் சாதாரண உலாவலை உள்ளூரில் வைத்திருக்கிறது, இது split tunnel-இல் முக்கியம். இது தனியுரிமை மண்டலத்தின் வினவல்களைப் பதிவு செய்ய ஒரு இடத்தையும், ஃபார்வர்டர் ஹோஸ்ட் நகரும் போது உடையும் ஒரு இடத்தையும் தருகிறது.
பொறுப்பின் அடிப்படையில் தேர்ந்தெடுங்கள், வசதியின் அடிப்படையில் அல்ல
VPN சுயவிவரத்தை நீங்கள் கட்டுப்படுத்தி, API மட்டுமல்ல ஒவ்வொரு தனியுரிமை பெயரும் வேலை செய்ய வேண்டும் எனில் தீர்ப்பானை அனுப்புங்கள். வாடிக்கையாளர்கள் மற்ற அனைத்திற்கும் தங்கள் உள்ளூர் DNS-ஐ வைத்திருக்க வேண்டும் எனில், அல்லது VPN-ஐ கிளஸ்டரைத் தவிர வேறு குழு நிர்வகித்தால் ஃபார்வர்டரைத் தேர்ந்தெடுங்கள்.
hosts பதிவுகள் கண்டறிதல், வரிசைப்படுத்தல் அல்ல. API அடையக்கூடியது என்பதை நிரூபிக்க ஒன்றைப் பயன்படுத்துங்கள், பின்னர் அதை அகற்றி தீர்ப்பானின் பாதையைச் சரிசெய்யுங்கள்; அதை விட்டுவிட்டால் பின்னர் பாதைக் கேள்வி பொக்கிஷ வேட்டையாக மாறும். எந்த விருப்பத்தைத் தேர்ந்தெடுத்தாலும், மண்டலம், தீர்ப்பான் முகவரி மற்றும் வினவலைச் சுமக்கும் பாதையை எழுதி வையுங்கள்.
API முனைப்புள்ளியைச் சோதியுங்கள், பெயரை மட்டுமல்ல
தேடல் வெற்றிபெற்றதும், கிளஸ்டர் CA உடன் API-இன் பதிப்பு முனைப்புள்ளியைப் பெறுங்கள். curl --cacert ca.crt https://api.internal.example:6443/version TLS மற்றும் அனுமதி தோல்விகளை DNS-இலிருந்து பிரிக்கிறது. 403 என்றால் பெயரும் இணைப்பும் வேலை செய்கின்றன, அடையாளம் செய்யவில்லை.
வாடிக்கையாளரின் முகவரி வரம்பு கிளஸ்டரின் அங்கீகரிக்கப்பட்ட பிணையங்கள் அல்லது தீப்பச்சையால் அனுமதிக்கப்படுகிறதா என்பதையும் சரிபார்க்கவும். தனியுரிமை கிளஸ்டர்கள் பெரும்பாலும் API போக்குவரத்தை VNet அல்லது peered வரம்புகளிலிருந்து மட்டுமே ஏற்கின்றன, எனவே வேறு குளத்திலிருந்து முகவரிகளை வழங்கும் சுரங்கப்பாதை பிணைய அடுக்கில் இணைந்து API-இல் நிராகரிக்கப்படுகிறது.
உயர்த்தும்போது நான்கு உண்மைகளை எழுதுங்கள்: வாடிக்கையாளர் பயன்படுத்திய தீர்ப்பான், அது திருப்பித் தந்த முகவரி, தேர்ந்தெடுத்த kubeconfig சூழலில் சேவையக URL, மற்றும் தோல்வியடைந்த முதல் செயல்பாடு. அந்தப் பதிவு அடுத்த பொறியாளருக்கு DNS, பாதை அல்லது தீப்பச்சைக் கொள்கையை மாற்ற வேண்டுமா என்று சொல்கிறது, அடுத்த hosts கோப்பு திருத்தத்தை நிறுத்துகிறது.
தேடலில் தொடங்குங்கள், மண்டலத்தின் உரிமையாளருக்குப் பொருந்தும் தீர்ப்பான் பாதையைத் தேர்ந்தெடுங்கள், பின்னர் முனைப்புள்ளியைச் சரிபார்க்கவும். மூன்றும் தேர்ச்சி பெற்றால், மீதமுள்ள பிரச்சினை அனுமதி, பெயர் தீர்வு அல்ல.