VPN සහ වෙබ් සඳහා එකම පොදු සත්කාරකය: භූමිකා බෙදා ගන්නේ කෙසේද

එක් යන්ත්‍රයකට අවශ්‍යතා තුනම එකවර ඉටු කළ හැක: ටනල් අවසන් කිරීම, HTTPS වලට පිළිතුරු දීම සහ පෞද්ගලික LAN දෙකක් අතර යැවීම. එය සාධාරණ ද යන්න කඩදාසි මත තීරණය කළ හැකි කරුණු තුනක් මත රඳා පවතී: පොදු ලිපිනය කා සතුද, සෑම වරායක් සහ ප්‍රොටෝකෝල යුගලය කා සතුද, සහ කුමන ක්‍රියාවලියකට පැකට් යැවීමට අවසර ඇත්ද. මේවා නිවැරදි නම්, හවුල් සත්කාරකය විශේෂ කිසිවක් නොවේ. වැරදි නම්, පිරිසිදුව ආරම්භ වී කිසිදා පිළිතුරු නොදෙන සේවාවක සති අන්තයක් ගත කරනු ඇත.

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

වරායන්ට පෙර ලිපිනයේ හිමිකරු තෝරන්න

ටනල් අන්ත ලක්ෂ්‍යයක් සහ වෙබ් සේවාදායකයක් එකම කර්නලයක් බෙදා ගත හැක; එකවර එකම ලිපිනය, වරාය සහ ප්‍රොටෝකෝලය බෙදා ගැනීම අසාර්ථක වන දෙයයි. WireGuard සාමාන්‍යයෙන් UDP 51820 ගනී, OpenVPN UDP 1194 හෝ TCP 443 ගනී, වෙබ් සේවාදායකය TCP 443 ගනී. වේදනා දෙන යුගලය HTTPS අසල TCP 443 මත OpenVPN වේ, මන්ද දෙකම එකම සොකට් එක අවශ්‍ය වන අතර කර්නලය එය පළමුව බැඳුණු අයට දෙයි. ඉදිරියේ ඇති ඩිමල්ටිප්ලෙක්සරයක් පමණක්, උදාහරණයක් ලෙස sslh හෝ TLS දන්නා ප්‍රොක්සියක්, ඔවුන්ට එම වරාය බෙදා ගැනීමට ඉඩ දෙයි, සහ එය අසාර්ථක වීම ෆයර්වෝල් ගැටලුවක් ලෙසම පෙනෙන සංරචකයක් එකතු කරයි.

කිසිවක් වෙනස් කිරීමට පෙර හිමිකරුවන් දෙස බලන්න: ss -lntup සවන් දෙන සෑම සොකට් එකකම දේශීය ලිපිනය, වරාය සහ ක්‍රියාවලිය මුද්‍රණය කරයි. පෙන්වන පේළි දෙකක් 0.0.0.0:443 යනු දෙවන සේවාව කිසිදා බැඳී නැති බවයි, එහි init ස්ක්‍රිප්ටය කොතරම් සතුටින් තිබුණත්. පාලම ද හිමිකරු ගෙන යයි. විට eth0 සමඟ එකතු වේ br0, IP br0 වෙත යයි සහ eth0 නම් කරන සෑම ෆයර්වෝල් රීතියක්ම ගැලපීම නවත්වයි, එබැවින් සේවා පාලම මත බැඳ කර ip -br addr සමඟ තහවුරු කරන්න.

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

LAN දෙක අතර මාර්ග කරන්න හෝ එක පැත්තක් NAT කරන්න

එකිනෙකා නොදකින LAN දෙකකට එකින් එක පොදු සත්කාරකය අමතා, එය ටනල් අතර යවයි. එම මාර්ගකෘත නිර්මාණයට කරුණු තුනක් අවශ්‍යය: යැවීම සක්‍රිය, සෑම දුරස්ථ උපසර්ගයකට මාර්ගයක් සහ සංක්‍රාන්තියට ඉඩ දෙන යැවීමේ ප්‍රතිපත්තියක්. sysctl -w net.ipv4.ip_forward=1 පළමුවැන්න ආවරණය කරයි, ip route add 10.20.0.0/24 dev wg1 දෙවැන්න, සහ nftables රේඛාවක් nft add rule inet filter forward iifname "wg0" oifname "wg1" accept තුන්වැන්න.

මූල NAT එකතු කිරීම පහසුය, දෝෂ නිරාකරණය අමාරුය. මාස්කරණය සේවාලාභියාගේ ලිපිනය නැවත ලියයි, එබැවින් දුරස්ථ පැත්ත සැබෑ සත්කාරකය නොව හබ් එක දකියි, එහි ප්‍රවේශ නීති සහ ලොග් ආරෝපණයට නිෂ්ප්‍රයෝජනවත් වේ. දෙකම ඔබේ නම් මාර්ග කරන්න. එක් පැත්තක් ප්‍රතිලෝම මාර්ගයක් එකතු නොකරන තෙවන පාර්ශ්වයකට අයත් නම්, NAT යනු මේ සතියේ පිටවන විකල්පයයි. කෙසේ වෙතත් ලිපින සැලැස්ම ලියන්න, මන්ද අතිච්ඡාදනය වන /24 දෙකක් කිසිදු වින්‍යාසයකින් මාර්ග කළ නොහැක.

