UID නීති සමඟ Linux යෙදුමක් VPN වෙත සම්බන්ධ කරන ආකාරය

Linux හි එක් වැඩසටහනක් VPN වෙත බැඳීම ප්‍රධාන වශයෙන් මාර්ගගත කිරීමේ ගැටලුවකි, සහ firewall නීතිය තීරණය කරන්නේ මාර්ගය තෝරා ගැනීමෙන් පසු සිදුවන දේ පමණි. උමං සතුව පෙරනිමි මාර්ගය පැමිණීමට පෙර ඔබ OUTPUT තුළ වැඩසටහනේ UID ගැළපුවහොත්, නීතිය ඔබ ආරක්ෂා කිරීමට අදහස් කළ එම ගමන් ප්‍රවාහයම ඉවත් කරයි. එම නීතියම වැඩසටහනේ DNS ප්‍රශ්නවලට පිළිතුරු දෙන resolver ක්‍රියාවලිය ද නොදකී. අනුපිළිවෙල නිවැරදි කරන්න, එවිට වරප්‍රසාද නොමැති එක් ගිණුමක් විශ්වාසදායක බෙදුණු උමං තේරීම්කරුවෙකු බවට පත්වේ.

තීරණයට පෙර ගිණුමට මාර්ගයක් දෙන්න

හිමිකරු ගැළපීම එක් ප්‍රශ්නයකට පිළිතුරු දෙයි: මෙම UID ට අයත් ස්ථානීය සොකට් එකක් පැකැට්ටුව ගොඩනැගුවේද? එය අතුරුමුහුණතක් තෝරන්නේ නැත, සහ ප්‍රධාන වගුව දැනටමත් භෞතික NIC හරහා යවන ප්‍රවාහය ගෙනයා නොහැක. එබැවින් ගැළපෙන මාර්ගයක් නොමැති UID නීතිය වැඩසටහන හරවනවා වෙනුවට අවහිර කරයි.

ගිණුම පළමුව එහිම වගුව හරහා යවන්න, පසුව firewall ට ප්‍රතිඵලය තහවුරු කිරීමට ඉඩ දෙන්න. මෙය iproute2 uidrange තේරුම් ගන්නා සත්කාරකයක ක්‍රියා කරයි, එය ip rule help එක් පේළියක වාර්තා කරයි. වගුව 100 උමං හරහා පෙරනිමි මාර්ගයක් රඳවා ගනී, සහ නීතිය UID 1000 පමණක් එම වගුවට යවයි. අනෙක් සියල්ල ප්‍රධාන වගුවේම රැඳී භෞතික සබැඳිය භාවිතා කරයි.

ip rule add uidrange 1000-1000 table 100
ip route add default dev tun0 table 100

වෙනත් උමං අවශ්‍ය දෙවන ගිණුමට වගුව 101 සහ එහිම නීතිය ලැබේ, මන්ද පැතිකඩ දෙකකට එකම වගුවේ පෙරනිමි මාර්ගය එකට හිමි කර ගත නොහැක. NetworkManager පැතිකඩ පද්ධති-පුළුල් බැවින් මෙම කොටස අතින්ම රැඳේ, සහ නැවත ආරම්භයේදී නීති අතුරුදහන් වේ, යමක් ඒවා ප්‍රතිස්ථාපනය නොකළහොත්. උමං නිර්වචනය අසල ඇති ආරම්භක ස්ක්‍රිප්ටයේ වගු ලියන්න, එවිට නැවත සම්බන්ධ වීම ගිණුමක් වැරදි මාර්ගයේ තබන්නේ නැත.

loopback ව්‍යතිරේකය උමං මරා දමන්නේ ඇයි

නීතියේ පිටපත් කළ බොහෝ අනුවාද loopback හරහා පිට නොයන සෑම පැකැට්ටුවක්ම ඉවත් කරයි. උමං loopback නොවේ, එබැවින් එම ආකෘතිය උමං ප්‍රවාහය ද ඉවත් කරයි, සහ ප්‍රතිඵලය firewall දෝෂයක් ලෙස නොව මියගිය VPN එකක් ලෙස පෙනේ.

OUTPUT ක්‍රියාත්මක වන විට කර්නලය දැනටමත් පිටවන අතුරුමුහුණත තෝරාගෙන ඇත, එබැවින් -o පැකැට්ටු ශීර්ෂය සමඟ නොව මාර්ගයේ පිළිතුර සමඟ සසඳනු ලැබේ. හිමිකරු ගැළපීම OUTPUT සහ POSTROUTING තුළ පමණක් සලකනු ලැබේ, සහ යොමු කළ පැකැට්ටුවල එය කියවිය හැකි සොකට් එකක් නොමැත. මෙම සංයෝජනය අදහස් කරන්නේ ව්‍යතිරේකය loopback ප්‍රතික්ෂේප කිරීම වෙනුවට උමං අතුරුමුහුණත නම් කර එම ගැළපීම ප්‍රතික්ෂේප කළ යුතු බවයි.

