Dev Container එකට VPN-පමණක් host එකට ළඟා විය නොහැක: කොහේ දෙස බලන්නද

පෞද්ගලික API ඔබේ ඩෙස්ක්ටොප් බ්‍රවුසරයේ විවෘත වන නමුත් සංවර්ධන container එකේ අසාර්ථක වේ. එය පරස්පරයක් නොවේ, සහ හේතුව VPN එකම වීම කලාතුරකින් සිදු වේ. බ්‍රවුසර ඉල්ලීම සහ අසාර්ථක ඉල්ලීම වෙනස් ක්‍රියාවලි විසින් සිදු කර ඇත, වෙනස් resolver, proxy සහ මාර්ග සමඟ, සහ බොහෝ විට සම්පූර්ණයෙන්ම වෙනස් ජාල නාම අවකාශවලින්. “මගේ ලැප්ටොප් එකේ” යන්නෙන් Windows host එක, WSL බෙදාහැරීමක්, Docker Desktop අතථ්‍ය යන්ත්‍රය සහ එම VM තුළ ඇති container එක අදහස් විය හැක — එකම host නාමයට එක් එක් අයට වෙනස් ලෙස පිළිතුරු දිය හැකි සන්දර්භ හතරක්. එක් සැකසුමක්වත් ස්පර්ශ කිරීමට පෙර අසාර්ථක වන ක්‍රියාවලිය කුමක් භාවිතා කරයිදැයි සොයා ගන්න.

සැකසුම වෙනස් කිරීමට පෙර ක්‍රියාවලිය සොයන්න

VPN සේවාදායකයාගෙන් නොව container එන්ජිමෙන් ආරම්භ කරන්න. විධාන රේඛාව කුමන සන්දර්භයක් සමඟ කතා කරන්නේද, එම එන්ජිම කුමන මෙහෙයුම් පද්ධතියක ධාවනය වන්නේද යන්න අසන්න, මන්ද ඩෙස්ක්ටොප් VM එකක් විසින් කළමනාකරණය කරන Linux container එකක් දේශීය ඩීමන් එකක් විසින් කළමනාකරණය කරන එකට වඩා වෙනස් මාර්ගයක් ගනී:

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

Windows හි, wsl -l -v මගින් බෙදාහැරීම WSL 2 යටතේ ධාවනය වේද යන්න පවසයි, එය එය තමන්ගේම අතථ්‍ය ස්විචය පිටුපස තබයි. එම විස්තරය මගින් container එක host එකේ මාර්ග වගුව බෙදා ගනීද, නැතහොත් host එකට ළඟා වීමට ඉදිරියට යවන ලද port එකක් හෝ host නාමයක් අවශ්‍ය වන NAT එකක් පිටුපස සිටීද යන්න තීරණය කරයි.

එක් ඉල්ලීමක් ස්ථිරව තබා සසඳන්න

පෞද්ගලික host එකේ එක් හානිකර නොවන අන්ත ලක්ෂ්‍යයක් තෝරා එය සෑම සංසන්දනයකටම භාවිතා කරන්න: බ්‍රවුසරයෙන්, host ටර්මිනලයෙන්, WSL බෙදාහැරීමෙන් සහ container ඇතුළතින්. සෑම උත්සාහයකටම කරුණු හතරක් සටහන් කරන්න: විසඳන ලද ලිපිනය, proxy එකක් භාවිතා කළේද, අසාර්ථකත්ව පන්තිය සහ ගත වූ කාලය. නාම සෙවීම, සම්බන්ධතාවය ගොඩනැගීම, TLS සත්‍යාපනය සහ HTTP තත්ත්වය වෙනස් ගැටළු හතරකි, ඒවා “වැඩ කරන්නේ නැත” ලෙස මිශ්‍ර කිරීමෙන් උදෑසනක් නාස්ති වේ.

