டெவ் கன்டெய்னர் VPN-மட்டும் ஹோஸ்ட்டை அடைய முடியவில்லை: எங்கே பார்ப்பது

தனியார் API உங்கள் டெஸ்க்டாப் உலாவியில் திறக்கிறது, ஆனால் டெவலப்மென்ட் கன்டெய்னரில் தோல்வியடைகிறது. இது முரண்பாடு அல்ல, மேலும் இது அரிதாகவே VPN தான். உலாவியின் கோரிக்கையும் தோல்வியடையும் கோரிக்கையும் வெவ்வேறு செயல்முறைகளால், வெவ்வேறு ரிசால்வர்கள், ப்ராக்ஸிகள் மற்றும் வழித்தடங்களுடன், பெரும்பாலும் முற்றிலும் வெவ்வேறு நெட்வொர்க் பெயர்வெளிகளில் இருந்து செய்யப்பட்டன. "என் லேப்டாப்பில்" என்பது Windows ஹோஸ்ட், ஒரு WSL விநியோகம், Docker Desktop மெய்நிகர் இயந்திரம் மற்றும் அந்த VM-க்குள் ஒரு கன்டெய்னர் ஆகிய நான்கு சூழல்களைக் குறிக்கலாம்; இவை ஒரே ஹோஸ்ட்பெயருக்கு வெவ்வேறு விதமாக பதிலளிக்கக்கூடும். ஒரு அமைப்பையும் தொடுவதற்கு முன் தோல்வியடையும் செயல்முறை எதைப் பயன்படுத்துகிறது என்பதைக் கண்டறியுங்கள்.

அமைப்பை மாற்றும் முன் செயல்முறையைக் கண்டறியுங்கள்

VPN கிளையண்டை விட கன்டெய்னர் இன்ஜினில் தொடங்குங்கள். கட்டளை வரி எந்த சூழலுடன் பேசுகிறது, அந்த இன்ஜின் எந்த இயங்குதளத்தில் இயங்குகிறது என்பதைக் கேளுங்கள், ஏனெனில் டெஸ்க்டாப் VM ஆல் நிர்வகிக்கப்படும் Linux கன்டெய்னர், உள்ளூர் டீமனால் நிர்வகிக்கப்படுவதிலிருந்து வேறு பாதை:

docker context ls
docker info --format '{{.OperatingSystem}} / {{.Name}}'
docker run --rm alpine ip route

Windows-இல், wsl -l -v விநியோகம் WSL 2-இன் கீழ் இயங்குகிறதா என்பதைச் சொல்லும், இது அதை அதன் சொந்த மெய்நிகர் சுவிட்சுக்குப் பின்னால் வைக்கிறது. கன்டெய்னர் ஹோஸ்ட்டின் ரூட்டிங் அட்டவணையைப் பகிர்கிறதா அல்லது ஹோஸ்ட்டை அடைய ஃபார்வேர்டு செய்யப்பட்ட போர்ட் அல்லது ஹோஸ்ட் பெயர் தேவைப்படும் NAT-க்குப் பின்னால் உள்ளதா என்பதை அந்த விவரம் தீர்மானிக்கிறது.

ஒரு கோரிக்கையை மாறாமல் வைத்து ஒப்பிடுங்கள்

தனியார் ஹோஸ்ட்டில் ஒரு பாதிப்பற்ற எண்ட்பாயிண்ட்டைத் தேர்ந்தெடுத்து, ஒவ்வொரு ஒப்பீட்டிற்கும் அதைப் பயன்படுத்துங்கள்: உலாவியிலிருந்து, ஹோஸ்ட் டெர்மினலிலிருந்து, WSL விநியோகத்திலிருந்து மற்றும் கன்டெய்னரின் உள்ளேயிருந்து. ஒவ்வொரு முயற்சிக்கும் நான்கு விஷயங்களைப் பதிவு செய்யுங்கள்: தீர்க்கப்பட்ட முகவரி, ப்ராக்ஸி பயன்படுத்தப்பட்டதா, தோல்வி வகை மற்றும் கடந்த நேரம். பெயர் தேடல், இணைப்பு நிறுவுதல், TLS சரிபார்ப்பு மற்றும் HTTP நிலை ஆகியவை நான்கு வெவ்வேறு பிரச்சினைகள்; அவற்றை "இது வேலை செய்யவில்லை" என்று கலப்பது ஒரு காலைப்பொழுதை வீணாக்கும்.

