එකම Pi එකක hostapd සහ OpenVPN: පෙරනිමි මාර්ගය කාගේද?
hostapd සහ OpenVPN සේවාලාභියෙකුට එකම Pi එකක් බෙදාගත හැක්කේ පාලම තමන්ගේ පෙරනිමි මාර්ගය රඳවා ගන්නා විටත්, උමග තම සේවාදායකයට මාර්ගය රඳවා ගන්නා විටත්ය. විධාන සහ ආපසු හැරවීම.
දුරකථන ප්රවේශ ලක්ෂ්යයට සම්බන්ධ වී ලිපිනයක් ලබා ගන්නා අතර, උමග ඉහළ යන විට කිසිවකට ළඟා නොවේ. එම තත්ත්වයේදී hostapd සාමාන්යයෙන් සුවපත් වන අතර OpenVPN ද එසේමය; බිඳෙන්නේ පෙරනිමි මාර්ගයයි, එය කිසිදා පාලමේ නොතිබුණි නම් හෝ VPN සේවාදායකයටම මාර්ගයක් නොතබා උමග එය ප්රතිස්ථාපනය කළේ නම්ය. මෙම මාර්ගෝපදේශය එම මාර්ගය නිවැරදි තැනට ආපසු ගෙන එන අතර ප්රතිඵලය Pi එකෙන් නොව සේවාලාභියෙකුගෙන් ඔප්පු කරයි. සෑම පියවරක්ම ආපසු හැරවිය හැකි අතර, උමග තුළ ඔබට අවශ්ය කුමන ගමන් කිරීමද දැනගන්නා තෙක් මෙහි කිසිවක් උමගේ වින්යාසය වෙනස් නොකරයි.
යමක් සංස්කරණය කිරීමට පෙර අතුරුමුහුණත් ලැයිස්තුගත කරන්න
හුරු පුරුදු සැලැස්ම රැහැන් රහිත ගුවන්විදුලිය සහ රැහැන් සහිත වරාය br0 තුළ තබයි, පාලමට එරෙහිව hostapd ආරම්භ කරයි, dnsmasq වෙතින් බදු බෙදාහරියි, අතර OpenVPN සේවාලාභියා tun0 සාදයි. එවිට වෙන් වෙන් අවශ්යතා තුනක් එකක් ලෙස පෙනේ: ප්රවේශ ලක්ෂ්ය සේවාලාභීන්ට ඔවුන්ගේ ද්වාරය ලෙස Pi අවශ්යයි, Pi ට තම සේවාදායකයට ළඟා වීමට අන්තර්ජාලයට මාර්ගයක් අවශ්යයි, පාලමට එම සේවාලාභීන්ට භාවිත කළ හැකි ද්වාර ලිපිනයක් අවශ්යයි.
වෙනස් කිරීමට පෙර වත්මන් තත්ත්වය කියවන්න, මන්ද මෙම විධාන හතර අතුරුමුහුණත් ගැටලුවක් මාර්ග ගැටලුවකින් වෙන් කරයි.
ip -br addr
ip route show
ip link show master br0
bridge link show
br0 ට ලිපිනයක් ඇතත් පෙරනිමි මාර්ගයක් නැති නම්, සේවාලාභීහු Pi දක්වා ළඟා වෙති, ඉන් ඔබ්බට කිසිවකට නොවේ. උමග පහළ ඇති විට පෙරනිමි මාර්ගය tun0 දෙසට යොමු වේ නම්, Pi ට ක්රියාකාරී මාර්ගයක්ම නැත, සේවාලාභියාගේ රෝග ලක්ෂණය ද හරියටම එසේම පෙනේ. අවස්ථා දෙකම දුරකථනයකින් සමානව පෙනේ, එබැවින් මාර්ග වගුව කෙලින්ම කියවිය යුතුය.
පාලමට එයට අයත් පෙරනිමි මාර්ගයක් දෙන්න
Raspberry Pi OS බොහෝ විට පාලම පෙරනිමි මාර්ගයකින් තොරව තබයි, අතුරුමුහුණත් ගොනුව ලියූ පසු පාලම පැන නැගුණු විට. කොටස /etc/dhcpcd.conf ට අයත් වන අතර එය Pi නොව ඉහළ රවුටරය නම් කළ යුතුය.
interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1
එම උදාහරණයේ 192.168.50.1 දැනට ඇති රවුටරය වන අතර 192.168.50.2 එම උපජාලයේ Pi හි පාලම් ලිපිනයයි, එබැවින් සංඛ්යා පිටපත් කරනවා වෙනුවට ඔබේම සැලැස්ම යොදන්න. පාලම් සාමාජිකයන් ද රවුටර ඉල්ලා නොගත යුතුය, එසේ නොවුණහොත් Pi ට තරඟකාරී පෙරනිමි මාර්ග ඉතිරි වේ, ඒවායේ ජයග්රාහකයා මෙට්රික් සහ කාලය මත රඳා පවතී, අභිප්රාය මත නොවේ.
systemctl restart dhcpcd පසු ip route show default br0 එක් වරක් පෙන්විය යුතු අතර රැහැන් සහිත වරායෙන් අනුපිටපතක් නොතිබිය යුතුය. වගුව නොව සෙවීම තහවුරු කරන්න, මන්ද පැරණි සටහනක් ජයග්රාහී සටහනක් අසල විය හැකිය: ip -4 route get 203.0.113.10 br0 නම් කළ යුතුය. එම ලිපිනය TEST-NET-3 ලේඛන පරාසයෙන් එන බැවින්, මෙය කියවන අතරතුර එය සැබෑ සේවාදායකයක් සමඟ ගැටීමට නොහැකිය.
උමග තම සේවාදායකයට යන මාර්ගය පැහැර ගැනීම වළක්වන්න
redirect-gateway පිළිගන්නා OpenVPN සේවාලාභියා පෙරනිමි මාර්ගය භාරගෙන එය උමග තුළට යොමු කරයි. සෑම ප්රවේශ ලක්ෂ්ය සේවාලාභියෙකුම VPN භාවිත කළ යුතු විට එය නිවැරදිය, සමහර ගමනාන්ත පමණක් කළ යුතු විට වැරදිය. කෙසේ වෙතත්, Pi හි සේවාදායකය සමඟ ඇති තම සම්බන්ධතාවය එය තවම ගොඩනගන උමග තුළින් ගමන් නොකළ යුතුය. OpenVPN පෙරනිමිය නැවත යොමු කරන විට මුල් ද්වාරය හරහා දුරස්ථයට සත්කාරක මාර්ගයක් එකතු කරයි, එයම තමයි ප්රවාහනය ජීවමානව තබන හැසිරීම; එම මාර්ගය නොමැති නම්, උමග ස්ථාපිත වූ වහාම කඩා වැටේ.
සම්බන්ධ වීමට පෙර සහ පසු එම ප්රවාහන මාර්ගයේ ඉක්මන් සංසන්දනය එම තත්පර දහයට වටී. ip -4 route get 203.0.113.10 දෙපැත්තේම යටි උපාංගය නම් කළ යුතුය, වෙනස් වන්නේ මෙට්රික් පමණි. උමග ඉහළ ගිය පසු එය tun0 නම් කරන්නේ නම්, සත්කාරක මාර්ගය කිසිදා ස්ථාපනය නොවීය, ඊළඟ නැවත සම්බන්ධ වීම අසාර්ථක වේ.
උමග හරහා යා යුත්තේ තෝරාගත් පෙරුක්ෂ පමණක් නම්, route-nopull භාවිත කර අවශ්ය මාර්ග අතින් එකතු කරන්න, නැතහොත් සේවාදායකයෙන් පටු කට්ටලයක් තල්ලු කරන්න. එම සැලැස්මේ පාලම පෙරනිමි මාර්ගය තබා ගනී, DNS ඊළඟ තීරණය වේ: dnsmasq නිවාස විසඳුම්කරුවෙකුට යොමු කිරීම අර්ථවත් වන්නේ එහි සැබවින්ම ජීවත් වන නම් සඳහා පමණි.
යොමු කිරීම සහ NAT පිළිබඳ තීරණය කරන්න
සම්පූර්ණ උමගකට Pi මත සක්රීය යොමු කිරීමක් සහ ප්රවේශ ලක්ෂ්ය උපජාලය මාර්ග කිරීමට සූදානම් අනෙක් පස ද්වාරයක් අවශ්යයි. අන් සියල්ලට පෙර යොමු කිරීම පරීක්ෂා කරන්න, මන්ද බිංදුවක් සෑම මාර්ග වෙනසක්ම අප්රස්තුත කරයි.
sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE
NAT රීතිය යනු සේවාදායකයා ප්රවේශ ලක්ෂ්ය පෙරුක්ෂය පිළිනොගන්නා විට ක්රියා කරන කෙටි මාර්ගයයි, එහි මිල වන්නේ අනෙක් පස සටහන්වල සෑම සේවාලාභියෙකුම Pi හි උමග් ලිපිනය ලෙස පෙනීමයි. NAT නොමැතිව පෙරුක්ෂය මාර්ග කිරීම ලිපින දෘශ්යව තබා ගනී සහ ගෘහ පැත්තේ 192.168.50.0/24 සඳහා ආපසු මාර්ගයක් මත රඳා පවතී.
firewall රීති අසල තේරීම ලියන්න, මන්ද සැලැස්මේ නොපෙනෙන NAT රීතියක් මාස හයකට පසු පැහැදිලි කළ නොහැකි වේ. IPv6 එම තීරණයේම තබන්න; කැඩුණු IPv6 මාර්ගයක් අසල ක්රියාකාරී IPv4 මාර්ගයක් තවමත් බ්රව්සරයේ අඩක් කැඩුණු ලෙස කියවේ.
සේවාලාභියෙකුගෙන් තහවුරු කර, පසුව පිරිසිදුව ආපසු හරවන්න
ප්රවේශ ලක්ෂ්යයේ දුරකථනයකින් හෝ ලැප්ටොප් එකකින් මෙම අනුපිළිවෙලින් පරීක්ෂා කරන්න: dnsmasq වෙතින් බද්දක්, පාලම් ලිපිනයට ping, පසුව උමගේ අනෙක් පස ගමනාන්තයක්. සෑම පියවරක්ම එක් ස්ථරයක් හුදකලා කරයි, එකම නිෂ්ප්රයෝජන අසාර්ථකත්වයක් නිපදවනවා වෙනුවට.
ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10
පසුව Pi ට තවමත් තම නික්මීමේ මාර්ගය ඇති බව තහවුරු කරන්න: ip route get 203.0.113.10 යටි උපාංගය නම් කළ යුතු අතර, සේවාදායකයා ICMP අනුමත කරන්නේ නම් ping -c 3 -I br0 203.0.113.10 පිළිතුරු දිය යුතුය. මුල් සේවාලාභී පියවර දෙක සමත් වී තුන්වැන්න අසාර්ථක වුවහොත්, දෝෂය යොමු කිරීමේ හෝ NAT හි ඇත. දෙවැනි පියවර අසාර්ථක වුවහොත්, පාලම හෝ DHCP තවම අසම්පූර්ණය.
ආපසු හැරවීම යනු එක් ගොනු සංස්කරණයක් සහ විධාන දෙකකි: කොටස ඉවත් කරන්න, dhcpcd නැවත අරඹන්න, සහ පෙරනිමි මාර්ගය පැහැදිලිව ip route replace default via 192.168.50.1 dev br0 සමඟ ප්රතිස්ථාපනය කරන්න. නඩත්තු කවුළුව වැසෙන්නට පෙර මෙය කරන්න, පසුව නොවේ, මන්ද පෙරනිමි මාර්ගය අහිමි වූ Pi එය අලුත්වැඩියා කිරීමට ඔබ භාවිත කරන ජාලයෙන් ළඟා කළ නොහැක.