Windows කන්ටේනර සහ VPN: දේශීය ජාලකරණය බිඳෙන්නේ ඇයි
Windows කන්ටේනරය සත්කාරකයේ මාර්ග වගුව භාවිත කරයි, එබැවින් දේශීය උපජාලය අවහිර කරන VPN එකක් කන්ටේනරයේ උපසර්ගයද රැගෙන යයි. Linux ආකාරය වෙනත් මාර්ගයක් ගනී.
එකම ලැප්ටොප් පරිගණකයේ, එක් VPN සේවාදායකයෙක් සම්බන්ධ වූ විට, Linux කන්ටේනර එකිනෙකා සමඟ කතා කරමින් සිටින අතර Windows කන්ටේනර නතර වේ. වෙනස් වන සාධකය පින්තූරය නොවේ; පැකට් සත්කාරකයට යන මාර්ගයයි. පෙරනිමි ජාලයේ Windows කන්ටේනර සත්කාරකයේ මාර්ග වගුව සහ පරිවර්තනය ණයට ගනී, එබැවින් සත්කාරකයේ මාර්ගකරණය වෙනස් කරන ප්‍රතිපත්තිය ඒවාද වෙනස් කරයි. යමක් නැවත ස්ථාපනය කිරීමට පෙර මාර්ග සෙවීමකින් එය තහවුරු කරන්න.
Windows කන්ටේනරයේ පැකට් සත්කාරකයට ඇතුළු වන්නේ කොහෙන්ද
පෙරනිමි nat ජාලයේ කන්ටේනරයක් Host Networking Service උපසර්ගයකින් ලිපිනයක් ලබා ගනී, සාමාන්‍යයෙන් 172.16.0.0/12 තුළ කොහේ හෝ, සහ අතථ්‍ය අනුවර්තකයක් හරහා සත්කාරකයට ළඟා වේ. සත්කාරකය එම උපසර්ගයේ මාර්ගය හිමිකර ගනී සහ දැනට සක්‍රීය අනුවර්තකය වෙත ගමනාගමනය පරිවර්තනය කරයි. එම මාර්ගයේ මැද තනි අතථ්‍ය යන්ත්‍රයක් නොමැත.
මෙම නිර්මාණය අසාර්ථකත්වය යාන්ත්‍රික කරයි. කන්ටේනරය පැකට් එකක් යවන විට, සත්කාරකය කන්ටේනර උපසර්ගය සඳහා මාර්ග සෙවීමක් කරයි. කුමන මාර්ගය දිනන්නේද එහිට පැකට් යයි, කන්ටේනරයට ඒ ගැන මතයක් නැත.
VPN සේවාදායකයා එම මාර්ගයේ වෙනස් කරන්නේ කුමක්ද
ආයතනික සේවාදායකයා බොහෝ විට මාර්ග රැසක් සහ උමග සක්‍රීයව ඇති විට දේශීය උපජාලයට ප්‍රවේශය ප්‍රතික්ෂේප කරන පෙරහනක් ස්ථාපනය කරයි. අරමුණ ආරක්ෂකයි: හානියට පත් දේශීය ජාලයක් ආරක්ෂිත යන්ත්‍රයකට ළඟා නොවිය යුතුය. අතුරු ප්‍රතිවිපාකය නම් සත්කාරකයේ මාර්ගය කන්ටේනර උපසර්ගය දක්වා තවදුරටත් දේශීය NAT ජාලය නොවීමයි.
ඒ වෙනුවට සෙවීම උමගට ගැළපෙන අතර පැකට් එම කන්ටේනර ලිපිනය ගැන කිසිදා නොඇසූ ගේට්වේට පවරනු ලැබේ. Ping අසාර්ථක වේ, යෙදුම කල් ඉකුත් වේ, VPN නිරූපකය දිලිසෙන අතර කන්ටේනරය කැඩී ඇති ලෙස පෙනේ. සම්බන්ධව සිටියදී සත්කාරකයේ වගුව බලන්න, තරඟකාරී මාර්ගය පෙනෙයි.
| Container mode | Outbound path | Typical result behind the VPN |
|---|---|---|
| Windows, default nat | Host routes and translates container traffic | Container prefix follows the tunnel and fails |
| Windows, transparent | Container sits on the physical link | Depends on the local subnet being allowed |
| Linux engine on Docker Desktop | VM egress proxied by a host process | Often keeps working |
Linux කන්ටේනර වෙනස් ලෙස හැසිරෙන්නේ ඇයි
Linux එන්ජිම කන්ටේනර සැහැල්ලු අතථ්‍ය යන්ත්‍රයක් තුළ ධාවනය කරයි, එම යන්ත්‍රයෙන් පිටවන සම්බන්ධතා කන්ටේනරය වෙනුවෙන් සත්කාරක පැත්තේ ප්‍රොක්සියක් විවෘත කරයි. සොකටය ආරම්භ කරන්නේ සත්කාරකයයි, එබැවින් කන්ටේනර උපසර්ගය පිළිබඳ VPN රීතිය එයට එලෙසම අදාළ නොවේ, සහ කාර්ය භාරය ජාලයට ළඟා වෙමින් තිබේ.
මෙම වෙනස Linux වට්ටෝරු මාරු නොවන්නේ ඇයිද යන්නද පැහැදිලි කරයි. තමන්ගේම උමගක් අවශ්‍ය Linux කන්ටේනරයකට TUN උපාංගයක් සහ NET_ADMIN හැකියාව ලබා දේ. Windows කන්ටේනර කිසිදු අතුරුමුහුණතක් උපාංගයක් ලෙස නොපෙන්වයි, එබැවින් එම රටාවට එම පැත්තේ සමානයක් නැත.
මාර්ගය සනාථ කරන්න, පසුව නිර්මාණයක් තෝරන්න
සාක්ෂි සත්කාරකයෙන් රැස් කරන්න, කන්ටේනරයෙන් නොව, මන්ද සෙවීම කරන්නේ සත්කාරකයයි:
docker network inspect nat --format "{{range .IPAM.Config}}{{.Subnet}}{{end}}"
route print -4
Get-NetRoute -AddressFamily IPv4 | Where-Object DestinationPrefix -like "172.16.*"VPN සම්බන්ධ වීමට පෙර එක් වරක් සහ පසුව එක් වරක් මාර්ග ප්‍රතිදානය ධාවනය කරන්න. දෙවන ප්‍රතිදානයේ කන්ටේනර උපසර්ගය උමග අනුවර්තකයට යොමු වේ නම්, රෝග විනිශ්චය සම්පූර්ණයි, කන්ටේනර නැවත ආරම්භ කිරීමෙන් ප්‍රයෝජනයක් නොවේ.
පළමු විකල්පය ප්‍රතිපත්ති තීරණයකි: මෙම උපාංගයට දේශීය LAN ප්‍රවේශය අවසර දිය හැකිදැයි ජාල හිමිකරුගෙන් අසන්න. ආයතනික සේවාදායක කිහිපයක් එය සැකසුමක් ලෙස ලබා දෙයි, නමුත් එය හිතාමතා ඇදි සීමාවක් දුර්වල කරයි. හිමිකරු සහ සමාලෝචන දිනය සහිත ලේඛනගත ව්‍යතිරේකයක් ලෙස එය ඉල්ලන්න. කිසිවෙකු නැවත නොබලන උපාංගයකට එක් ස්විචයක් යනු ආරක්ෂක ප්‍රතිපත්තියක් නිශ්ශබ්දව අතුරුදහන් වන ක්‍රමයයි.
ප්‍රතිපත්තිය රැඳිය යුතු තැන, මාර්ගය සමඟ සටන් නොකර කාර්ය භාරය ගෙන යන්න. පැහැදිලි උපජාලයක් සහ ගේට්වේ එකක් සහිත විනිවිද පෙනෙන ජාලයක් කන්ටේනර දේශීය සබැඳියට තබයි, Linux කාර්ය භාරය VM ප්‍රොක්සිය පිටුපස ධාවනය වේ, සහ තමන්ගේම සේවාදායකය සහිත වෙනම අතථ්‍ය යන්ත්‍රයක් තමන්ගේම ප්‍රතිපත්තිය රඳවා ගනී. එකක් හිතාමතා තෝරා කන්ටේනරය තුළින් පරීක්ෂා කරන්න, මන්ද පරිශීලකයාගේ ඉල්ලීම උත්පාදනය වන්නේ එහිදීය.