VM තුළ VPN හරහා හොස්ට් ට්‍රැෆික් රවුට් කිරීම: චෙක්පත් හයක්

පිළිවෙලින් කරන චෙක්පත් හයක් තීරණය කරන්නේ VM එකක් එහිම හොස්ට් සඳහා VPN ද්වාරයක් විය හැකිද යන්නයි. හයිපර්වයිසර් මේ කිසිවක් ඔබ වෙනුවෙන් නොකරයි: ටනලය ගෙස්ට් සතුය, රවුටය හොස්ට් සතුය, ඒවා අතර ජාලය සාමාන්‍ය රවුටින්ග් ය. මම මේ ලැයිස්තුව තබා ගන්නේ එක් පියවරක් මඟ හැරීමෙන් සැමවිටම එකම ලක්ෂණය ලැබෙන නිසාය, නිහඬතාව, හොස්ට් ගෙස්ට්ට සතුටින් පිංග් කරන නමුත් ඇතුළත කිසිවකට නොපැමිණෙන තැන.

හේතුවෙන් පටන් ගන්න. එක්කෝ ආයතනික සේවාලාභියා ගෙස්ට් තුළම පමණක් ස්ථාපනය වේ, නැතහොත් ප්‍රතිපත්තිය එය එහිම තබා ගනී, ඔබට තවමත් හොස්ට් සිට ඇතුළත build සේවාදායකය අවශ්‍යය. හොස්ට්ට තමන්ගේම සේවාලාභියෙකු ලැබේ නම් එය කරන්න: හොස්ට් මත එක් ටනලයක් සැමවිටම ජාල දෙකක් සහ NAT එකකට වඩා උසස්ය.

චෙක්පත 1: හොස්ට්ට ලිපිනයක් දිය හැකි සබැඳියක් අවශ්‍යය

හොස්ට්ට ගෙස්ට්ගේ දෙවන ඇඩැප්ටරය සමඟ එකම ප්‍රීෆික්සයේ අතුරුමුහුණතක් තිබිය යුතුය. VirtualBox හි host-only, VMware Workstation හි host-only හෝ අභිරුචි VMnet, QEMU/KVM හි අභ්‍යන්තර පාලම හෝ tap උපාංගය, සහ Hyper-V හි Internal ස්විචය සියල්ල සුදුසුය. ගෙස්ට් 192.168.56.2, හොස්ට් 192.168.56.1, ප්‍රීෆික්ස් 192.168.56.0/24 මා පරීක්ෂණාගාරවල භාවිත කරන වින්‍යාසයයි.

QEMU හි පරිශීලක මාදිලි ජාලකරණය (-netdev user, පෙරනිමි SLIRP බැක්එන්ඩ්) සහ VirtualBox NAT මෙම චෙක්පත සම්පූර්ණයෙන් අසමත් වේ. ගෙස්ට්ගේ පැකට් හොස්ට් මත තැරැව්කාර ක්‍රියාවලියකට ළඟා වේ, එබැවින් හොස්ට් ගෙස්ට්ගේ ලිපින දරන උපාංගයක් කිසිදා නොදකින අතර රවුටයක් යොමු කිරීමට කිසිවක් නැත. Hyper-V හි Default Switch ද එකම කතාවය. හොස්ට් සිට ping 192.168.56.2 අසමත් වුවහොත් නවතින්න: පසුව එකතු කරන කිසිදු රවුටයක් එය නොසකසයි.

චෙක්පත 2: ගෙස්ට් ඉදිරියට යවයි සහ පරිවර්තනය කරයි

හොස්ට් සිට එන පැකට් host-only මූලාශ්‍ර ලිපිනයක් සහ අභ්‍යන්තර ගමනාන්තයක් සමඟ පැමිණේ, එබැවින් ගෙස්ට් ඒවා ඉදිරියට යවා පසුව තම ටනල් ලිපිනය පිටුපස සඟවා තැබිය යුතුය. Linux ගෙස්ට් එකක මින් අදහස් වන්නේ ඉදිරියට යැවීම, FORWARD accept යුගලයක්, සහ ටනලය දෙසට source NAT ය:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

MASQUERADE රීතිය යනු මිනිසුන් අත්හැර යන කොටසයි. ආයතනික රවුටර දැනගන්නේ කලාතුරකින් 192.168.56.0/24 පවතින බවයි; රීතිය සමඟ අභ්‍යන්තර සේවාදායක ගෙස්ට්ගේ ටනල් ලිපිනය දැක එයට පිළිතුරු දෙයි, සහ පිළිතුර නැවත ගෙස්ට් වෙත මාර්ගය සොයා ගනී.