සංසන්දනය අසාර්ථක වන container එක තුළම, කාල සීමාවක් සමඟ ක්‍රියාත්මක කරන්න, නිහඬ firewall එකක් ටර්මිනලය මිනිත්තු ගණනක් රඳවා නොගැනීමට. නව container එකක් එන්ජිමේ ජාල සන්දර්භය නැවත නිපදවයි, නමුත් යෙදුම් container එකේ නාම අවකාශය, proxy විචල්‍ය හෝ resolver නොවේ, එබැවින් සැබෑ container එකට docker exec කිරීම අධිකාරී පරීක්ෂණය වන අතර, පැත්තේ container එක වෙනස එන්ජිමේද container එකේද යන්න වෙන් කිරීමේ ක්‍රමයක් පමණි:

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 නැත, සහ පිටපත් කළ රෝග නිර්ණය කොටසක් අසාර්ථක වීමට හේතු වන්නේ එවැනි විස්තරයක් ය: සේවාදායකය සහිත රූපයක් තෝරන්න, නැතහොත් එය එම ධාවනය තුළම එකතු කරන්න. සම්බන්ධයක් නැති පොදු අඩවි සමඟ සංසන්දනය කිසිවක් වෙන් නොකරයි. container එකෙන් https://example.com වැඩ කරන්නේ නම්, container එකට අන්තර්ජාල ප්‍රවේශය ඇති බව පමණක් දැනගත් අතර, ටනලය හරහා පෞද්ගලික ලිපිනයකට ළඟා වේද යන්න ගැන කිසිවක් නොදනී. එලෙසම, නව ටර්මිනලයක් විවෘත කිරීමෙන් ඔප්පු වන්නේ නව ටර්මිනලය වැඩ කරන බව පමණක් මිස, අසාර්ථක වූ යෙදුම සමඟ එකම ධාවන පරිසරය බෙදා ගන්නා බව නොවේ.

Docker Desktop VPN එකක් සමඟ වැඩ කළ හැක

Docker හිම VPN සහ host සම්බන්ධතාවය පිළිබඳ ලේඛනය මෙය ආධාරක සැකසුමක් ලෙස විස්තර කරන අතර, අවංක සාරාංශය වන්නේ එය ස්වයංක්‍රීයව කැඩී යනවාට වඩා වැඩ කරන බවයි. ඩෙස්ක්ටොප් VM එක නිර්මාණය අනුවම host ටනලය මඟ හරින බව නොසිතන්න; බොහෝ සැකසුම්වල ගමන්මග host ටනලය නිවැරදිව අනුගමනය කරයි, එබැවින්ම “Docker VPN නොසලකා හරියි” යන ජනප්‍රවාදය විශ්වාසවන්ත හා වැරදි උපදෙස් ලබා දෙයි.

තවමත් වැදගත් වන්නේ භාවිතා කරන backend, සේවාදායකයේ split-tunnel ප්‍රතිපත්තිය සහ VM එකට ලැබුණු resolver වින්‍යාසයයි. මාර්ග ස්ථාපනය කරන නමුත් DNS නොකරන, හෝ VM එකට ළඟා විය නොහැකි DNS සේවාදායකයක් තල්ලු කරන VPN සේවාදායකයක් container එක තුළ නාම සෙවුම් අසාර්ථකත්වය ඇති කරයි, නමුත් host එක වැඩ කරන්නේ එයට අමතර resolver එකක් හෝ cache කළ පිළිතුරක් ඇති බැවිනි. මෙය container වේෂයක් පැළඳි resolver ගැටළුවකි. ඔබ උත්සාහ කරන සෑම VPN නැවත සම්බන්ධතාවයකින්ම එය නොනැසී පවතී, මන්ද ටනලය දැනටමත් ඔබ ඉල්ලා සිටි ගමන්මග රැගෙන යන බැවිනි.

ලිපින අතිච්ඡාදනය සහ MTU වෙනස් අසාර්ථකතා වේ

