Docker බහාලුමට VPN පිටුපස ඇති සත්කාරක වෙත ළඟා විය නොහැක්කේ ඇයි

ආයතනික VPN පිටුපස කිසිවකට ළඟා විය නොහැකි බහාලුම සාමාන්‍යයෙන් උමං මාර්ගයට වඩා වෙනස් ජාල නාම අවකාශයක ජීවත් වේ. සත්කාරක සේවාදායකයේ මාර්ග, DNS සේවාදායක සහ ෆයර්වෝල් සලකුණු සත්කාරකයේ ගොඩට අයත් වේ; බ්‍රිජ් ජාල බහාලුමට තමන්ගේම ගොඩක් ඇත. මෙම එකම කරුණ වේදිකා කණ්ඩායමට ළඟා වන බොහෝ වාර්තා පැහැදිලි කරයි, සහ «VPN කැඩී ඇත» සහ «Docker VPN මඟ හරියි» දෙකම එකම වේලාවේ වැරදි විය හැකි බවට හේතුව ද එයමය. එක් රෝග ලක්ෂණයක් පිටුපස සම්පූර්ණයෙන් වෙනස් සැකසුම් දෙකක් සැඟවී ඇත, එබැවින් ඕනෑම සැකසුමක් වෙනස් කිරීමට පෙර ඔබට ඇත්තේ කුමක්දැයි හඳුනාගන්න.

උමං මාර්ගය කාගේ නාම අවකාශයට අයත් දැයි සොයා ගන්න

macOS හෝ Windows සඳහා Docker Desktop තුළ බහාලුම් Linux අතථ්‍ය යන්ත්‍රයක් තුළ ක්‍රියාත්මක වේ. ඩෙස්ක්ටොප් මත ස්ථාපනය කළ VPN සේවාදායකය ඩෙස්ක්ටොප් මෙහෙයුම් පද්ධතිය තුළ උමං මාර්ගයක් සාදයි, අතථ්‍ය යන්ත්‍රය එය කිසිදා නොදකී. කිසිදු බහාලුම් වින්‍යාසයක් එය අලුත්වැඩියා නොකරයි, මන්ද බහාලුමට අවශ්‍ය අතුරුමුහුණත එහි ජාල නාම අවකාශයේ කිසිසේත් නොමැති බැවිනි.

Linux සත්කාරකයක උමං මාර්ගය සත්කාරකයේ නාම අවකාශයේ ජීවත් වේ, සහ බ්‍රිජ් බහාලුම් සාමාන්‍යයෙන් පිටවීමේදී මූලාශ්‍ර NAT යොදන ලද සත්කාරකයේ මාර්ගගත කිරීමේ වගුව හරහා එයට ළඟා වේ. එම මාර්ගය අසාර්ථක වූ විට, හේතුව සාමාන්‍යයෙන් නැති වූ මාර්ගයක් නොව, යැවීමේ ප්‍රතිපත්තිය, ප්‍රතිලෝම මාර්ග පෙරහන හෝ අතිච්ඡාදනය වන උපජාලයක් වේ. තවදුරටත් කියවීමට පෙර ඔබ දෙලොවින් කුමන ලෝකයේ සිටීදැයි තහවුරු කරන්න:

docker info --format '{{.OperatingSystem}}'
docker run --rm --net=host alpine ip route | head -5
docker run --rm alpine ip route | head -5

එම මාර්ගගත කිරීමේ වගු දෙක අතර වෙනස එක් තිරයක මුළු ගැටලුවයි. සත්කාරකයේ දර්ශනයේ උමං අතුරුමුහුණත ඇති අතර බ්‍රිජයේ දර්ශනයේ නොමැති නම්, ඔබ දකින්නේ නාම අවකාශ හුදකලාවය, සහ ඉතිරි සියල්ල එය තරණය කරන ආකාරය පිළිබඳ තේරීමකි.

සත්කාරක ජාලකරණය පරීක්ෂණයකි, නිර්මාණයක් නොවේ