Windows ගෙස්ට් වඩා අපහසුය. SYSTEM\CurrentControlSet\Services\Tcpip\Parameters යටතේ IPEnableRouter=1 පරිවර්තනයකින් තොරව ඉදිරියට යැවීම සක්‍රීය කරයි, එබැවින් ආයතනික රවුටින් දැනටමත් ඔබේ host-only ප්‍රීෆික්සය දෙසට ආපසු යොමු කරන තැන පමණක් එය ක්‍රියා කරයි. Internet Connection Sharing පරිවර්තනය කරයි, නමුත් බෙදාගත් ඇඩැප්ටරය 192.168.137.1 ලෙස නැවත අංකනය කරයි, එබැවින් හොස්ට් රවුට් ලිවීමට පෙර එය ඇත්තටම ගත් ලිපිනය කියවන්න.

චෙක්පත 3: හොස්ට් රවුට් ගෙස්ට් නම් කරයි, ටනලය නොවේ

හොස්ට්ට අවශ්‍ය ප්‍රීෆික්ස් පමණක් ගෙස්ට් හරහා යවන්න. Linux හි එක් ප්‍රීෆික්සයකට එක් රවුටයක් ප්‍රමාණවත් වන අතර එය පිරිසිදුව ආපසු හැරේ:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

Windows හි සමාන දෙය route add 10.20.0.0 mask 255.255.0.0 192.168.56.2 ය. පරීක්ෂා කරන අතරතුර -p ඉවත් කරන්න, නරක රවුටයක් නැවත ඇරඹීමේදී මිය යාමට, සහ මාර්ගය ක්‍රියා කළ පසු එය එකතු කරන්න. හොස්ට්ගේ පෙරනිමි රවුටය ඉවත් නොකරන්න, හොස්ට්හි සෑම යෙදුමක්ම ටනලය භාවිත කළ යුතු නම් මිස; සම්පූර්ණ ටනලයක් ඇත්තටම අවශ්‍යතාවය නම්, /1 රවුට් දෙක එකතු කර හයිපර්වයිසර් ජාලයට සෘජු රවුටය තබා ගන්න:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

Windows හොස්ට් එකක අතුරුමුහුණත් මෙට්‍රිකය ද පරීක්ෂා කරන්න. host-only ඇඩැප්ටරය අක්‍රීයව තිබියදී එකතු කළ රවුටය වගුවේ රැඳී ඇතත් කිසිදා ට්‍රැෆික් ගෙන යන්නේ නැත, සහ අඩු මෙට්‍රිකයක් ඇති දෙවන ඇඩැප්ටරයක් එකම ප්‍රීෆික්සය සඳහා සෙවීම ජය ගත හැක.

චෙක්පත 4: DNS රවුටය අනුගමනය කරයි, ටනලයේ පෙරනිමිය නොවේ

රවුට් පැකට් ගෙන යයි; විසඳන්නා තීරණය කරන්නේ කුමන නම් පැකට් සාදන්නේද යන්නයි. හොස්ට්ගේ විසඳන්නා ප්‍රතිස්ථාපනය කිරීම වෙනුවට ආයතනික විසඳන්නා ආයතනික කලාපයට සීමා කරන්න, සහ නව රවුටය දැනටමත් ළඟා වන DNS සේවාදායකයක් වෙත එය යොමු කරන්න. හොස්ට් මත systemd-resolved සමඟ:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

Windows හි නම් විසඳුම් ප්‍රතිපත්ති වගුවේ සටහනක් එකම කාර්යය කරයි: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. ගෙස්ට් host-only ලිපිනයේ තමන්ගේම විසඳන්නා ධාවනය කරන්නේ නම්, ඒ වෙනුවට එම ලිපිනය භාවිත කරන්න, නමුත් එය loopback මත නොව 192.168.56.2 මත පිළිතුරු දෙන බව තහවුරු කිරීමෙන් පසුව පමණි.

පසුව මන්දගාමී පිටු සඳහා DNS ට දොස් නැඟීමට පෙර MTU පරීක්ෂා කරන්න. ටනලයේ අතුරුමුහුණත හොස්ට්ගේ 1500 බයිට් අතුරුමුහුණතට වඩා කුඩාය, එබැවින් DF බිට් දමා සම්පූර්ණ ප්‍රමාණයේ කොටස් යවන හොස්ට් ඒවා ගෙස්ට් තුළ කොහේ හෝ අහිමි කරයි. සම්භාව්‍ය ලක්ෂණය නම් වැඩ කරන ping සහ TLS අත්වැල් ගැසීමෙන් පසු නතර වන අභ්‍යන්තර වෙබ් යෙදුමයි. ගෙස්ට්ගේ ඉදිරියට යැවීමේ මාර්ගයේ MSS තද කරන්න:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