loopback තවමත් DROP ට ඉහළින් එහිම ACCEPT ට සුදුසුය, මන්ද වැඩසටහනේ පළමු DNS පැකැට්ටුව lo හරහා ස්ථානීය stub වෙත යයි. නීති දෙක මෙම අනුපිළිවෙලට තබන්න, එවිට ගිණුම stub වෙත ළඟා වේ, පසුව උමං වෙත, සහ වෙනත් කිසිදු තැනකට නොවේ.

iptables -I OUTPUT 1 -o lo -m owner --uid-owner vpnapp -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner vpnapp ! -o tun0 -j DROP

IPv6 වෙනම නීති කට්ටලයකි, සහ v4 සඳහා පමණක් වූ යුගලය ip6tables නොසලකා හරියි. AAAA වාර්තාවලට මුල් තැන දෙන වැඩසටහනක් එවිට DROP වෙත කිසිදා නොපැමිණ භෞතික සබැඳිය හරහා පිටව යනු ඇත. නීති දෙකම ip6tables තුළ පිළිබිඹු කරන්න, නැතහොත් උමං v6 ලිපිනයක් නොගෙන යන විට සත්කාරකයේ IPv6 අක්‍රීය කරන්න. අතින් එකතු කළ නීති ද නැවත ආරම්භයේදී අතුරුදහන් වේ, එබැවින් ඒවා netfilter-persistent save සමඟ සුරකින්න හෝ එම තර්කනයම ආරම්භක ඒකකය පූරණය කරන nftables වගුවක් ලෙස නැවත ගොඩනඟන්න.

DNS පිළිතුරු වෙනත් ක්‍රියාවලියකින් පැමිණේ

වැඩසටහනේ 127.0.0.53 වෙත ප්‍රශ්නය loopback ACCEPT හරහා ගමන් කරයි, සහ එහිදීම UID ගැළපීම නතර වේ. stub resolver එහි සේවා ගිණුමෙන් ඉහළට යොමු කරයි, එබැවින් vpnapp වෙත බැඳුණු නීතිය දෙවන ප්‍රශ්නය කිසිදා නොදකී. resolver එක සබැඳිය සඳහා LAN සේවාදායකයක් තෝරා ගත්තොත්, පිළිතුරු භෞතික NIC හරහා ආපසු එන අතර වැඩසටහනේම පැකැට්ටු උමං තුළ රැඳේ. පෙනෙන ප්‍රතිඵලය වන්නේ කැඩුණු නම් සහිතව ක්‍රියා කරන උමං එකක්, නැතහොත් ඔබ තෝරා නොගත් සේවාදායකයක් පිළිතුරු දෙන නම් ය.

නම් විභේදනය යෙදුමේ නොව උමං සබැඳියේ නිවැරදි කරන්න. උමං පැතිකඩට DNS සේවාදායකයක් සහ මාර්ගගත කිරීමේ වසමක් දෙන්න, පසුව resolvectl query සහ resolvectl status tun0 සමඟ වැදගත් නම් සඳහා resolver එය භාවිතා කරන බව තහවුරු කරන්න. ජාල නාම අවකාශය තුළ ගැටලුව අතුරුදහන් වේ, මන්ද අවකාශයේ resolver දන්නේ උමං පමණි.

ගිණුමෙන්ම නීතිය පරීක්ෂා කරන්න

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

ip route get 1.1.1.1 uid 1000
sudo -u vpnapp curl -s https://ifconfig.co

ගණක දරන්නන් පෙන්වන්නේ නීතිය කිසිදා ක්‍රියාත්මක වූයේද යන්නයි. iptables -vnL OUTPUT ධාවනය කරන්න, සෑම නීතියක් අසල පැකැට්ටු ගණන කියවන්න, සහ සැබෑ ප්‍රවාහයෙන් පසු DROP අසල ශුන්‍යය ගැළපීමේ වැරැද්දක් ලෙස සලකන්න.

යොමු කළ ප්‍රවාහය මෙම සැලසුමෙන් පිටතයි. පාලම පිටුපස ඇති බහාලුමකට හෝ VM එකකට vpnapp ට හිමි ස්ථානීය සොකට් එකක් නොමැත, එබැවින් හිමිකරු ගැළපීම කිසිදා ක්‍රියාත්මක නොවන අතර එම පැකැට්ටු FORWARD ප්‍රතිපත්තිය අනුගමනය කරයි. එම භාරය ආවරණය කළ යුතු නම්, එය වෙනම පරීක්ෂා කර පාලමට හෝ බහාලුම් ලිපිනයට බැඳුණු ප්‍රතිපත්තියක් ලියන්න. වගුව, අතුරුමුහුණත ව්‍යතිරේකය, resolver සහ v6 නීති සියල්ලම එකම දිශාවට යොමු වන විට සැලසුම රැඳේ; ඉන් එකක් හෝ ඉවත් කළහොත් ගිණුම ගලා යයි නැතහොත් සම්බන්ධතාව අහිමි වේ.