බහාලුම සත්කාරක ජාලකරණය සමඟ ධාවනය කිරීම, එය Docker සත්කාරක ජාල නාම අවකාශය බෙදාගැනීම ලෙස ලේඛනගත කරයි, එයට උමං අතුරුමුහුණත සහ එහි මාර්ග සෘජුවම උරුම කරයි. එම ඉල්ලීම පසුව සාර්ථක වුවහොත්, මාර්ග සිද්ධාන්තය තහවුරු වේ, සහ අසාර්ථකත්වය නාම අවකාශ හුදකලාවය, අක්‍රමතා, DNS හෝ ප්‍රවේශ නියමයක් නොවේ.

docker run --rm --net=host curl -sS -o /dev/null -w '%{http_code}\n' https://api.internal/health

එය රෝග විනිශ්චයක් ලෙස තබා ගන්න. සත්කාරක ජාලකරණය වරාය ප්‍රකාශනය සහ බහාලුමකින් ඔබට අවශ්‍ය වූ හුදකලාවේ වැඩි ප්‍රමාණයක් අත්හරියි, සහ Docker Desktop තුළ «host» යන්නෙන් අදහස් වන්නේ අතථ්‍ය යන්ත්‍රය මිස ඩෙස්ක්ටොප් නොවේ, එබැවින් ඔබ කතා කළේ කුමන සත්කාරකයටද යන්න අමතක වුවහොත් එහි සාර්ථකත්වය හෝ අසාර්ථකත්වය ඔබව අපගමනය කළ හැකිය.

tun උපාංගය සහ එය සමඟ එන වරප්‍රසාද

බහාලුම තුළ ඇති VPN සේවාදායකයට උමං උපාංගයක් සහ එය වින්‍යාස කිරීමට අවසරයක් අවශ්‍ය වේ. සුලබ කෙටි මාර්ගය --privileged වන අතර, එය සෑම උපාංගයක්ම ලබා දෙන අතර මුළු බහාලුම තුළ ආරක්ෂක ප්‍රතිපත්තිය ලිහිල් කරයි. එය මෙම කාර්යයට අවශ්‍ය ප්‍රමාණයට වඩා බොහෝ වැඩි වන අතර සමාලෝචනයකදී එය සාධාරණීකරණය කිරීම අපහසුය.

sudo modprobe tun
docker run --rm -it --device /dev/net/tun --cap-add NET_ADMIN myvpn-client

පටු ස්වරූපය තනි උපාංග නෝඩය සිතියම්ගත කර ජාල පරිපාලන හැකියාව පමණක් එකතු කරයි. නෝඩය පවතින පරිදි පළමුව සත්කාරකයේ මොඩියුලය පූරණය කරන්න. බහාලුම ආරම්භ වී සේවාදායකය උමං උපාංගය විවෘත කළ නොහැකි බව වාර්තා කරන්නේ නම්, පැතිකඩ සැක කිරීමට පෙර සිතියම්ගත කිරීම පරීක්ෂා කරන්න, මන්ද එම දෝෂය සාමාන්‍යයෙන් වචනාර්ථයෙන්ම වේ.

මෙම නිර්මාණයෙන් අදහස් වන්නේ සේවාදායකය එක් එක් බහාලුම සඳහා ධාවනය වන බවයි. එක් එක් කාර්ය භාරයට තමන්ගේම උමං මාර්ගයක් අවශ්‍ය වූ විට මෙය නිවැරදි පිළිතුර වන අතර, ඔබට අවශ්‍ය වූයේ සත්කාරකයේ උමං මාර්ගය පෙනෙන්නට තිබීම පමණක් නම් එය වැරදි පිළිතුරයි — වේදිකා කණ්ඩායම ඔබ එසේ කරන බව උපකල්පනය කරන්නට ඇත.

බ්‍රිජ් NAT VPN දකින මූලාශ්‍රය වෙනස් කරයි

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

macvlan හෝ ipvlan ඒ වෙනුවට බහාලුමට LAN ලිපිනයක් ලබා දෙයි, එය LAN සොයාගැනීමට උපකාරී වන අතර බහාලුම කොටසේ සමානයෙකු ලෙස පෙනේ. එය සත්කාරකයේ උමං මාර්ගය සම්පූර්ණයෙන්ම මඟ හරියි, එබැවින් එවැනි බහාලුමක් VPN-පමණක් උපසර්ග වෙත ළඟා නොවේ, එම LAN වෙතින් ද VPN ප්‍රවේශ විය හැකි නොවන්නේ නම්.