අසාර්ථකතා දෙකක් තමන්ගේම රෝග නිර්ණයක් ලැබිය යුතුය, මන්ද ඒවා බොහෝ විට ප්‍රවේශ ප්‍රතිපත්තියක් ලෙස වැරදි ලෙස තේරුම් ගැනේ. පළමුවැන්න ලිපින අතිච්ඡාදනයකි: VPN එක container ජාලයක පෙරනිමි පාලම් උපජාලය සමඟ ගැටෙන පරාසයක් තල්ලු කරන්නේ නම්, එම පරාසය සඳහා container එකේ මාර්ගය දේශීය පාලම වෙත යොමු වන අතර කිසි විටෙක ටනලයට ළඟා නොවේ. අනුමාන නොකර සැබෑ උපජාල පරීක්ෂා කරන්න:

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

දෙවැන්න MTU ගැටළුවකි. සම්බන්ධතාවය ස්ථාපිත වී TLS සම්පූර්ණ වුවත් විශාල ප්‍රතිචාර නතර වන්නේ නම්, ඔබට ඇත්තේ පැකට් ප්‍රමාණ ගැටළුවක් මිස අවසර ගැටළුවක් නොවේ, සහ DNS වාර්තා ප්‍රතිස්ථාපනය කිරීමෙන් එය කිසි විටෙක නොවිසඳේ. යමක් වෙනස් කිරීමට පෙර කුඩා සහ විශාල ඉල්ලීමකින් පරීක්ෂා කර ප්‍රතිඵල දෙකම සටහන් කරන්න.

අතිච්ඡාදනයකට විසඳුම වන්නේ ලිපින සැලැස්මේ හිමිකරු තෝරන වෙනත් container උපජාලයක් හෝ සීමිත මාර්ගයකි. MTU නතරවීමට විසඳුම වන්නේ ටනලයේ හෝ අතුරුමුහුණතේ MTU මාර්ගය තුළ රැඳී පවතින අගයකට තද කිරීම හෝ අඩු කිරීම වන අතර, එය ඔබ පාලනය කරන ස්තරයේ යෙදිය යුතුය.

proxy වින්‍යාසය යන්ත්‍රය අනුව නොව ක්‍රියාවලිය අනුව වේ

container එකක් තුළ, localhost එම container එකේම ජාල සන්දර්භය නම් කරයි, එබැවින් host එකේ ධාවනය වන proxy එකක් එහි එම නාමයෙන් ළඟා විය නොහැක. Docker Desktop host ප්‍රවේශය සඳහා host.docker.internal සපයන අතර, Linux හි ඔබ එය --add-host=host.docker.internal:host-gateway සමඟ පැහැදිලිව එකතු කරයි. කෙසේ වුවද, එම නාමය ඔබට host වෙත මාර්ගයක් ලබා දෙයි; එය proxy සේවාවක් නිර්මාණය නොකරයි, එය භාවිතා කිරීමට අවසරයක්ද නොදේ.

සැබෑ පරිසරය සඳහා ලබා දී ඇති proxy ලිපිනය සහ port එක භාවිතා කර, එය කවුරුන් කියවන්නේදැයි පරීක්ෂා කරන්න. අන්තර්ක්‍රියාකාරී shell එකක export කළ විචල්‍ය සෑම සංස්කාරක දිගුවක්, භාෂා සේවාදායකයක්, build මෙවලමක් සහ පසුබිම් ඩීමන් එකක් ස්වයංක්‍රීයව වින්‍යාස නොකරයි. වැදගත් වන්නේ අසාර්ථක ඉල්ලීම කළ ක්‍රියාවලියයි, එබැවින් ඔබේ ටර්මිනලයේ නොව එහි පරිසරය පරීක්ෂා කරන්න.

අවසාන වශයෙන්, නිවැරදි කිරීම තමන්ම පැහැදිලි කර ගැනීමට ඉඩ දෙන්න. ප්‍රයෝජනවත් විසඳුමක් වැරදි වූ මායිම, එය වෙනස් කළ සැකසුම සහ දැන් එය බලපාන ක්‍රියාවලි කට්ටලය නම් කරයි. VPN, සංස්කාරකය සහ එන්ජිම අනුපිළිවෙලින් නැවත ආරම්භ කිරීම රෝග ලක්ෂණය වෙනස් කළ හැකි නමුත්, ඊළඟ පුද්ගලයාට භාවිතා කළ හැකි කිසිවක් ඉතිරි නොකරයි.