හොස්ට් VPN නොසලකා හරින Docker සහ WSL රථවාහන නිවැරදි කරන්න

කන්ටේනර සහ WSL තමන්ගේම මාර්ග, විසඳන්නා සහ යැවීමේ මාර්ගය තබා ගනී, එබැවින් ක්‍රියාකාරී හොස්ට් ටනලයක් ඒවා පැරණි DNS සමඟ හෝ පිටවීමක් නොමැතිව තබයි. සෑම ස්තරයක්ම නිවැරදි කරන්න.

මෙම වසන්තයේ උදෑසනක වැඩි කාලයක් මම එකම අභ්‍යන්තර නාමයක් පවා විසඳා ගත නොහැකි කන්ටේනරයක් පසුපස හඹා යමින් ගත කළෙමි, අතර පැත්තේ තිබූ බ්‍රවුසරය කිසිදු පැමිණිල්ලක් නොමැතිව විකිය විවෘත කළේය. ටනලය ඉහළින් තිබුණි, බ්‍රවුසරය එය ඔප්පු කළේය, සහ කන්ටේනරය වෙනත් මාර්ග වගුවක් සහ වෙනත් විසඳන්නෙකු සහිත තවත් ජාල නාම අවකාශයක තිබුණි. ඊළඟට එන්නේ මම දැන් පරීක්ෂා කරන අනුපිළිවෙලයි: පළමුව මාර්ග වගු, දෙවනුව නාම විසඳුම, තෙවනුව යැවීම සහ අවසානයේ හොස්ට් වේදිකාව. දැනටමත් අසාර්ථක වන පළමු පියවරේදී නවතින්න, මන්ද තුඩුවේ පහළින් නීති එකතු කිරීම මායිම ගෙනයාම වෙනුවට සඟවයි.

නීතියක් වෙනස් කිරීමට පෙර මාර්ග වගු තුන සසඳන්න

Docker හි පෙරනිමි පාලමේ ඇති කන්ටේනරයට docker0 ද්වාරය වෙත යන එක් පෙරනිමි මාර්ගයක් ඇති අතර tun0 පවතින බව එය නොදනී. හොස්ටයට tun0, VPN විසින් තල්ලු කළ මාර්ග, සහ සමහරවිට ඔබ අපේක්ෂා කරන එකට වඩා වෙනස් අතුරුමුහුණතක් හරහා පරීක්ෂණ රථවාහන යවන ප්‍රතිපත්ති නීතියක් ඇත. WSL තමන්ගේම අතථ්‍ය අනුකරණය පිටුපස තෙවන වගුවක් එකතු කරයි. ඒවායින් එකක්වත් සංස්කරණය කිරීමට පෙර තුනම මුද්‍රණය කරන්න.

ContextCommandWhat a wrong answer looks like
Hostip route get 10.8.0.20Leaves a physical interface instead of tun0
Containerip routeOnly 172.17.0.0/16 via 172.17.0.1
Container DNScat /etc/resolv.confA public resolver, or an upstream the tunnel never pushed
WSLip addr; ip routeOnly the WSL subnet, no Windows VPN adapter

කන්ටේනරයේ එකම මාර්ගය පාලම නම් සහ tun0 එහි නාම අවකාශයේ කිසිදා නොපෙනේ නම්, පහළින් කිසිවක් උදව් නොකරනු ඇත: කිසිදු නාම සේවාදායක වෙනසක් මාර්ගයක් සාදන්නේ නැත, සහ කිසිදු මාර්ගයක් සහකරු පිළිගන්නා ටනල අනන්‍යතාව සාදන්නේ නැත. අනුපිළිවෙල වැදගත් වන්නේ ෂෙලය තුළ සිට DNS අසාර්ථකත්වය සහ මාර්ග අසාර්ථකත්වය එකම ලෙස පෙනෙන බැවිනි.

විසඳන්නා පොදු එකකට නොව ටනලය වෙත යොමු කරන්න

හොස්ටයේ, resolvectl status සෑම සබැඳියකටම DNS සේවාදායක ලැයිස්තුගත කරයි, සහ readlink -f /etc/resolv.conf ගොනුව systemd ස්ටබ් එකක්ද, NetworkManager ගොනුවක්ද, නැතිනම් සැපයුම්කරුවෙකුගේ සේවාලාභියෙකු නැවත ලියූ දෙයක්ද යන්න පවසයි. පරිශීලක-නිර්වචිත ජාලයක ඇති කන්ටේනරය තුළ, /etc/resolv.conf නම් කරයි 127.0.0.11, Docker හි කාවැද්දූ විසඳන්නා, එය ඩේමන් වින්‍යාස කළ upstream වෙත යවයි. නමුත් පෙරනිමි පාලමේ කන්ටේනරය සෑදූ විට හොස්ට් ගොනුවේ පිටපතක් ලබා එය තබා ගනී.