ලැප්ටොප් එකක් සඳහා අන්තර්ජාල පිටවීමක් ලෙස ක්‍රියා කිරීම එම පෙට්ටියම එන ටනල් අවසන් කිරීම වළක්වන්නේ නැත. වළක්වන්නේ අතිච්ඡාදනය වන ලිපින පමණි, එබැවින් ලිපින සැලැස්ම වැදගත් ලේඛනයයි.

භූමිකා දෙකක් නතර කර ඇති විට බෙදීම පරීක්ෂා කරන්න

ප්‍රයෝජනවත් පරීක්ෂණය අඩු කිරීමයි: භූමිකා දෙකක් නවතා තුන්වැන්න තවමත් පිළිතුරු දෙන බව තහවුරු කරන්න. ටනල් සේවාව වසා ඇති විට වෙබ් ඉල්ලීම සම්පූර්ණ විය යුතුය, වෙබ් සේවාදායකය නතර කර ඇති විට ටනල් අත්වැල් ගැසීම සම්පූර්ණ විය යුතුය. දෙකම සියල්ල ධාවනය වන විට පමණක් ක්‍රියා කරන්නේ නම්, ඔබට අහම්බෙන් යැපීමක් ඇත, උදාහරණයක් ලෙස හවුල් ෆයර්වෝල් වගුවක්, නැති වූ මාර්ගයක් හෝ වැරදි ලිපිනයට යොමු වන නමක්.

විධාන තුනක් එම පරීක්ෂණය මූර්ත කරයි. curl -sk --resolve example.test:443:203.0.113.10 https://example.test/ බාහිර DNS නොමැතිව දේශීය සවන්දෙන්නා පිළිතුරු දෙන බව ඔප්පු කරයි, wg show සේවාලාභියා මත අත්වැල් ගැසීම සම්පූර්ණ වූ බව ඔප්පු කරයි, සහ tcpdump -ni any port 51820 හබ් එකේ මාර්ග ගැටලුව යතුරු ගැටලුවෙන් වෙන් කරයි. ග්‍රහණයේ කිසිදා නොපෙනෙන අත්වැල් ගැසීම සත්කාරකයට පෙර මිය ගියේය: සැපයුම්කරුගේ ෆයර්වෝල්, වැරදි පොදු ලිපිනය හෝ මාර්ගයේ NAT රීතිය.

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

භූමිකා අඩු කරන අතර රීති කට්ටලය කියවිය හැකිව තබා ගන්න. nft list ruleset සැබවින්ම අවශ්‍ය සෑම දිශාවකටම එක් පිළිගැනීමේ රීතියක් පෙන්විය යුතුය, සියල්ල පිළිගන්නා යැවීමේ දාමය බෙදීමක් නොවේ, එය ක්‍රියාත්මක වන ආදර්ශනයකි.

IPv6 පමණක් ප්‍රවේශ මාර්ග සහ IPv4 සේවා

සමහර ප්‍රවේශ මාර්ග IPv6 ළඟා වීම පමණක් ලබා දෙයි, සේවා තවමත් IPv4 හරහා ප්‍රකාශයට පත් කළ යුතුය. ටනලයම තවමත් රථවාහන ගෙන යන පවුල හරහා ගමන් කරයි, ප්‍රකාශිත සේවාව ටනලය තුළ ඇති ලිපිනයක වාඩි වේ. මෙය සාමාන්‍ය උපකල්පනය පෙරළා දමා අධීක්ෂණය නිහඬව බිඳ දමයි: IPv4 මාර්ගය සඳහා ලියූ ෆයර්වෝල් රීතියක් හෝ ක්‍රියාකාරී කාල පරීක්ෂාවක් දැන් කිසිවක් රැගෙන නොයන අතුරුමුහුණතක් නිරීක්ෂණය කරයි.

සෑම පවුලක්ම වෙන වෙනම පරීක්ෂා කරන්න curl -4 සහ curl -6 සමඟ, මන්ද එක් සාර්ථක ඉල්ලීමක් ඔබ උත්සාහ නොකළ මාර්ගය ගැන කිසිවක් නොකියයි. වරාය හිමිකාරිත්වය පවුල් අතර වෙනස් නොවේ, නමුත් සවන්දෙන්නා වෙනස් වේ: ss -lntup IPv4 සහ IPv6 සොකට් වෙන වෙනම පේළි ලෙස ලැයිස්තුගත කරයි, සහ 0.0.0.0:443 ආවරණය නොකරයි [::]:443 ක්‍රියාවලිය dual-stack සොකට් ඉල්ලා නොමැති නම්.

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