தோல்வியடையும் கன்டெய்னரின் உள்ளேயே ஒப்பீட்டை இயக்குங்கள், ஒரு நேர வரம்புடன், அமைதியான ஃபயர்வால் டெர்மினலை நிமிடங்கள் பிடித்து வைக்காதபடி. புதிய கன்டெய்னர் இன்ஜினின் நெட்வொர்க் சூழலை மீண்டும் உருவாக்கும், ஆனால் பயன்பாட்டுக் கன்டெய்னரின் பெயர்வெளி, ப்ராக்ஸி மாறிகள் அல்லது ரிசால்வரை அல்ல, எனவே உண்மையான கன்டெய்னருக்குள் docker exec செய்வதே அதிகாரப்பூர்வ சோதனை; பக்கக் கன்டெய்னர் என்பது வேறுபாடு இன்ஜினிலா கன்டெய்னரிலா என்பதைத் தனிமைப்படுத்தும் ஒரு வழி மட்டுமே:

docker exec -it app /bin/sh -c "getent hosts api.internal; curl -v --max-time 8 https://api.internal/ 2>&1 | tail -20"
docker run --rm --network container:app curlimages/curl:latest -sv --max-time 8 https://api.internal/ 2>&1 | tail -20

alpine அடிப்படை இமேஜில் busybox உள்ளது, curl இல்லை, காப்பி செய்யப்பட்ட கண்டறியும் தொகுதி தோல்வியடைவதற்கு இதுபோன்ற விவரமே காரணம்: கிளையண்ட் உள்ள இமேஜைத் தேர்ந்தெடுங்கள், அல்லது அதே இயக்கத்திற்குள் அதைச் சேர்க்கவும். தொடர்பில்லாத பொது தளங்களுடன் ஒப்பிடுவது எதையும் தனிமைப்படுத்தாது. கன்டெய்னரிலிருந்து https://example.com வேலை செய்தால், கன்டெய்னருக்கு இணைய அணுகல் உள்ளது என்பதை மட்டுமே அறிந்தீர்கள், சுரங்கப்பாதை வழியாக தனியார் முகவரியை அடைய முடியுமா என்பது பற்றி எதுவும் இல்லை. அதுபோலவே, புதிய டெர்மினல் திறப்பது புதிய டெர்மினல் வேலை செய்கிறது என்பதை மட்டுமே நிரூபிக்கிறது, தோல்வியடைந்த பயன்பாட்டுடன் அது ஒரு இயக்கச் சூழலைப் பகிர்கிறது என்பதை அல்ல.

Docker Desktop ஒரு VPN-உடன் வேலை செய்ய முடியும்

VPN மற்றும் ஹோஸ்ட் இணைப்பு பற்றிய Docker-இன் சொந்த ஆவணம் இதை ஆதரிக்கப்பட்ட அமைப்பாக விவரிக்கிறது, நேர்மையான சுருக்கம் என்னவென்றால் இது தானாகவே உடைந்ததாக இல்லாமல் வேலை செய்கிறது. டெஸ்க்டாப் VM வடிவமைப்பின் அடிப்படையில் ஹோஸ்ட் சுரங்கப்பாதையைத் தவிர்க்கிறது என்று கருத வேண்டாம்; பல அமைப்புகளில் டிராஃபிக் ஹோஸ்ட் சுரங்கப்பாதையைச் சரியாகப் பின்பற்றுகிறது, அதனால்தான் "Docker VPN-ஐ புறக்கணிக்கிறது" என்ற புனைவு நம்பிக்கையான ஆனால் தவறான ஆலோசனையை உருவாக்குகிறது.

இன்னும் முக்கியமானது பயன்பாட்டில் உள்ள backend, கிளையண்டின் பிரிந்த-சுரங்கப்பாதைக் கொள்கை மற்றும் VM பெற்ற ரிசால்வர் உள்ளமைவு. வழித்தடங்களை நிறுவும் ஆனால் DNS-ஐ நிறுவாத, அல்லது VM அடைய முடியாத DNS சேவையகத்தைத் தள்ளும் VPN கிளையண்ட், ஹோஸ்ட் வேலை செய்யும்போது கன்டெய்னருக்குள் பெயர் தேடல் தோல்வியை உருவாக்குகிறது, ஏனெனில் ஹோஸ்ட்டுக்கு கூடுதல் ரிசால்வர் அல்லது தற்காலிகச் சேமிப்பில் உள்ள பதில் உள்ளது. இது கன்டெய்னர் வேடத்தில் இருக்கும் ரிசால்வர் பிரச்சினை. நீங்கள் முயற்சிக்கும் ஒவ்வொரு VPN மறு-இணைப்பையும் இது தாங்கும், ஏனெனில் சுரங்கப்பாதை ஏற்கனவே நீங்கள் கேட்ட டிராஃபிக்கை எடுத்துச் செல்கிறது.

முகவரி ஒன்றுடன் ஒன்று மற்றும் MTU வெவ்வேறு தோல்விகள்