එම පිටපත නිසාම කන්ටේනරය ආරම්භ වූ පසු ඉහළ එන ටනලය කන්ටේනරය පැරණි upstream වෙතින් අසන ලෙස තබයි. එක්කෝ VPN විසඳන්නා පැහැදිලිව මෙය සමඟ යවන්න docker run --dns 10.8.0.53, නැත්නම් "dns": ["10.8.0.53"] තුළ /etc/docker/daemon.json සකසා ඩේමන් නැවත අරඹන්න, නැත්නම් ටනලය ඉහළ ආ පසු කන්ටේනරය නැවත සාදන්න. නැවත සෑදීම සාමාන්‍යයෙන් පැයකට පෙර නිවැරදි වූ විසඳන්නෙකු ඩීබග් කිරීමට වඩා ලාභදායීය.

පොදු විසඳන්නෙකු දැමීම රෝග ලක්ෂණය තබා ගන්නා අලුත්වැඩියාවයි. එය අන්තර්ජාලය විසඳා ගනී නමුත් සෑම පුද්ගලික කලාපයකම අසාර්ථක වේ, සහ ටනලය පවතින හේතුව වන පෙරහැරීම නිශ්ශබ්දව මගහැරිය හැක. ඔබ ක්‍රියාත්මක වන කන්ටේනරයක /etc/resolv.conf තුළ ලිවීමට උත්සාහ කරන්නේ නම්, අපේක්ෂා කරන්න Device or resource busy: Docker එම ගොනුව bind-mount කරයි, එබැවින් සංස්කරණයට පළමුව unmount අවශ්‍යය. --dns සෑදීමේදී සැකසීම නැවත ආරම්භය ගැලවෙන අනුපිළිවෙලයි.

කන්ටේනර ටනලය ණයට ගන්නා විට යවන්න සහ පරිවර්තනය කරන්න

පෙරනිමි පාලම සමඟ, හොස්ටය docker0 සහ tun0 අතර රවුටරයකි, සහ පෙරනිමියෙන් එය දෙකෙන් කිසිවක් නොකරයි. යැවීම සක්‍රීය කර මූලාශ්‍ර ලිපිනය පරිවර්තනය කරන්න, එවිට සහකරුට ආපසු මාර්ගයක් නොමැති ලිපිනයක් වෙනුවට හොස්ටයේ ටනල ලිපිනය පෙනේ (tun0 ඔබේ සේවාලාභියා අතුරුමුහුණතට දෙන නමින් වෙනස් කරන්න):

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i docker0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o docker0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

FORWARD නීති යැවීමේ ප්‍රතිපත්තිය DROP වන හොස්ට්වල වැදගත් වේ. Docker තමන්ගේම දාම ඇතුළු කරයි, එබැවින් කියවීම වෙනුවට පැකට්ටුවකින් පරීක්ෂා කරන්න iptables -S: කන්ටේනරයෙන්, ip route get 10.8.0.20 පාලම් ද්වාරය නම් කළ යුතුය, සහ nc -vz 10.8.0.20 443 විසඳන්නා වෙත නොව ටනලය වෙත සම්බන්ධ විය යුතුය හෝ කාලය ඉක්මවිය යුතුය.

MASQUERADE නොමැතිව සහකරුට 172.17.0.0/16 වෙත ආපසු මාර්ගයක් අවශ්‍ය වේ, එය බොහෝ දුරස්ථ ප්‍රවේශ VPN තල්ලු නොකරනු ඇත. මෙහිදී ප්‍රතිපත්ති පාදක සේවාලාභියා සැලසුම බිඳ දමයි: එය යම් UID හෝ cgroups වල රථවාහන පමණක් අල්ලා ගන්නේ නම්, ඔබේ යැවීමේ නීති ටනලය තුළ පැකට්ටුව කිසිදා නොදකිනු ඇත, සහ නිවැරදි කිරීම iptables හි නොව සේවාලාභියාගේ මාර්ගකරණ ප්‍රතිපත්තියේ පවතී. අතින් එකතු කළ නීති නැවත ආරම්භයේදී අතුරුදහන් වේ, එබැවින් ඒවා systemd ඒකකයක හෝ netfilter-persistent වගුවක තබා නැවත ආරම්භයෙන් පසු නැවත පරීක්ෂා කරන්න, මන්ද ප්‍රමාදව ඉහළ එන ටනලයකට ඒවා ගසාගෙන යා හැක.