ස්වරූප දෙකම නීත්‍යානුකූලය; ඒවා වෙනස් අවශ්‍යතාවලට පිළිතුරු දෙයි. අවශ්‍යතාව «මෙම බහාලුම VPN-පමණක් සේවාවකට ළඟා විය යුතුය» නම්, ඔබ සත්කාරකය හරහා මාර්ගගත කිරීම සහ බහාලුම තුළ උමං මාර්ගය අවසන් කිරීම අතර තෝරා ගනී. එම තේරීම යෙදවීමට පෙර ලියන්න, පළමු අසාර්ථක ඉල්ලීමෙන් පසුව නොවේ. ඔබ කුමක් තෝරා ගත්තද, දුරස්ථ කෙළවර දකින මූලාශ්‍ර ලිපිනය සටහන් කරන්න, මන්ද එහි ප්‍රවේශ නියම සහ එහි ලොග් පෙන්වන්නේ එයම බැවිනි. එම ලිපිනය පැවසිය නොහැකි නිර්මාණයක් සම්පූර්ණ නොවේ.

DNS ඩීමන්ට අනුගත වේ, උමං මාර්ගයට නොවේ

බහාලුම ආරම්භ වන විට තමන්ගේ විසඳුම්කරු වින්‍යාසය ලබා ගනී, එය ඩීමන් හෝ රූපයෙන් පිටපත් කර ඇත. VPN සම්බන්ධ වූ පසු තල්ලු කරන ලිපින එම පිටපතට ඉතා ප්‍රමාද වී පැමිණේ, සහ ඒවා බහාලුමට නොව සත්කාරකයේ විසඳුම්කරුට තල්ලු කරයි.

සේවාව සඳහා විසඳුම්කරු පැහැදිලිව සකසන්න, නැතහොත් උමං මාර්ගය හරහා ප්‍රවේශ විය හැකි අභ්‍යන්තර විසඳුම්කරුවෙකු වෙත යොමු කරන්න. පෞද්ගලික නාමයක් පොදු ලිපිනයකට විසඳන බහාලුම සාමාන්‍යයෙන් පොදු විසඳුම්කරුවෙකු භාවිතා කරයි, කැඩුණු මාර්ගයකින් පීඩා නොවිඳියි, සහ නිවැරදි කිරීම compose ගොනුවට හෝ ඩීමන් වින්‍යාසයට අයත් වේ.

එම තර්කයම පිටවන ලිපින ප්‍රශ්නයට ද අදාළ වේ. සෑම බහාලුමක්ම වෙනස් VPN ලිපිනයකින් පෙනිය යුතු නම්, එක් සත්කාරක උමං මාර්ගයකට එය ලබා දිය නොහැක්කේ NAT ඒවා එක් මූලාශ්‍රයකට සංකෝචනය කරන බැවිනි. ක්‍රියාකාරී ස්වරූප වන්නේ සෑම බහාලුමක නාම අවකාශයේ සේවාදායකයක් හෝ උමං මාර්ගය හිමිකර ගන්නා සහ තම ගොඩ බෙදාගන්නා පැති මඟක් වන අතර, දෙකම යෙදුම ලිපිනගත කරන ආකාරය වෙනස් කරයි.

ටිකට්පත වැසීමට පෙර පරීක්ෂණ ලැයිස්තුව: උමං මාර්ගය හිමි නාම අවකාශය හඳුනා ගන්න, සත්කාරක ජාලකරණයෙන් මාර්ගය ඔප්පු කරන්න, අවශ්‍ය tun උපාංගය පමණක් සිතියම්ගත කරන්න, NAT පසු මූලාශ්‍ර ලිපිනය මතක තබා ගන්න, විසඳුම්කරු පැහැදිලිව සකසන්න, සහ බහාලුමකට පිටවන ලිපින කොඩියක් නොව වාස්තුවිද්‍යා තීරණයක් ලෙස සලකන්න.