LAN සේවාදායකයේ VPN සේවාලාභියා: පිළිතුරු වැරදි මාර්ගයෙන් යන්නේ ඇයි

රෝග ලක්ෂණ එක් ආකාරයක් අනුගමනය කරයි: සත්කාරකයක් ක්‍රියා කරයි, පසුව එය සේවාලාභියෙකු ලෙස VPN වෙත සම්බන්ධ වේ, දැන් LAN සේවාදායකයන් එයට ළඟා වන අතර එහි පිළිතුරු අතුරුදහන් වේ. සත්කාරකයේ ගන්නා ලද ග්‍රහණයක් පෙන්වන්නේ පිළිතුරු LAN අතුරුමුහුණත වෙනුවට උමඟ උපාංගය හරහා පිටවන බවයි. උමඟේ කිසිවක් කැඩී නැත, සහ නිවැරදි කිරීම මාර්ගයක් මිස නැවත සම්බන්ධ වීමක් නොවේ. පහත චතුර් පරීක්ෂණ පිළිවෙලින් කර පළමු අසමත් එකේ නතර වන්න.

පිළිතුර නව පැකට්ටුවකි, මාර්ගයේ ප්‍රතිවිරුද්ධ ගමනක් නොවේ

ඉල්ලීමක් ගිය මාර්ගයෙන්ම පිළිතුර ආපසු එනවා යන අදහස අත්හැරීම උපකාරී වේ. මාර්ගකරණය තීරණය වන්නේ එක් එක් පැකට්ටුවට, එක් එක් දිශාවට, යවන සත්කාරකයේ ය. උමඟ තුළ 10.64.0.23 වෙතින් පැමිණි ඉල්ලීමක් ආපසු මාර්ගයක් නිර්මාණය නොකරයි; සත්කාරකය පිළිතුරු දෙන විට එම පිළිතුර නව පැකට්ටුවක් ලෙස වගුව සමඟ ගැලපී ජයගන්නා මාර්ගයෙන් පිටවේ.

එහෙයින් LAN එකක් ද සේවා කරන යන්ත්‍රයක පූර්ණ උමඟ සේවාලාභියෙකු මෙතරම් ව්‍යාකූල අසාර්ථකත්වයක් ඇති කරයි. සේවාලාභියා පෙරනිමි මාර්ගයක් හෝ සමහර සේවාලාභීන් කැමති අර්ධ-පෙරනිමි මාර්ග දෙකක් ස්ථාපනය කරයි, දැන් LAN සේවාදායකයෙකුට යන පිළිතුර උමඟට ගැලපේ. එය සැපයුම්කරු වෙත යයි, ඔවුන්ට එය ඉදිරියට යැවීමට හේතුවක් නැත, සත්කාරකය ක්‍රියාත්මකව දේශීයව පිළිතුරු දෙන නමුත් LAN සේවාදායකය කාලාන්තයක් දකී. ග්‍රහණය මෙය පැහැදිලි කරයි, මාර්ගකරණ වගුව එය විස්තර කරයි.

ඉතිරිය කියවන විට උපජාල දෙකක් මතක තබා ගන්න. එකක් දුරස්ථ සේවාලාභීන් පැමිණෙන VPN ලිපින තටාකයයි, මෙම උදාහරණයේ 10.64.0.0/24. අනෙක ක්‍රියා කළ යුතු LAN එකයි, 172.16.24.0/24, එහි මාර්ගකරු 172.16.24.1 හි. දෝෂය වන්නේ ඒවා අතර ගමන් මාර්ගය පෙරනිමි මාර්ගයෙන් තීරණය වීමයි.

ග්‍රහණයෙන් සහ සෙවීමෙන් එය ඔප්පු කරන්න

කිසිවක් වෙනස් කිරීමට පෙර පිළිතුර කුමන උපාංගය භාවිතා කරන දැයි තහවුරු කරන්න. සෙවීමක් ග්‍රහණයකට වඩා වේගවත් වන අතර පැකට්ටුව ගොඩනැගෙන විට කර්නලය පිළිතුරු දෙන එම ප්‍රශ්නයටම පිළිතුරු දෙයි.

ip route get 10.64.0.23 from 172.16.24.10
tcpdump -ni any -c 6 icmp

පිළිතුර කොටස් දෙකකින් කියන්න. එය dev tun0 නම් කරන්නේ නම්, සත්කාරකය පිළිතුර කැප්සියුලනය කර සැපයුම්කරුට දෙනු ඇත, LAN සේවාදායකය එය කිසිදා නොදකිනු ඇත. එය dev eth0 නම් කරන නමුත් සේවාදායකය තවමත් කාලාන්තයක් ලබා ගන්නේ නම්, මාර්ගය දැනටමත් නිවැරදි වන අතර පැකට්ටුව පසුව ඉවත දමයි, එය වෙනත් ගැටලුවක් සහ වෙනත් නිවැරදි කිරීමක් වේ.

එම පියවරේම ග්‍රහණය ping විසින් විසඳිය නොහැකි සැකය තීරණය කරයි. LAN සේවාදායකයට ළඟා වන ප්‍රතිරාව පිළිතුරක් යම් මාර්ගයක් ක්‍රියා කරන බව ඔප්පු කරයි, එය ගෙන ගියේ කුමන අතුරුමුහුණත ද යන්න නොවේ, එබැවින් ග්‍රහණය සත්කාරකයේම ධාවනය කර රාමු පිටවන තැන බලන්න. එම උපජාලයේ මුද්‍රණ යන්ත්‍රය දිගටම පිළිතුරු දෙයි, එහි සෘජු මාර්ගය උමඟේ පෙරනිමියට වඩා නිශ්චිත නිසා. යොමු කළ තොටුපොළක් අනෙක් ඕනෑම ප්‍රවාහයක් මෙන්ම අසාර්ථක වේ, අතුරුමුහුණත තෝරන්නේ වගුව මිස සම්බන්ධය නොවේ.