ඉලක්කය හුදකලා කිරීම නම් ටනලය කන්ටේනරය තුළ තබන්න

එක් කන්ටේනරයක් නිශ්චිත නෝඩයක් හරහා පිටවිය යුතු නම්, එම කන්ටේනරය තුළ සේවාලාභියා ධාවනය කරන්න. එයට --cap-add NET_ADMIN සහ --device /dev/net/tun අවශ්‍ය වේ, එවිට එයට තමන්ගේම tun0, මාර්ග සහ ගිනි පවුර ඇත. වෙනත් කන්ටේනර එය හරහා ගමන් කරන්නේ නම්, කන්ටේනරය තුළ යැවීම සහ MASQUERADE නීතියද අවශ්‍ය වේ, සහ එම සහකරුවන්ට එය වෙත යොමු වන පැහැදිලි මාර්ගයක් හෝ ප්‍රතිශ්‍රේණියක් අවශ්‍ය වේ; Docker හි පෙරනිමි පාලම ඔබ වෙනුවෙන් එම මාර්ගය එකතු නොකරයි.

හොස්ට් ජාලකරණය, docker run --network host, ලාභදායී අනුවාදයයි: කන්ටේනරය හොස්ටයේ නාම අවකාශයට එකතු වී ටනල මාර්ග සෘජුවම දකී. එය ජාල හුදකලා කිරීමද අත්හැර දමයි, තොරතුරු මග ගැටීමට ආරාධනා කරයි, සහ ප්‍රායෝගිකව එය Linux විකල්පයකි. ප්‍රකාශිත තොරතුරු මගක් එයට ආදේශකයක් නොවේ. -p 8080:80 සේවාවක් හොස්ටයෙන් ළඟාවිය හැකි කරයි; එය අභ්‍යන්තර 10.x ලිපින කන්ටේනරය තුළින් ළඟාවිය හැකි නොකරයි, සහ දෙකම මිශ්‍ර කිරීම යනු මාර්ගකරණ ගැටලුවක් නිරාවරණය වූ දත්ත සමුදාය තොරතුරු මගක් බවට පත්වන ක්‍රමයයි.

නාම අසාර්ථකත්වය අතිච්ඡාදනය වන උපජාලයකින් වෙන් කරන්න

Docker හි පෙරනිමි පාලම 172.17.0.0/16 වන අතර බොහෝ ආයතනික VPN තටාක 172.16.0.0/12 තුළ පිහිටා ඇත. ටනලය එම පරාසය අත්පත් කර ගත් පසු, කන්ටේනරය සඳහා අදහස් කළ රථවාහන ඒ වෙනුවට ටනලය වෙත මාර්ගගත විය හැක. නාම අසාර්ථක වේ, දෝෂය DNS මෙන් පෙනේ, සහ ගැටලුව ලිපිනවල ඇත. ගමනාන්තය පරීක්ෂා කරන්න, විසඳන්නා නොව: ip route get 172.17.0.5 හොස්ටයේ, පසුව පාලම් උපසර්ගය VPN තටාකය සහ docker network inspect bridge --format '{{range .IPAM.Config}}{{.Subnet}}{{end}}' සමඟ සසඳන්න.

අලුත්වැඩියාව යනු පරාසයන්ගෙන් එකක් ගෙනයාමයි: එක්කෝ daemon.json තුළ Docker සඳහා වෙනත් පෙරනිමි ලිපින තටාකයක්, නැත්නම් සාන්ද්‍රකයේ වෙනත් තටාකයක්. මෙහි තවත් නාම සේවාදායකයක් එකතු කිරීම කිසිවක් නොකරයි, සහ ssh -b ද නොකරයි: සේවාලාභියා අතුරුමුහුණතකට බැඳීම මූලාශ්‍ර ලිපිනය වෙනස් කරයි, ටනලය තුළට යොමු වන ගමනාන්ත මාර්ගය නොව. ඉක්මන් කාර්ය බෙදීම: හොස්ටයේ විසඳෙන නමුත් කන්ටේනරයේ නොවිසඳෙන නාමය විසඳන්නාගේ ගැටලුවකි, අතර කන්ටේනරයේ එල්ලෙන නමුත් හොස්ටයේ ක්‍රියා කරන සෘජු IP සම්බන්ධතාව මාර්ග හෝ යැවීම් දාම ගැටලුවකි.

