VPN හරහා Docker කන්ටේනරයට ළඟා විය නොහැකිද? උපජාලක සසඳන්න
Docker ලබා දෙන උපජාලයට VPN ද අයිති කරගනී. ලිපින සැලසුම් දෙක සසඳා, නැවත සම්බන්ධ වූ පසුවත් රැඳෙන අලුත්වැඩියාවක් තෝරන්න.
කන්ටේනර කාර්යාල LAN එකේ පිළිතුරු දෙයි, නමුත් සමාගම් VPN සම්බන්ධ වන මොහොතේම පිළිතුරු දීම නවතී. කන්ටේනරයේ කිසිවක් වෙනස් වී නැත: නැවත ආරම්භයක් නැත, රූප යාවත්කාලීනයක් නැත, වින්‍යාස සංස්කරණයක් නැත. වෙනස් වූයේ සත්කාරකයේ මාර්ගගත කිරීමේ වගුවයි; එහි උමග එකතු කළ මාර්ගයක් දැන් Docker ලබා දුන් ලිපිනය ආවරණය කරයි. උපජාලයක් සංස්කරණය කිරීමට හෝ VPN ව්‍යතිරේකයක් ඉල්ලීමට පෙර ලිපින සැලසුම් දෙකම අසලින් තබන්න, මන්ද එක් එක් අලුත්වැඩියාව ගත වන කාලය බෙහෙවින් වෙනස් ය.
වින්‍යාසය වෙනස් කිරීමට පෙර මාර්ගය කියවන්න
Docker සැබවින්ම ගොඩනැගූ ජාලයෙන් ආරම්භ කරන්න. IPAM කොටස ලිපින සැලසුමයි, උපජාලය යනු වැදගත් වන පේළියයි:
docker network inspect project_default --format '{{json .IPAM.Config}}'
# [{"Subnet":"172.18.0.0/16","Gateway":"172.18.0.1"}]Compose සෑම නව ව්‍යාපෘතියකටම පෙරනිමියෙන් /16 එකක් වෙන් කරයි, එබැවින් සේවා දෙකක් ලිපින 65,536ක පරාසයක් තුළ තිබිය හැක. මෙම පළල නිසාම අතිච්ඡාදන බහුල ය: අහඹු ලෙස තෝරාගත් /16 එකක් උමග හරහා ඔබ ළඟා වන අඩවියක් ගිල දැමීමට තරම් විශාල ය, උමග ඉහළ යන තෙක් කිසිවෙකු එය නොදකී.
පසුව එක් කන්ටේනර ලිපිනයක් සඳහා මාර්ග තේරීම සසඳන්න — එක් වරක් උමග වැසී ඇති විට, එක් වරක් එය විවෘතව ඇති විට:
ip route get 172.18.0.7
# 172.18.0.7 dev br-3f2a9c src 172.18.0.1පිළිතුරු ආකාර දෙකක් විවිධ තැන්වලට යාමට හේතු වේ. ප්‍රතිදානය tun0, wg0 හෝ වෙනත් උමග උපාංගයක් නම් කරන්නේ නම්, VPN උපසර්ගය අවම වශයෙන් පාලම් මාර්ගය තරම්ම නිශ්චිත වන අතර පැකට්ටුව කිසිදා කන්ටේනරයට ළඟා නොවේ. එය තවමත් පාලම නම් කරන්නේ නම්, සත්කාරකයට කන්ටේනරයට ළඟා විය හැක, ඔබේ දෝෂය පෙරීම, DNS හෝ එක් දිශාවකින් පමණක් අසාර්ථක වන ආපසු මාර්ගයකි.
/16 ගැටුමක් පහසුවෙන් සිදුවන්නේ ඇයි
Docker පෞද්ගලික තටාකවලින් පාලම් ජාල ලබා ගනී, පෙරනිමි තටාකය 172.16.0.0/12 කොටසින් /16 කැබලි ලෙස පැමිණේ. ආයතනික ජාල බොහෝ විට එම පෞද්ගලික අවකාශයම භාවිත කරයි, දුරස්ථ ප්‍රවේශ VPN එම උපසර්ග සම්බන්ධ වන සෑම සේවාදායකයකුටම තල්ලු කරයි. දෙපිරිසම 172.18.0.0/16 තමන් සතු යැයි විශ්වාස කරන විට, එක් මාර්ගගත කිරීමේ වගුවක පරස්පර විරෝධී හිමිකම් දෙකක් ඇත.
ජයග්‍රාහකයා තීරණය කරන්නේ උපසර්ග දිග මිස මාර්ග අනුපිළිවෙල නොවේ. 10.0.0.0/8 තල්ලු කරන උමගක් 172.18.0.0/16 පාලම් මාර්ගය නොපරදවයි, මන්ද /8 අඩු නිශ්චිත ය. 172.18.0.0/16 හෝ එහි ඇති 172.18.5.0/24 තල්ලු කරන උමගක් පරදවයි. එබැවින් එක් ලැප්ටොප් පරිගණකයක් කාර්යාල ජාලයේ වැඩ කරමින් එම VPN සමඟ හෝටල් Wi-Fi එකේ අසාර්ථක වන්නේ එලෙසය: සේවාදායකයට විවිධ උපසර්ග ලැබේ.
එම වගුවම අනෙක් දිශාව ද පාලනය කරයි. 10.8.4.20 ලිපිනයේ අභ්‍යන්තර සත්කාරකයක් අවශ්‍ය කන්ටේනරයක් පැකට්ටුව තම පාලම් ද්වාරයට යවයි, පසුව සත්කාරකය එය උමගට මාර්ගගත කරයි. සත්කාරකය NAT සිදු කරන බැවින් එම මාර්ගය සාමාන්‍යයෙන් වැඩ කරයි, නමුත් ආයතනික පැත්ත ලැප්ටොප්හි VPN ලිපිනය පමණක් පිළිගන්නා විට, හෝ ප්‍රතිලෝම මාර්ග පෙරීම අසමමිතික පිළිතුර ඉවත දමන විට එය අසාර්ථක වේ.
අලුත්වැඩියා තුන සසඳන්න
පිටවීමට මාර්ග තුනක් පමණක් ඇත, ඒවා කවුරුන් අනුමත කළ යුතු ද සහ එකක් යෙදීමේදී කුමක් බිඳේ ද යන්නෙන් වෙනස් වේ.
| Repair | Who owns it | What it costs |
|---|---|---|
| Renumber the container network | You | Recreates the network, restarts services, invalidates literal addresses in configs and scripts |
| Exclude your range from the tunnel | Network team | Changes what every laptop sees, needs a change request and a client profile update |
| Reach the service through a published port | You and the client | One port only, no direct container-to-container routing across the tunnel |
ටිකට් පතක් නොමැතිව අවසන් කළ හැකි එකම අලුත්වැඩියාව නැවත අංකනයයි, එබැවින් බොහෝ ලිපි එහි නතර වේ. නව ව්‍යාපෘතියක එය ලාභදායී වන අතර, සංක්‍රමණ මෙවලමක් හෝ ගබඩා කළ සම්බන්ධතා තන්තුවක් වචනාර්ථ ලිපිනයකට යොමු වූ පසු එය මිල අධික වේ. YAML සංස්කරණය කිරීමට පෙර එම යොමු ගණන් කරන්න, පසුව නොවේ.
අතිච්ඡාදනය ඔබේ සමාගමට සැබවින්ම හිමි පරාසයක ඇති විට උමගෙන් ව්‍යතිරේකය පිරිසිදුම පිළිතුරයි. එය මන්දගාමී ම ද වන අතර, සේවාදායක පැතිකඩ වෙනස් කළ නොහැකි කොන්ත්‍රාත්කරුවකුට එය නිෂ්ඵල ය. ප්‍රකාශිත වරායක් හෝ කුඩා ප්‍රතිලෝම නියෝජිතයක් මෙම තර්කය මඟ හරියි: සේවාදායකය උමග දැනටමත් නිවැරදිව මාර්ගගත කරන ලිපිනයක් සමඟ කථා කරයි, එම වරාය පමණක් ළඟා විය හැකි විය යුතුය.
චේතනාන්විතව පරාසයක් සවි කරන්න
එක් ව්‍යාපෘතියක් සඳහා, ව්‍යාපෘතිය හවුල් තටාකයෙන් ගැනීම නවත්වන පරිදි compose ගොනුවේ උපජාලය ප්‍රකාශ කරන්න:
networks:
default:
ipam:
config:
- subnet: 10.201.7.0/24එම පරාසය සොයන විට හමු වූ උදාහරණයකින් නොව, ඔබේ කණ්ඩායම තබා ගන්නා ලේඛනයකින් ගන්න. VPN තල්ලු කරන උපසර්ග, මිනිසුන් වැඩ කරන නිවෙස් LAN සහ එම සත්කාරකයේ අනෙක් කන්ටේනර ජාල සමඟ එය පරීක්ෂා කරන්න. පසුව නැවත නිර්මාණය සැලසුම් කරන්න, මන්ද පවතින ජාලයක් එහි පැරණි උපජාලය රඳවා ගනී: docker compose down, පසුව up -d. අන්ත ලක්ෂ්‍ය සම්බන්ධව ඇති විට docker network rm ප්‍රතික්ෂේප කරයි, ගොනුවේ ඕනෑම ipv4_address සටහනක් නව පරාසය තුළ විය යුතුය.
Docker තමන්ම සාදන ජාල සඳහා, /etc/docker/daemon.json තුළ ඩීමන් තටාකයක් සකසන්න:
{
"default-address-pools": [
{ "base": "10.201.0.0/16", "size": 24 },
{ "base": "10.202.0.0/16", "size": 24 }
]
}මෙම තටාකය ඩීමන් නැවත ආරම්භ වූ පසු සාදන ජාල සඳහා අදාළ වේ, දැනටමත් ඇති පාලම් ඒවායේ ලිපින රඳවා ගනී. එය පහසු වන අතර අමතක කිරීම ද පහසු ය, එබැවින් කිසිවෙකු එහි ජාලය නැවත නිර්මාණය කරන තෙක් පැරණි ව්‍යාපෘතියක් තවමත් අතිච්ඡාදනය වන ලෙස සලකන්න. Docker හි එන්ජිම් ජාලකරණ ලේඛනය සමාලෝචනයේදී තටාකය ආරක්ෂා කිරීමට අවශ්‍ය නම් වෙන් කිරීමේ නීති විස්තර කරයි.
Linux පාලම සහ Docker Desktop වෙනස් ලෙස අසාර්ථක වේ
Linux සත්කාරකයක, කන්ටේනර සත්කාරකයේ නාම අවකාශයේ පාලම් මත වාඩි වේ. සියල්ල තීරණය කරන්නේ එක් වගුවක් ය, එබැවින් ඉහත සංසන්දනය මුළු කතාවම ය: පාලම් මාර්ගය කියවන්න, උමග මාර්ගය කියවන්න, සැබෑ කන්ටේනර ලිපිනයකට ජය ගන්නේ කුමක් දැයි බලන්න.
Docker Desktop කන්ටේනර තමන්ගේම NAT ඇති VM එකක් පිටුපස තබයි. සත්කාරකයට කන්ටේනර ලිපිනයට කිසිසේත් මාර්ගයක් නැත; එය සේවාවට ළඟා වන්නේ ප්‍රකාශිත වරායක් හරහා ය, සාමාන්‍යයෙන් 127.0.0.1 වෙත බැඳී ඇත. එබැවින් VPN සේවාදායකයකට කිසිදු උපජාල අතිච්ඡාදනයකින් තොරව සේවාව බිඳිය හැක: VM හි අභ්‍යන්තර පරාසය සඳහා මාර්ගයක් ස්ථාපනය කිරීමෙන් හෝ උමග සම්බන්ධව ඇති විට loopback රථවාහන අවහිර කිරීමෙන්. සත්කාරකයේ ip route get කන්ටේනර ලිපිනයට මාර්ගයක් නැතැයි වාර්තා කරන්නේ නම්, එය අපේක්ෂිත ය, දෝෂය නොවේ.
ප්‍රායෝගික ප්‍රතිවිපාකය වන්නේ ඔබ මුලින්ම බලන්නේ කොහේ ද යන්නයි. Linux හි, මාර්ගගත කිරීමේ වගුවෙන් ආරම්භ කරන්න. Desktop හි, ප්‍රකාශිත වරායෙන් සහ VPN සේවාදායකයේ ගිනිතාප්ප නීතිවලින් ආරම්භ කර, පසුව VM හි අභ්‍යන්තර උපජාලය උමග තල්ලු කරන දෙයක් සමඟ ගැටෙන්නේ දැයි පරීක්ෂා කරන්න.
උමග විවෘතව තබා තහවුරු කරන්න
මෙය විසඳා ඇතැයි පැවසීමට පෙර VPN දෙවරක් නැවත සම්බන්ධ කරන්න, මන්ද සම්බන්ධ වන විට මාර්ග තල්ලු කර විසන්ධි වන විට ඒවා ඉවත් කරන පැතිකඩක් පළමු උත්සාහයෙන් පසු නිවැරදි ලෙස පෙනිය හැක. පසුව සේවාදායකය සැබවින්ම කරන පරීක්ෂණ ක්‍රියාත්මක කරන්න:
- කන්ටේනරයේ සැබෑ ලිපිනය භාවිතා කරමින් සත්කාරකයෙන්
ip route get. - සේවාවම සුවපහසු බව ඔප්පු කිරීමට තවත් කන්ටේනරයකින් ඉල්ලීමක්.
- උමග විවෘතව ඇති විට සේවාදායකයෙන්
curl -sv http://127.0.0.1:8080/, පසුව LAN හි යන්ත්‍රයකින් කන්ටේනර ලිපිනයටtraceroute -n. - ඉල්ලීම සත්කාරකයට ළඟා වී පිළිතුර අතුරුදහන් වේ නම්
sysctl net.ipv4.conf.all.rp_filter.
අවසාන වශයෙන්, තෝරාගත් පරාසය එය තෝරාගත් එම ලේඛනයේම දිනය සහ එය හිමි ව්‍යාපෘතිය සමඟ ලියන්න. ඊළඟ අතිච්ඡාදනය කිසිවෙකු ලේඛනගත නොකළ ව්‍යාපෘතියකින් පැමිණේ, එකම ආරක්ෂාව වන්නේ පරාසය අහඹු ලෙස නොව චේතනාන්විතව වෙන් කර තිබීමයි.