උමඟ අභිබවා යන පටුම මාර්ගය ස්ථාපනය කරන්න

තීරණය වන්නේ උපසර්ග දිග මිස මිනුම නොවේ, එබැවින් LAN මාර්ගකරු හරහා සේවාලාභී තටාකයට යන මාර්ගය VPN සේවාලාභියා ස්ථාපනය කරන ඕනෑම පෙරනිමියක් අභිබවා යයි. මිනුම් සැත්කම් අවශ්‍ය නැත, පෙරනිමිය සේවාලාභියා තැබූ තැනම රැඳී සිටිය හැක.

ip route replace 10.64.0.0/24 via 172.16.24.1 dev eth0
ip route get 10.64.0.23 from 172.16.24.10

දෙවන add වෙනුවට replace භාවිතා කරන්න, නැවත සම්බන්ධ වන සේවාලාභියා දැනටමත් තම සටහන ස්ථාපනය කර ඇති අතර දෙවන add අවසර ගැටලුවක් ලෙස කියවෙන පවතින මාර්ග දෝෂයකින් අසාර්ථක වේ. Windows සත්කාරකයේ සමානය route add 10.64.0.0 mask 255.255.255.0 172.16.24.1 -p වේ, එහිදී -p නැවත ආරම්භ කිරීම් හරහා සටහන රඳවා ගනී, උමඟ නැවත ඉහළ එන විට සේවාලාභියාට වගුව නැවත ගොඩනැගිය හැකි නිසා. නවීන Windows සත්කාරකයේ සහාය දක්වන සමානය New-NetRoute -DestinationPrefix 10.64.0.0/24 -NextHop 172.16.24.1 -InterfaceAlias Ethernet -PolicyStore PersistentStore වන අතර පැරණි route විධානය පැරණි ආකාරය ලෙස රඳවා ඇත.

එක් විස්තරයක් තීරණය කරන්නේ මෙය නිවැරදිද නැතහොත් විශ්වාසනීය පමණක්ද යන්නයි: ඊළඟ පිම්ම සේවාලාභීන් වෙත ආපසු යන මාර්ගය ඇත්ත වශයෙන්ම හිමි මාර්ගකරු විය යුතුය. උමඟ හරහාම ළඟා වන ලිපිනයකට මාර්ගය යොමු කිරීම පිරිසිදු අසාර්ථකත්වයක් වෙනුවට කඩින් කඩ අලාභයක් ලෙස පෙනෙන ලූපයක් නිර්මාණය කරයි. රේඛාව තහවුරු කිරීමට පෙර ඊළඟ පිම්ම LAN උපජාලයේ ඇති බව තහවුරු කරන්න.

නැවත සම්බන්ධ වීමෙන් පසුවත් පිළිතුර රඳවා ගන්න

අතින් එක් කළ මාර්ගයක් හොඳම අවස්ථාවේ ඊළඟ නැවත සම්බන්ධ වීම දක්වා පවතී. සේවාලාභී තටාකය ගතික නම්, ඔබ මාර්ගකරණය කළ උපසර්ගය සේවාලාභීන්ට ලැබෙන උපසර්ගයම වන පරිදි එය සේවාදායක වින්‍යාසයේ සවි කරන්න; එසේ නොමැති නම් සටහන හිස් පරාසයකට යොමු වන අතර රෝග ලක්ෂණ සති කිහිපයකට පසු පැහැදිලි හේතුවක් නොමැතිව නැවත පැමිණේ. මාර්ගය සේවාලාභියාගේම up-පිටපතේ ලිවීම අනෙක් විශ්වාසදායක විකල්පයයි, එය සේවාලාභියා වගුව නැවත ලිවීමෙන් පසු ධාවනය වන නිසා.

තත්ත්වය සහිත ගිනිපවුරකට නිවැරදි මාර්ගයක් පවා පරාජය කළ හැක. ග්‍රහණය දැන් පෙන්වන්නේ පිළිතුර eth0 හරහා පිටවන බවත් සේවාදායකය තවමත් කාලාන්තයක් ලබන බවත් නම්, සත්කාරකය යැවීමට පෙර පැකට්ටුව ඉවත දමන්නේදැයි පරීක්ෂා කරන්න. දැඩි ප්‍රතිලෝම මාර්ග පෙරීම සහ net.ipv4.conf.all.rp_filter 1 ලෙස සැකසීම, පැමිණි අතුරුමුහුණත හරහා ආපසු මාර්ග නොකෙරෙන මූලයක් ඇති පැකට්ටු ඉවත දමයි, එය ඔබ දැන් නිර්මාණය කර පසුව නිවැරදි කළ අසමමිතික අවස්ථාවම වේ, conntrack තත්ත්වය යොමු කළ තොටුපොළවලට ද එම කතාවම කියයි.

අවසාන පරීක්ෂාව මිනිසුන් මඟ හරින එකයි: උමඟ පහළට ගොස් නැවත ඉහළ ආ පසු සෙවීම නැවත කරන්න. අගයන් හතරක් ඔබ ලියා තැබූ දේට ගැලපිය යුතුය: ගමනාන්තය, ඊළඟ පිම්ම, උපාංගය සහ තෝරාගත් මූලය. ඒවායින් එකක් හෝ ගමන් කළේ නම්, සේවාලාභියා වගුව නැවත ලියා ඇති අතර නිවැරදි කිරීම ඔහුගේ කොකු තුළ මිස shell ඉතිහාසයේ නොවේ.