WSL සහ Docker Desktop Linux නීති අනුගමනය නොකරයි

එහි පෙරනිමි NAT මාදිලියේ, WSL තමන්ගේම අතථ්‍ය අනුකරණය පිටුපස ඉඳගනී සහ Windows VPN හි අභ්‍යන්තර මාර්ග හෝ DNS උපසර්ග නොලබයි, එබැවින් බ්‍රවුසරය ක්‍රියා කරයි සහ ping බෙදාහැරීම තුළ නොකරයි. මෑත Windows 11 ගොඩනැගීම්වල ඇති දර්පණ ජාලකරණය ඒ වෙනුවට හොස්ට් අතුරුමුහුණත් බෙදා ගනී, නමුත් එය .wslconfig තුළ සක්‍රීය කළ යුතු අතර බෙදාහැරීම wsl --shutdown සමඟ නැවත අරඹන්න. සක්‍රීය මාදිලිය wslinfo --networking-mode සමඟ තහවුරු කරන්න, නිවැරදි කිරීමක් යෙදීමට පෙර, මන්ද NAT පිළිතුර දර්පණ මාදිලියට වැරදි වන අතර අනෙක් අතටද.

Docker Desktop තවත් ස්තරයක් එකතු කරයි. Windows හි Linux කන්ටේනර ඓතිහාසිකව vpnkit ලෙස හඳුන්වන NAT ක්‍රියාත්මක කිරීමක් පිටුපස ඉඳගනී, සහ ඒවායේ මාර්ගය ස්වදේශීය Linux හොස්ටයට වඩා වෙනස්ය. Windows කන්ටේනර Hyper-V අතථ්‍ය ස්විචය හරහා සම්බන්ධ වේ, සහ ආයතනික සේවාලාභියෙකුට එම ස්විචයේ රථවාහන අවහිර කළ හැක, එබැවින් එකම යන්ත්‍රයේ Linux කන්ටේනර ජාලයට ළඟා විය හැකි අතර Windows කන්ටේනරවලට කිසිවක් නැත. භෞතික අනුකරණයට බැඳුණු බාහිර ස්විචයක් සාමාන්‍ය විසඳුම වන අතර, එය කන්ටේනරයේ ජාල අනන්‍යතාව ප්‍රතිපත්තිය අවසර නොදෙන ආකාරවලින් වෙනස් කරයි.

තවත් නීතියක් ලිවීමට පෙර, ස්තර හතර පිළිවෙලට ගොස් ඒවායින් එකක් වැරදි තැන නවතින්න:

  • කන්ටේනරය තුළ: ip route පුද්ගලික උපසර්ගයට ළඟා වේද, සහ /etc/resolv.conf එය විසඳන upstream එකක් නම් කරයිද?
  • හොස්ටයේ: යැවීම සක්‍රීයද, NAT ටනල අතුරුමුහුණතට බැඳී තිබේද, සහ යැවීම් දාමය පාලමේ සිට ටනලයට පිළිගනීද?
  • සහකරු අත: එය ආපසු මාර්ගයක් දන්නේද, නැත්නම් කන්ටේනර උපජාලය සැඟවීමට ඔබ NAT මත රඳා පවතීද?
  • වේදිකාවේ: WSL NAT හෝ දර්පණ මාදිලියේද, සහ කන්ටේනරය Linux ද Windows ද?

සෑම පරීක්ෂණයක්ම නව කන්ටේනරයක හෝ ෂෙලයක නැවත ධාවනය කරන්න. කැෂ් කළ පිළිතුරක් හෝ ස්ථාපිත සම්බන්ධතාවක් ඇති දිගුකාලීන ක්‍රියාවලියක් වින්‍යාසය නිවැරදි වූ පසුවත් අසාර්ථක වෙමින් පවතිනු ඇත, සහ එම අසාර්ථකත්වය ක්‍රියා නොකළ අලුත්වැඩියාවක් මෙන් හරියටම පෙනේ.

අදාළ ලිපි