NAT සහ Bridged VM ජාලකරණය: VPN ගමන් ප්රවාහය ගෙනයන්නේ කුමක්ද?
NAT අමුත්තන් හෝස්ට් ටනලය ණයට ගන්නේ ක්ලයන්ටය මාර්ගයෙන් ටනල් කරන විට පමණි; bridged අමුත්තන් තමන්ම මාර්ගගත වේ. අමුත්තා පරීක්ෂා කර, ගැළපෙන මාදිලිය තෝරන්න.
Bridged සහ NAT කියන්නේ එකම අමුත්තා ඔබේ VPN එකට සම්බන්ධ කරන ක්රම දෙකක් නොවේ; ඒවා තීරණය කරන්නේ, කිසිදු ටනලයක් සම්බන්ධ වීමට පෙර අමුත්තාගේ පැකට් අයිති කාටද කියාය. NAT මාදිලියේදී හයිපර්වයිසරය අමුත්තාගේ ප්රවාහය නැවත ලියා හෝස්ට් පැත්තේ කේතයකින් පිට කරයි, එබැවින් අමුත්තා ගමන් කරන්නේ හෝස්ට් එම කේතයට දෙන මාර්ගයේය. Bridged මාදිලියේදී අමුත්තාට භෞතික කොටසේ තමන්ගේම සබැඳි ස්ථර අනන්යතාවක් ලැබෙන අතර තමන්ගේම පෙරනිමි ගේට්වේ තෝරා ගනී, එයින් හෝස්ට්ගේ ටනලය ඔහුට අදාළ නොවන දෙයක් බවට පත්වේ, LAN රවුටරයම ටනල් කරන්නේ නම් මිස. මම VM එක VPN එකේ ඇති දෙයක් ලෙස සැලකීම නවතා, එය එම අමුත්තාගේ පෙරනිමි මාර්ගය කොහෙද යන්නේ යන ප්රශ්නයක් ලෙස සැලකීම ආරම්භ කළෙමි. පහත පරීක්ෂණයට එක් මාදිලියකට මිනිත්තු කිහිපයක් ගතවන අතර අනුමාන නොකර එය විසඳයි.
NAT අමුත්තා හයිපර්වයිසර් කේතය පිටුපස තබා ගනී, එහිදී හෝස්ට් මාර්ග බලපායි
VirtualBox හි NAT අමුත්තෙක් 10.0.2.0/24 තුළ, 10.0.2.2 හි අතථ්ය ගේට්වේ එකක්, 10.0.2.3 හි DNS ප්රොක්සියක් සමඟ වාසය කරන අතර භෞතික ජාලයට තමන්ගේම මාර්ගයක් නොමැත. පිටතට යන පැකට් NAT එන්ජිම විසින් ගෙන, මූලාශ්රය හෝස්ට් වන පරිදි නැවත ලියා හෝස්ට්ගේ IP ස්ටැක් එකට භාර දෙයි. එතැන් සිට අමුත්තාගේ ප්රවාහය හෝස්ට් ප්රවාහයක් වන අතර මාර්ග සෙවීම ගමනාන්තය අනුව සිදුවේ: හෝස්ට් එකේ 0.0.0.0/1 සහ 128.0.0.0/1 ස්ථාපනය කරන පූර්ණ ටනල් ක්ලයන්ටයක් VM එකක් ඇති බව නොදැනම එය අල්ලා ගනී. Oracle හි VirtualBox ජාලකරණ පරිච්ඡේදය ඔබේ build එකේ ලිපින තහවුරු කර ගැනීමට අවශ්ය නම් මෙම පෙරනිමි අගයන් ලැයිස්තුගත කරයි.
libvirt හි පෙරනිමි ජාලය 192.168.122.0/24 සිට එම තැනටම ළඟා වේ, එහිදී dnsmasq බදු නිකුත් කරන අතර හෝස්ට් උපජාලය මාස්ක් කරයි, එබැවින් අමුත්තාගේ පැකට් නැවතත් හෝස්ට්ගේ මාර්ග තීරණයට පැමිණේ. ව්යතිරේකය නම් මාර්ගය අනුව නොව ක්රියාවලිය අනුව ප්රවාහය තෝරන ක්ලයන්ටයකි. බෙදුණු ටනල් ලැයිස්තුවේ ඔබේ බ්රවුසරය පමණක් තිබේ නම්, NAT එන්ජිම එම ලැයිස්තුවේ නැත, එබැවින් හෝස්ට් බ්රවුසරය තවමත් ආවරණය වී ඇති ලෙස පෙනෙද්දී අමුත්තා ටනලයක් නොමැතිව යන්ත්රයෙන් පිටවේ. එකම උපජාලය, ප්රතිවිරුද්ධ ප්රතිඵලය.
Bridged අමුත්තාට භෞතික LAN එකේ තමාගේම තැනක් දෙයි
Bridged අමුත්තෙකුට සැබෑ ඇඩැප්ටරයකට සම්බන්ධ අතථ්ය NIC එකක් ලැබෙන අතර, තමන්ගේම MAC ලිපිනයක් ලබා භෞතික ජාලයෙන් DHCP බද්දක් ගනී. ඔහුගේ පෙරනිමි ගේට්වේ යනු LAN රවුටරයයි, හයිපර්වයිසරය නොවේ, ඔහුගේ රාමු එම ඇඩැප්ටරය හරහා රැහැනට යයි. හෝස්ට්ගේ ටනල් මාර්ග හෝස්ට්ගේ වගුවේ ඇති අතර කිසිදා විමසා නොබලයි, මන්ද අමුත්තාගේ රාමු කිසිදා හෝස්ට්ගේ IP ස්ටැක් එකට ඇතුළු නොවේ.
එය දෙපැත්තටම කපයි. අමුත්තාට LAN විකාශන ප්රවාහය පෙනෙන නිසා mDNS සහ SMB බ්රවුස් කිරීම වැඩ කරන්නට පටන් ගනී, අමුත්තා අතරමැද හෝස්ට් ෆයර්වෝලයක් නොමැතිව එම කොටසේ අනෙක් යන්ත්රවලින් ළඟා විය හැකි වේ. Bridging කියන්නේ පවතින ටනලයක් හරහා අමුත්තා තල්ලු කරන ක්රමයක්ද නොවේ: VM එකක් හෝස්ට්ගේ WireGuard හෝ OpenVPN අතුරුමුහුණතට සම්බන්ධ කිරීම VirtualBox හෝ libvirt ඔබ වෙනුවෙන් කරන දෙයක් නොවේ. Bridged අමුත්තෙකුට ටනල් කිරීම අවශ්ය නම්, ටනලය එම LAN එකේ කොහේ හෝ අවසන් විය යුතුය.
තර්කය අවසන් කරන පරීක්ෂණය
මාදිලි දෙකේම එකම පරීක්ෂණ ධාවනය කර පිළිතුරු ලියන්න:
- හෝස්ට් එකේ,
curl -s https://ifconfig.meපොදු v4 ලිපිනය ලබා දෙයි. - අමුත්තා තුළ, එම විධානයම, අමතරව
ip routeLinux හි හෝGet-NetRoute -DestinationPrefix 0.0.0.0/0Windows හි පෙරනිමි ගේට්වේ සඳහා. - විසඳුම්කරුගේ අනන්යතාවය:
resolvectl statusහෝcat /etc/resolv.confඅමුත්තා තුළ, එය 10.0.2.3 වෙතද නැතහොත් LAN සේවාදායකයකටද යන්න බැලීමට. - ලිපින පවුල:
ip -6 addr show scope globalසහ එක් v6 ඉල්ලීමක්, මන්ද v4 ටනලයක් අමුත්තාට තිබිය හැකි ගෝලීය v6 ලිපිනයක් ගැන කිසිවක් නොකියයි.
ගැළපෙන පොදු ලිපින යනු අමුත්තා හෝස්ට්ගේ මාර්ගයේ සිටින බවයි. LAN එකේ සාමාන්ය පිටවීමට ගැළපෙන අමුත්තාගේ ලිපිනයක් යනු එසේ නොවන බවයි. මිනිසුන් මඟ හරින පියවර වන්නේ පාලනයයි: හෝස්ට් ටනලය පහත හෙළා අමුත්තාගේ ඉල්ලීම නැවත කරන්න. අමුත්තා දිගටම බ්රවුස් කරන්නේ නම්, මාදිලියේ නම කුමක් කීවත් ඔහු කිසිදා හෝස්ට් ටනලය මත රඳා නොසිටියේය. NAT මාදිලියේදී හෝස්ට් ටනලය පහත ඇති විට අමුත්තාට අන්තර්ජාලය අහිමි විය යුතුය, ක්ලයන්ටය ටනලයෙන් පිටත ප්රවාහයට ඉඩ දෙන ලෙස වින්යාස කර නොමැති නම් මිස, එය වෙනම දැනගැනීම වටී.
සංඥා දෙකක් බොරු කියයි. සාර්ථක ping එකක් ඔප්පු කරන්නේ ළඟාවීම, පිටවීමේ මාර්ගය නොවේ. තවද DNS පිළිතුරු දිය හැක්කේ හෝස්ට් විසඳුම්කරු හරහා 10.0.2.3 ප්රොක්සිය මගිනි, TCP වෙනත් මාර්ගයක් ගන්නා අතරතුර, එලෙසම තමයි පිටුවක් පූරණය වී පිවිසුමක් කිසිදා සම්පූර්ණ නොවන්නේ.
කාර්යයට ගැළපෙන මාදිලිය
මාදිලිය යනු මාර්ග තීරණයකි, එබැවින් පුරුද්දට වඩා අවශ්යතාවයෙන් එය තෝරන්න:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
පළමු පේළිය යනු මිනිසුන් අසුවන තැනයි: NAT සහ හෝස්ට් එකේ පූර්ණ ටනල් ක්ලයන්ටයක් අමුත්තා ඇත්තෙන්ම ආවරණය කරයි, නමුත් ක්ලයන්ටය මාර්ගයෙන් ටනල් කරන තාක් සහ හෝස්ට්ගේ ඉහළ සබැඳිය එම ටනලය වන තාක් පමණි. ක්ලයන්ටය බ්රවුසරයට පමණක් අවසර දෙන ලැයිස්තුවකට මාරු කරන්න, ආවරණය කොතැනකවත් දෝෂයක් නොමැතිව අතුරුදහන් වේ. හතරවන පේළිය ප්රතිවිරුද්ධ වැරැද්දයි, පහසුව සඳහා bridged කළ අමුත්තෙක් නිහඬව කාර්යාල LAN එකේ SMB හෝ SSH වලට පිළිතුරු දෙන්නට පටන් ගනී.
VPN එකට පවරන අසාර්ථකතා
Windows හි NAT පරිවර්තනය VirtualBox VM ක්රියාවලිය තුළ ධාවනය වේ, එබැවින් යෙදුම් අනුව ක්රියා කරන ක්ලයන්ටයකට ලැයිස්තුවේ එම රූපයම අවශ්ය වේ, අතථ්ය යන්ත්ර සඳහා පොදු නියමයක් නොවේ. ක්ලයන්ට් යාවත්කාලීනයක් එහි ක්රියාවලි ලැයිස්තුව නැවත ගොඩනඟන විට, NAT අමුත්තන් පළමුව ආවරණය අහිමි කර ගනී, වාර්තාව කියවෙන්නේ හෝස්ට් හොඳින් තිබියදී LAN එකට ළඟා වුවත් අන්තර්ජාලයට නොළඟා වන VM එකක් ලෙසය.
Wi-Fi වෙත bridging අනෙක් සම්භාව්ය අවස්ථාවයි. ප්රවේශ ස්ථාන විදේශීය මූලාශ්ර MAC එකක් රැගෙන යන රාමු කලාතුරකින් ඉදිරියට යවයි, එබැවින් wlan0 වෙත යන bridge එකක් එක්කෝ කෙලින්ම අසාර්ථක වේ, එක්කෝ AP එකේ සේවාලාභී හුදකලාව එය අතහැරීමට පටන් ගන්නා තාක් වැඩ කරයි. VirtualBox තවමත් ලැයිස්තුවේ රැහැන් රහිත ඇඩැප්ටරය ලබා දෙනු ඇත. හෝස්ට් Wi-Fi හි ඇති අතර අමුත්තා bridged විය යුතු නම්, උපකල්පනය නොකර පරීක්ෂණයක් සැලසුම් කරන්න.
MTU යනු තුන්වැන්නයි. Bridged අමුත්තෙක් LAN එකේ 1500 බයිට් MTU රඳවා ගනී, ඔහු තමන්ගේ WireGuard ක්ලයන්ටය 1420 හි ධාවනය කරන්නේ නම්, විශාල TLS අතට අත දීම් ඇනහිටින අතර කුඩා ඉල්ලීම් සාර්ථක වේ. NAT යටතේ හෝස්ට් ටනලයේ MTU හෝස්ට්ගේ ගැටලුවයි, නමුත් අමුත්තා තවමත් 1500 විශ්වාස කරන අතර don't-fragment බිට් යොදා ඇති UDP එලෙසම කළු කුහරයකට වැටේ.
මාදිලිය ලියා ඕනෑම ඇඩැප්ටර් වෙනසකට පසු නැවත පරීක්ෂා කරන්න
මාදිලිය, bridge එක භාවිත කරන හෝස්ට් අතුරුමුහුණත, අමුත්තාගේ පෙරනිමි ගේට්වේ, ඔහුගේ විසඳුම්කරු සහ ඔහුගේ v4 සහ v6 පිටවීම් ලිපින සටහන් කරන්න. එම වාර්තාව තමයි ඊළඟ අසාර්ථකතාව ලාභදායක කරන්නේ: ලැප්ටොප් එකක් dock එකේ සිට Wi-Fi වෙත ගමන් කරන විට, bridged අමුත්තෙක් bridge එක වෙනත් භෞතික ඇඩැප්ටරයක් වෙත අනුගමනය කර නැවත තවත් උපජාලයකට බදු ගත හැක, එහෙත් NAT අමුත්තෙක් තම 10.0.2.x ලිපිනය රඳවා ගෙන නිහඬව වෙනත් ඉහළ සබැඳියක් උරුම කර ගනී.
ටිකට්ටුව වසා දැමීමට පෙර මේ සෑම එකක්ම තහවුරු කරන්න:
- අමුත්තාගේ පිටවීම් ලිපිනය හෝස්ට්ගේ පිටවීම් ලිපිනයට වඩා වෙනස්ය, එබැවින් එය හෝස්ට් ටනලයේ නැත.
- විසඳුම්කරු 10.0.2.3 ප්රොක්සිය හෝ LAN සේවාදායකයකි, ඒවායින් පිළිතුරු දුන්නේ කවුද යන්න ඔබ දන්නවා.
- ටනල් සැලසුම v4 පමණක් නම් අමුත්තා තුළ ගෝලීය v6 ලිපිනයක් නොපවතී.
- හෝස්ට් ටනලය පහත හෙළූ විට අමුත්තා බ්රවුස් කිරීම නවත්වයි, නැතහොත් ඔහු කිසිදා එය මත රඳා නොසිටි බව දැන් ඔබ දන්නවා.
- තමාට බැලීමට කිසිදු අයිතියක් නැති LAN විකාශන ප්රවාහය අමුත්තා දකින්නේ නැත.