සේවාදායක කවුළුව Connected යැයි කියයි, ටනල් ලිපිනය ඇත, නමුත් බ්‍රව්සරය තවමත් කැරකෙයි. එම සංයෝගය සාමාන්‍යයි, මන්ද සාර්ථක අත්වැල් ගැසීම සාධනය කරන්නේ ටනලය ගොඩනඟා ඇති බව පමණි; එය සේවාදායකයා ඔබේ පැකට් ඉදිරියට යවයිද, ඒවායේ මූලාශ්‍රය නැවත ලියයිද, නැතහොත් ඔබේ DNS විමසුම්වලට පිළිතුරු දෙයිද යන්න නොකියයි. බොහෝ දෙනා කරන වැරැද්ද නම් මුලින්ම සේවාදායක වින්‍යාසය විවෘත කිරීමයි. ඒ වෙනුවට සේවාදායකයාගෙන් පිටතට වැඩ කරන්න, මන්ද පහත සෑම පියවරක්ම ඊළඟ පියවර පරීක්ෂා කිරීම වටීද යන්න කියයි.

සේවාදායකයාගෙන් ආරම්භ කර පිටතට යන්න

මෙම අනුපිළිවෙලින් පරීක්ෂණ තුනක් කර පළමුවැන්න අසාර්ථක වන්නේ කොහේද යන්න ලියන්න. සේවාදායකයාගේ ටනල් ලිපිනයට ping කරන්න, එය ටනලයම රථවාහන ගෙන යන බව සාධනය කරයි. සංඛ්‍යාවකින් පොදු ලිපිනයකට ping කරන්න, එය නම් විසඳීම ඇතුළත් නොකර ඉදිරියට යැවීම සහ පරිවර්තනය සාධනය කරයි. පසුව සත්කාරක නාමයක් විසඳීමට උත්සාහ කරන්න, එය DNS භාවිත කරන එකම පරීක්ෂණයයි. සෑම ප්‍රතිඵලයක්ම සැකයෙන් සම්පූර්ණ ස්ථරයක් ඉවත් කරයි.

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

ග්‍රහණ දෙකක් පෙන්වන්නේ පැකට් නවතින තැනයි

සේවාදායකයාගෙන් පොදු ලිපිනයකට ping ගමන් කරන අතර ටනල් අතුරුමුහුණතේ එක් ග්‍රහණයක් සහ අන්තර්ජාලයට ළඟා විය යුතු ඉහළ සබැඳියේ තවත් ග්‍රහණයක් ගන්න. කාල මුද්‍රා ගැළපෙන පරිදි දෙකම එකවර ධාවනය කරන්න.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

ඉල්ලීම් ටනලයේ පෙනී ඉහළ සබැඳියේ කිසි විටෙකත් නොපෙනේ නම්, සේවාදායකයා ඒවා ටනලය සහ කම්බිය අතර ඉවතට දමා ඇත, හේතුව ඉදිරියට යැවීම හෝ ඉදිරියට යැවීමේ ගිනි පවුරු ප්‍රතිපත්තිය මිස NAT නොවේ. දෙකේම පෙනේ නම්, සේවාදායකයා තම කොටස කර ඇති අතර පිළිතුර තවත් ඈතින් නැති වී ඇත, එය පරිවර්තනය, ඉහළ පෙරහනක් හෝ සැපයුම්කරු පැත්තේ සීමාවක් කරා යොමු කරයි.

ඉහළ සබැඳියේ නම උපදේශකයෙකුගෙන් නොව මාර්ගගත වගුවෙන් ගන්න. ක්ලවුඩ් රූප සහ නැවත නම් කළ ඇඩැප්ටර මාර්ගෝපදේශයේ උදාහරණ අතුරුමුහුණත සමඟ කලාතුරකින් ගැළපේ, සහ වැරදි උපාංගයේ ගත් ග්‍රහණයක් ඉදිරියට නොයවන සේවාදායකයක් මෙන් හරියටම පෙනේ:

ip -4 route get 9.9.9.9

එම ප්‍රතිදානයේ dev ක්ෂේත්‍රය NAT රීතියට පසුව අවශ්‍ය වන නමයි, එබැවින් එය තබා ගන්න.

ඉදිරියට යැවීම යනු කර්නලයේ ස්විචයක් සහ ගිනි පවුරු ප්‍රතිපත්තියකි

කර්නලය මුලින්ම ඉදිරියට යැවීමට එකඟ විය යුතුය. වත්මන් අගය කියවා, පසුව ධාවනය වන කර්නලයට පමණක් ලිවීම වෙනුවට සැකසුම ස්ථිර කරන්න:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

