උමගක් ඉහළ එයි, සේවාදායකයාට ගේට්වේ වෙත ping කළ හැක, නමුත් proxy මාර්ගයෙන් යන සෑම වෙබ් ඉල්ලීමක් මිය යයි. redsocks ක්‍රියාවලිය ක්‍රියාත්මක වන අතර එහි තොටුපළ සවන් දෙයි, එබැවින් ගේට්වේයේ සිටම සේවාව සුවපහසු ලෙස පෙනේ. අසාර්ථක වන්නේ බෙදාහැරීමේ පියවරයි: උමගෙන් හරවා යවන ලද පැකට්ටුව ඔබ ආරම්භ කළ socket මතට නොවැටේ. බැඳීමේ ලිපිනය සහ හරවා යැවීමේ ඉලක්කය එකඟ විය යුතු අතර, සාමාන්‍යයෙන් ඒවායින් එකක් පමණක් පරීක්ෂා කෙරේ.

හරවා යවන ලද පැකට්ටුව ඇත්තටම වැටෙන්නේ කොහේද

ගේට්වේයක තුළින් දෘශ්‍යමාන proxy එකක් PREROUTING හි nat වගුවේ REDIRECT භාවිතා කර එන සම්බන්ධතාවයේ ගමනාන්තය දේශීය තොටුපළකට නැවත ලියයි. නැවත ලියන ලද ගමනාන්තය පැකට්ටුව පැමිණි අතුරුමුහුණතින් දකින දේශීය ලිපිනයකි, වෙනත් තැනක ආරම්භ කළ ක්‍රියාවලියක loopback ලිපිනය නොවේ. 127.0.0.1 වෙත පමණක් බැඳුණු ශ්‍රෝතාවක් දැනටමත් සත්කාරකයේ දේශීයව තිබූ සම්බන්ධතා පිළිගනී, උමගේ ට්‍රැෆික් අසාර්ථක වන විට ක්‍රියා කරමින් පවතින අවස්ථාව හරියටම මෙයයි. සේවාදායකයාගේම loopback තුන්වන ලිපිනය වන අතර එය කිසිදා ගේට්වේයේ නීතියේ ඉලක්කය නොවේ.

එබැවින් ඉහළ මට්ටමේ සත්‍යතාපත්‍ර ස්පර්ශ කිරීමට පෙර කරුණු දෙකක් තහවුරු කරන්න: නීතිය නැවත ලියන්නේ කුමන දේශීය ලිපිනයටද, සහ proxy socket බැඳී ඇත්තේ කුමන ලිපිනයටද.

ශ්‍රෝතාව සහ හරවා යැවීමේ නීතිය එකට කියවන්න

socket වගුව සහ nat නීති එකම ගමනකින් මුද්‍රණය කරන්න, මන්ද කිසිවෙකුට හිමි නොවන තොටුපළකට යොමු වන නීතිය වැරදි ලිපිනයට යොමු වන නීතියට සමානව පෙනේ. sudo ss -ltnp | grep redsocks බැඳීමේ ලිපිනය සහ හිමිකරු ක්‍රියාවලිය පෙන්වයි. sudo iptables -t nat -S PREROUTING REDIRECT ඉලක්කය පෙන්වයි, sudo iptables -t nat -L PREROUTING -v -n එයට යමක් ගැළපුණේදැයි පෙන්වයි.

REDSOCKS නම් පරිශීලක දාමයකට පැනීමක් එම දාමය නොපවතී නම් සහ අපේක්ෂිත බැහැර කිරීම් සහ REDIRECT ක්‍රියාව රැගෙන නොයයි නම් කිසිවක් ඉටු නොකරයි. නාමය කාර්යය කරයි යැයි උපකල්පනය කිරීම වෙනුවට sudo iptables -t nat -S REDSOCKS සමඟ එය පනින දාමය කියවන්න.

පසුව අගයන් දෙක සසඳන්න. නීතිය 12345 තොටුපළේ ගේට්වේ ලිපිනයට හරවා යවන්නේ නම් සහ ශ්‍රෝතාව 127.0.0.1:12345 වාර්තා කරන්නේ නම්, එම නොගැළපීම තවත් රෝග විනිශ්චයකින් තොරව අසාර්ථකත්වය පැහැදිලි කරයි.

පටුවට බැඳ, පසුව එයට ළඟා විය හැකි දේ සීමා කරන්න

ඉහළ මට්ටමේ ආදර්ශ සැකසුම හොඳ හේතුවක් නිසා ශ්‍රෝතාව loopback මත තබයි: දෘශ්‍යමාන proxy එකක් එයට ළඟා විය හැකි ඕනෑම අයෙකු වෙනුවෙන් සම්බන්ධතා පිළිගනී. බැඳීම 0.0.0.0 වෙත වෙනස් කිරීම බෙදාහැරීම නිවැරදි කරන අතර එම අවස්ථාවේදීම සෑම අතුරුමුහුණතකම තොටුපළ විවෘත කරයි, එය ආරක්ෂක වෙනසක් මිස උදාසීන අලුත්වැඩියාවක් නොවේ. හරවා යැවීම ඉලක්ක කරන නිශ්චිත දේශීය ලිපිනයට බැඳීමට කැමති වන්න, සහ විශ්වාස නොකරන අතුරුමුහුණත් මත තොටුපළ වසා තබන්න. පුළුල් බැඳීමක් නොවැළැක්විය හැකි නම්, උමගේ මූලාශ්‍ර පරාසය සහ ගේට්වේයේම දේශීය ට්‍රැෆික් පමණක් අවසර දෙන සත්කාරක firewall නීතියක් එක් කරන්න.

පොදු අතුරුමුහුණතේ තොටුපළ විවෘත කිරීම හරවා යවන ලද VPN ට්‍රැෆික් සඳහා කිසිදා අවශ්‍ය නොවේ, මන්ද නැවත ලිවීමෙන් පසු සම්බන්ධතාවය දේශීයව අවසන් වේ. දේශීය හරවා යැවීමක් ක්‍රියා කිරීමට proxy එක අන්තර්ජාලයට නිරාවරණය නොකරන්න.

සේවාදායකයෙකුගෙන් නව සම්බන්ධතාවකින් එය ඔප්පු කරන්න

ගේට්වේයේ shell එකකින් නොව, සැබෑ VPN සේවාදායකයෙකුගෙන් නව TCP සම්බන්ධතාවක් සමඟ පරීක්ෂා කරන්න. සේවාදායකයා මත curl -sS -o /dev/null -w '%{http_code}\n' http://example.com හරවා යවන ලද මාර්ගය මුල සිට අග දක්වා ක්‍රියාත්මක කරයි.

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

අවසාන වශයෙන්, මෙම මාර්ගය ආවරණය නොකරන දේ මතක තබා ගන්න. සාමාන්‍ය redsocks TCP හරවා යැවීම UDP, QUIC හෝ DNS SOCKS ට්‍රැෆික් බවට පත් නොකරයි, සහ පෞද්ගලික ගමනාන්තවලට සාමාන්‍යයෙන් පැහැදිලි බැහැර කිරීම් අවශ්‍ය වේ. සාර්ථක දේශීය පරීක්ෂණයක් ඔප්පු කරන්නේ කිසිදා ගැටලුව නොවූ loopback මාර්ගය පමණි.

අදාළ ලිපි