චෙක්පත 5: දෙකෙළවරින්ම තහවුරු කරන්න

හොස්ට් සිට අභ්‍යන්තර ලිපිනයකට traceroute හෝ tracert පළමු හොප් ලෙස භෞතික ද්වාරය නොව 192.168.56.2 පෙන්විය යුතුය. ගෙස්ට් තුළ එම උත්සාහය පිටව යන අයුරු බලන්න: tcpdump -ni any host 10.20.30.40 host-only පැත්තේ ඉදිරියට යැවූ ඉල්ලීම සහ ටනලය මත පරිවර්තිත ඉල්ලීම පෙන්වයි. පිටව ගොස් ආපසු පැමිණ නමුත් හොස්ට් නිහඬව තබන ඉල්ලීම ආපසු මාර්ගය දෙසට යොමු කරයි.

මෙයින් බොහොමයක් අසමත්වීම් දෙකක් පැහැදිලි කරයි. එක්කෝ NAT රීතිය නොමැති නිසා ගෙස්ට්ගේ ටනලය host-only ප්‍රීෆික්සය සඳහා ආපසු රවුටයක් රැගෙන නොයයි, නැතහොත් නැවත ඇරඹීමෙන් පසු ගෙස්ට්ට නොමැති ලිපිනයකට හොස්ට් රවුටය යොමු වේ. පෙර සැසියේ සටහන් විශ්වාස කිරීම වෙනුවට ip -br addr සහ ip route get සමඟ ලිපින නැවත කියවන්න.

චෙක්පත 6: නැවත ඇරඹීමක් සහ හයිපර්වයිසර් උපග්‍රේඩයක් ඔරොත්තු දෙන ලෙස සාදන්න

දෙකොටසම ස්ථිර කරන්න: හොස්ට් මත netplan හෝ NetworkManager රවුට් වින්‍යාසය, Windows හි route add ... -p, සහ /etc/sysctl.d/ තුළ net.ipv4.ip_forward=1 සමඟ ගෙස්ට් තුළ නැවත පූරණය වන ෆයර්වෝල් රීති කට්ටලය. වින්‍යාසය තහවුරු වූ වහාම, ඊළඟ ආයතනික සේවාලාභී යාවත්කාලීනය පැමිණීමට පෙර ගෙස්ට්හි snapshot එකක් ගන්න.

හයිපර්වයිසර් තම ඇඩැප්ටර නැවත සාදන විට host-only ජාල නැවත අංකනය වේ, එය 192.168.56.0/24 මත ගොඩනගා ඇති සෑම රවුටයක්ම සහ NAT රීතියක්ම නිශ්ශබ්දව අවලංගු කරයි. උපග්‍රේඩයකින් පසු පළමු චෙක්පත් තුන පිළිවෙලින් නැවත ධාවනය කරන්න; එයට විනාඩියක් ගත වන අතර හොස්ට්ට තම රවුටය තවම ඇති අතර ගෙස්ට් නව උපජාලයකට ගොස් ඇති අවස්ථාව අල්ලා ගනී.

IPv6 ට තමන්ගේම වටයක් අවශ්‍යය. ip6tables රීති, AAAA වාර්තා සහ හොස්ට් රවුට්වල දෙවන පවුල IPv4 සැකසුම අනුගමනය නොකරයි, සහ IPv6 හරහා ළඟා විය හැකි ආයතනික සේවාවක් IPv4 ක්‍රියා කරන අතරේ සදාකාලිකව කැඩී ඇති ලෙස පෙනෙනු ඇත.

සමත් වුවත් නොවුවත්, පිළිවෙලින්: හොස්ට්ට ගෙස්ට්ගේ host-only ලිපිනයට පිංග් කළ හැක; ගෙස්ට් ටනලය දෙසට ඉදිරියට යවා MASQUERADE කරයි; ip route get අභ්‍යන්තර ප්‍රීෆික්සය සඳහා ද්වාරය ලෙස ගෙස්ට් ආපසු දෙයි; ආයතනික නම් සීමිත විසඳන්නා හරහා විසඳේ; traceroute ගෙස්ට් පළමුව පෙන්වයි; සහ එම පිළිතුරු හය නැවත ඇරඹීමෙන් පසුවද රැඳී ඇත.