இரண்டு தோல்விகள் தனிப்பட்ட கண்டறிதலைப் பெறத் தகுதியானவை, ஏனெனில் அவை பொதுவாக அணுகல் கொள்கையுடன் தவறாகக் கருதப்படுகின்றன. முதலாவது முகவரி ஒன்றுடன் ஒன்று: VPN ஒரு கன்டெய்னர் நெட்வொர்க்கின் இயல்புநிலை பிரிட்ஜ் சப்நெட்டுடன் மோதும் வரம்பைத் தள்ளினால், அந்த வரம்பிற்கான கன்டெய்னர் வழித்தடம் உள்ளூர் பிரிட்ஜை நோக்கிச் சென்று சுரங்கப்பாதையை ஒருபோதும் அடையாது. ஊகிக்காமல் உண்மையான சப்நெட்டுகளை ஆய்வு செய்யுங்கள்:

docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}'
ip route get 10.20.30.40

இரண்டாவது MTU பிரச்சினை. இணைப்பு நிறுவப்பட்டு TLS முடிந்தும் பெரிய பதில்கள் தடைபட்டால், அது அனுமதிப் பிரச்சினை அல்ல, பாக்கெட் அளவுப் பிரச்சினை, DNS பதிவுகளை மாற்றுவது அதை ஒருபோதும் சரிசெய்யாது. எதையும் மாற்றுவதற்கு முன் சிறிய கோரிக்கை மற்றும் பெரிய கோரிக்கையுடன் சோதித்து இரண்டு முடிவுகளையும் பதிவு செய்யுங்கள்.

ஒன்றுடன் ஒன்றுக்கான தீர்வு வேறு கன்டெய்னர் சப்நெட் அல்லது வரையறுக்கப்பட்ட வழித்தடம், முகவரி திட்டத்தை வைத்திருப்பவர் தேர்ந்தெடுக்க வேண்டியது. MTU தடைக்கான தீர்வு, சுரங்கப்பாதை அல்லது இடைமுகத்தின் MTU-ஐ பாதையைத் தாங்கும் மதிப்புக்குக் குறைப்பது, நீங்கள் கட்டுப்படுத்தும் அடுக்கில் பயன்படுத்தப்பட வேண்டும்.

ப்ராக்ஸி உள்ளமைவு இயந்திரத்திற்கு அல்ல, செயல்முறைக்கு

ஒரு கன்டெய்னருக்குள், localhost அந்தக் கன்டெய்னரின் சொந்த நெட்வொர்க் சூழலைக் குறிக்கிறது, எனவே ஹோஸ்ட்டில் இயங்கும் ப்ராக்ஸி அந்தப் பெயரில் அங்கு அணுக முடியாது. Docker Desktop ஹோஸ்ட் அணுகலுக்கு host.docker.internal வழங்குகிறது, Linux-இல் அதை --add-host=host.docker.internal:host-gateway உடன் வெளிப்படையாகச் சேர்க்கிறீர்கள். எப்படியிருந்தாலும், அந்தப் பெயர் ஹோஸ்ட்டிற்கு ஒரு வழித்தடத்தைத் தருகிறது; அது ப்ராக்ஸி சேவையை உருவாக்காது, அதைப் பயன்படுத்த உங்களுக்கு அதிகாரம் அளிக்காது.

உண்மையான சூழலுக்கு வழங்கப்பட்ட ப்ராக்ஸி முகவரி மற்றும் போர்ட்டைப் பயன்படுத்துங்கள், அதை யார் படிக்கிறார்கள் என்பதைச் சரிபார்க்கவும். ஊடாடும் ஷெல்லில் ஏற்றுமதி செய்யப்பட்ட மாறிகள் ஒவ்வொரு எடிட்டர் நீட்டிப்பு, மொழி சேவையகம், கட்டமைப்புக் கருவி மற்றும் பின்னணி டீமனை தானாகவே உள்ளமைக்காது. முக்கியமானது தோல்வியடைந்த கோரிக்கையைச் செய்த செயல்முறை, எனவே உங்கள் டெர்மினலின் சூழலை அல்ல, அதன் சூழலை ஆய்வு செய்யுங்கள்.

இறுதியாக, தீர்வு தன்னைத்தானே விளக்கட்டும். பயனுள்ள தீர்வு தவறான எல்லையை, அதை மாற்றிய அமைப்பை, இப்போது அது பாதிக்கும் செயல்முறைகளின் தொகுப்பையும் பெயரிடுகிறது. VPN, எடிட்டர் மற்றும் இன்ஜினை வரிசையாக மறுதொடக்கம் செய்வது அறிகுறியை மாற்றலாம், ஆனால் அடுத்தவர் பயன்படுத்த எதையும் விட்டுச் செல்லாது.