ඉදිරියට යැවීම අඩක් පමණි. UFW ඇති සත්කාරකයක ඉදිරියට යැවීමේ ප්‍රතිපත්තිය /etc/default/ufw තුළ සකසන අතර නැවත පූරණය බලපැවැත්වීමට පෙර එය ACCEPT විය යුතුය. ඉදිරියට යැවීමේ මාර්ගයේ පෙරනිමි බැහැර කිරීම අත්වැල් ගැසීම සම්පූර්ණයෙන් සුවපත්ව තබා ටනලය හරහා පිටවීමට උත්සාහ කරන සෑම පැකට්ටුවක්ම නිහඬව ඉවතට දමයි, සහ එය ඔබ ආරම්භ කළ හරියටම ලක්ෂණයයි.

nftables සෘජුවම කළමනාකරණය කරන සත්කාරකවලට එම ප්‍රශ්නයම වෙනත් වාක්‍ය ව්‍යූහයකින් එනවා. සේවාදායක පරීක්ෂණය ධාවනය වන අතර ඉදිරියට යැවීමේ දාමයේ ගණකයන් බලන්න, මන්ද විමසන දාමය සහ ඉවතට දමන දාමය වින්‍යාස ගොනුවක එකම ලෙස පෙනේ.

NAT රීතියේ සැබෑ පිටවීම් අතුරුමුහුණත නම් කරන්න

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

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

සම්භාව්‍ය අසාර්ථකත්වය නම් මාර්ගෝපදේශයකින් පිටපත් කළ රීතියක් -o eth0 යැයි කියන අතර එම යන්ත්‍රයේ ඇඩැප්ටරය වෙනත් නමකින් හැඳින්වීමයි. රීතිය අනතුරු ඇඟවීමකින් තොරව ස්ථාපනය වේ, කිසිවකට නොගැළපේ, සහ සේවාදායකයාට තවමත් අන්තර්ජාලය නැත. තටාකය එම වැරැද්දේ අනෙක් අඩකි: සේවාදායකයා 10.44.0.0/24 බෙදා දෙන අතර රීතිය 10.8.0.0/24 ආවරණය කරයි නම්, කිසිවක් කිසි විටෙකත් නොගැළපේ.

රීතියේ පෙළ විශ්වාස කරනවාට වඩා ගණකයන් දෙස බලන්න. ලැයිස්තුව සෑම රීතියකටම පැකට් වාර්තා කරයි, සහ කිසි විටෙකත් නොගැළපෙන රීතිය කොතරම් නිවැරදිව පෙනුණත් ශුන්‍යයේම රැඳේ. එම සංඛ්‍යාවෙන් යමක් කියවීමට පෙර එයට විනාඩියක සැබෑ සේවාදායක රථවාහන දෙන්න:

iptables -t nat -L POSTROUTING -v -n

සැබෑ සේවාදායක පරීක්ෂණයකින් පසු ශුන්‍ය පැකට් ගණනක් යනු ගැළපීම වැරදිය, ටනලය කැඩී නැත. එක් වරක් ගැළපුණු පසු නැවත ඇරඹීමෙන් ගැලවීමට රීති කට්ටලය සුරකින්න; ඔබේ shell ඉතිහාසයේ පමණක් ජීවත් වන අලුත්වැඩියාව පළමු නැවත ඇරඹීමේදීම අතුරුදහන් වේ.

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

DNS යනු පළමුවැන්න පිටුපස දෙවැනි අසාර්ථකත්වයයි

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

සේවාදායකයාට කොහේ ඇසිය යුතුද යන්න දැනගැනීමට සේවාදායකයාගෙන් විසඳන්නෙකු තල්ලු කරන්න. සටහන් දෙකක් පළමුවැන්න ළඟා නොවේ නම් සේවාදායකයාට විකල්පයක් දෙන අතර, දෙකම ටනලය ඇත්තටම අවසර දෙන විසඳන්නන් විය යුතුය.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windows සේවාදායකයන් පසුව එසේ වුවත් ස්ථානීය විසඳන්නා වෙත ආපසු යා හැක, එය block-outside-dns පවතින්නේ වැළැක්වීමටය, ස්ථානීය ජාලයට පමණක් විසඳිය හැකි නම් අහිමි වීමේ මිලට. systemd-resolved භාවිත කරන Linux සේවාදායකයන් ස්ක්‍රිප්ටයක් ස්ථාපනය නොකළහොත් තල්ලු කළ විසඳන්නා නොසලකා හරිති, එබැවින් තල්ලු කිරීම නොසලකා හරිනු ලැබීය යැයි නිගමනය කිරීමට පෙර ටනල් උපාංගය සඳහා resolvectl status පරීක්ෂා කරන්න.

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

අදාළ ලිපි