දුරස්ථ පරිශීලකයින්ට VPN හබය හරහා දෙවන අඩවියට ළඟා විය නොහැක

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

ගමන් කිරීමට සෙවීම් තුනක් අවශ්‍යයි, ටනලයක් නොවේ

සෑම උපාංගයක්ම තමන්ගේම දිගම උපසර්ග ගැලපීම සිදු කර එය අමතක කරයි. ලැප්ටොපය 10.20.0.50 තම ස්ථානීය යොමුකරු වෙත නොව ටනලය තුළට යැවිය යුතුය. හබය දුරස්ථ ප්‍රවේශ අතුරුමුහුණතේ පැමිණි පැකට්ටුවක් ගෙන එය අඩවි-සිට-අඩවි අතුරුමුහුණතට දිය යුතුය. මූලස්ථානය පරිශීලකයාගේ ලිපිනයට පිළිතුරක් ටනලය හරහා ආපසු යැවිය යුතුය. මේ තුනෙන් එකක් අසාර්ථක වුවත් බ්‍රවුසරයේ එකම ලෙස පෙනේ: නිශ්ශබ්දතාව.

ඒ නිසා එක් එක් ටනලය වෙන් වෙන්ව පරීක්ෂා කිරීම ඉතා අල්පයක් ඔප්පු කරයි. හබයේ LAN ලිපිනයට පිංග් කිරීම පළමු තීරණය අභ්‍යාස කරයි, මූලස්ථානයේ සිට හබයට පිංග් කිරීම තෙවැන්න අභ්‍යාස කරයි. අසාර්ථක වන පැකට්ටුවේ මූලාශ්‍රය පරිශීලක සමූහය වන අතර ගමනාන්තය දෙවන අඩවියයි, එබැවින් පළමුව එම උපසර්ග ලියා ගන්න. මෙහි සමූහය 10.80.0.0/24, හබයේ LAN 10.10.0.0/24, සහ මූලස්ථානය 10.20.0.0/24 වේ.

දුර උපසර්ගය දුරස්ථ සේවාලාභියා වෙත තල්ලු කරන්න

එක් OpenVPN දුරස්ථ ප්‍රවේශ සේවාදායකයක සේවාලාභියා සම්බන්ධ වන විට මාර්ග ඉගෙන ගනී. push නොමැතිව, බෙදුණු ටනල සේවාලාභියා 10.20.0.50 තමන්ගේම ගේට්වේ වෙත යවයි, සහ පැකට්ටුව කිසිවිටෙක ටනලයට ඇතුළු නොවේ.

push "route 10.20.0.0 255.255.255.0"

තල්ලු කළ මාර්ගය සේවාලාභියා සම්බන්ධ වන විට බලාත්මක වේ, එබැවින් මාර්ගගතව රැඳී සිටින පරිශීලකයා නැවත සම්බන්ධ වන තෙක් කිසිවක් නොදකී. සේවාලාභියා මත පරීක්ෂා කරන්න: Linux හි ip route get 10.20.0.50, Windows හි route print. ප්‍රතිදානය ටනල අතුරුමුහුණත නම් කළ යුතුය.

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

හබයට සැබෑ පිටවීමේ මාර්ගයක් දෙන්න

හබයට මූලස්ථාන උපසර්ගය සඳහා තමන්ගේම ඊළඟ හොප් එක අවශ්‍යයි. යොමු කළ ටනලයක එය අඩවි-සිට-අඩවි අතුරුමුහුණත හරහා යන සාමාන්‍ය මාර්ගයක් වන අතර, එක් විධානයක් තෝරාගත් මාර්ගය සහ තෝරාගත් මූලාශ්‍රය දෙකම පෙන්වයි:

ip route get 10.20.0.50 from 10.80.0.25
sudo ip route add 10.20.0.0/24 via 172.30.0.2 dev s2s0

අඩවි-සිට-අඩවි කොටසම OpenVPN නම්, මාර්ගය එම වින්‍යාසයේම සහකරුගේ ටනල ලිපිනය ගේට්වේ ලෙස තබා ජීවත් විය හැක: route 10.20.0.0 255.255.255.0 172.30.0.2. ගේට්වේ අත්‍යවශ්‍යයි. එය අත්හැරියොත් ඊළඟ හොප් එක ක්‍රියාත්මක කිරීමේ පෙරනිමියට වැටේ, එය තනි දුරස්ථ සේවාලාභියෙකු සහ බහු සහකරු හබයක් අතර වෙනස් වේ.

ප්‍රතිපත්ති පාදක IPsec වෙනස් ය: හබයේ කර්නලය පැකට්ටුව තම සාමාන්‍ය LAN ගේට්වේ වෙත යවයි, ප්‍රතිපත්තිය පිටවීමේදී එය අල්ලා ගනී, එබැවින් ටනල මාර්ගය එක්කෝ කිසිවක් නොකරයි, එක්කෝ ප්‍රතිපත්තිය මගහැර රථවාහන යවයි. ඉහත විධානයේ මූලාශ්‍රය දෙස බලන්න, මන්ද සමූහයේ ලිපිනය වෙනුවට 10.10.0.1 යන්නෙන් අදහස් වන්නේ දුර පැත්ත ප්‍රතික්ෂේප කරන ලිපිනයක් කර්නලය තෝරාගෙන ඇති බවයි. iroute ද පිළිතුර නොවේ; එය සේවාදායකයට කියන්නේ කුමන සේවාලාභියා තම ටනලය පිටුපස උපජාලයක් හිමිකර ගනීද යන්නයි, තෙවන අඩවිය සඳහා රථවාහන කොහේ යවන්නද යන්න නොවේ.

දුර පැත්ත පරිශීලක සමූහය දක්වා දිගු කරන්න

මූලස්ථානය දැනටමත් හබයේ LAN, 10.10.0.0/24 ආවරණය කරයි. පරිශීලක සමූහය දෙවන උපසර්ගය වන අතර එය තේරීම්කරුවන් තුළද තිබිය යුතුය, එසේ නොමැති නම් 10.80.0.25 වෙත යවන පිළිතුරක් කිසිදු ප්‍රතිපත්තියක් ආවරණය නොකරයි. සෑම සහකරුවෙක්ම තම පැත්තෙන් එකම උපසර්ග කට්ටල යුගලය නම් කරයි:

# strongSwan swanctl.conf, on the hub
local_ts  = 10.10.0.0/24, 10.80.0.0/24
remote_ts = 10.20.0.0/24

# on the headquarters peer
local_ts  = 10.20.0.0/24
remote_ts = 10.10.0.0/24, 10.80.0.0/24

එක් උපාංගයක local_ts යනු අනෙකේ remote_ts ය. හබයේ කොටස මූලස්ථානයට පිටපත් කරන්න, යුගලය පෙරළෙයි, එබැවින් දරු SA කිසිවිටෙක ඉහළ නොඑයි.

පැරණි ipsec.conf වාක්‍ය වින්‍යාසය කොමාවෙන් වෙන් කළ leftsubnet භාවිත කරයි. ක්‍රියාත්මක ආරක්ෂක සංගමය සාකච්ඡා කළ තේරීම්කරුවන් රඳවා ගනී, එබැවින් සංස්කරණයෙන් පසු ටනලය නැවත ස්ථාපිත කරන්න. 10:00 ට වෙනස් කළ තේරීම්කරුවෙක් 09:40 ට ඉහළ ආ SA එකකට එරෙහිව පරීක්ෂා කළත් අසාර්ථක වේ, එහෙත් වින්‍යාස ගොනුව මුළු කාලයම නිවැරදි ලෙස පෙනේ.

පසුව අවසාන හොප් එක පරීක්ෂා කරන්න. දුර කෙළවරේ ip route get 10.80.0.25 ටනලය තුළට යොමු විය යුතුය. සේවාව LAN යොමුකරුව තම පෙරනිමි ගේට්වේ ලෙස භාවිත කරන්නේ නම්, එම යොමුකරුවටද ආපසු මාර්ගය අවශ්‍යයි, එසේ නොමැති නම් පිළිතුර එහිම මිය යයි. එම කොටසේ tcpdump -ni eth1 host 10.80.0.25 ධාවනය කිරීම පිළිතුර කෙළවරින් පිටව ගියේද යන්න පෙන්වයි.

හබයේ ප්‍රවාහයට අවසර දෙන්න

යැවීම සක්‍රීය විය යුතු අතර මාර්ගයට අවසර තිබිය යුතුය. අතුරුමුහුණත් අතර සියල්ල පිළිගැනීම වෙනුවට නියම උපසර්ග දෙකට සීමා කරන්න.

sysctl -w net.ipv4.ip_forward=1
iptables -I FORWARD -i tun0 -o s2s0 -s 10.80.0.0/24 -d 10.20.0.0/24 -j ACCEPT
iptables -I FORWARD -i s2s0 -o tun0 -s 10.20.0.0/24 -d 10.80.0.0/24 -j ACCEPT

ප්‍රතිලෝම මාර්ග පෙරහන ඊට යාබද නිශ්ශබ්ද අසාර්ථකත්වයයි: කොටස් දෙක වෙනස් අතුරුමුහුණත් මත නම්, rp_filter=1 පිළිතුර ඉවත දැමිය හැකි අතර පිළිගැනීමේ නියමයේ ගණකය කිසිසේත් නොසැලේ. උත්සාහයකට පෙර සහ පසු iptables -vnL FORWARD සසඳන්න. කිසිවිටෙක නොවැඩෙන නියමයකට ළඟා නොවේ, එබැවින් එය නැවත ලිවීම වෙනුවට එක් ස්ථරයක් පහළ බලන්න.

එක් කණ්ඩායමකට පමණක් ගමන් අවශ්‍ය නම්, ගෝලීය push පුළුල් කිරීම වෙනුවට client-config-dir යටතේ සේවාලාභියාට වෙන් වූ ගොනුවක මාර්ගය තබන්න. හබයේ Source NAT ද දුර පැත්තේ ආපසු මාර්ගයේ අවශ්‍යතාව ඉවත් කරයි, නමුත් එය පරිශීලකයාගේ ලිපිනය සඟවයි, එබැවින් දුර අඩවියේ ලොග සහ ලිපින පාදක නියම පරිශීලකයින් වෙන් කිරීම නවත්වයි.

සේවාලාභියාගෙන් පරීක්ෂා කර, පසුව ප්‍රතිලෝම අනුපිළිවෙලින් ආපසු හරවන්න

ICMP පමණක් නොව TCP වරායක් පරීක්ෂා කරන්න, මන්ද සේවාව අවහිරව තිබියදී පිංග් ගමන් කළ හැක. සේවාලාභියාගෙන් nc -vz 10.20.0.50 445 සහ traceroute -n 10.20.0.50 දෙවන හොප් එක හබයේ ටනල ලිපිනයද යන්න පෙන්වයි. හබයේ, tcpdump -ni tun0 host 10.20.0.50 සහ අඩවි-සිට-අඩවි අතුරුමුහුණතේ එම පෙරහනම: දෙකෙහිම ඉල්ලීමක් නමුත් කිසිවකට පිළිතුරක් නැත්නම් ගැටලුව දුර පැත්තට මාරු වේ.

පසුව අවහිරව තිබිය යුතු දෙයක් පරීක්ෂා කරන්න. සමූහය කිසිවිටෙක ළඟා නොවිය යුතු සත්කාරකයක්ද පිළිතුරු දෙන්නේ නම්, ඔබ ගමන් කිරීමට වඩා විවෘත කර ඇති අතර නියම පටු කළ යුතුය. සියල්ල සෑම ශාඛාවකටම යවන හබයක් පළමු පරීක්ෂණය සමත් වී දෙවැන්නෙන් අසාර්ථක වේ.

ආපසු හැරවීමේ ලැයිස්තුවක් තබා ගන්න, මන්ද වස්තු හතරක් වෙනස් වූ අතර තුනක් අමතක කිරීම පහසුය: තල්ලු කළ මාර්ගය, හබයේ මාර්ගය, තේරීම්කරුවන් සහ ෆයර්වෝල් නියම. ඒවා ප්‍රතිලෝම අනුපිළිවෙලින් අවලංගු කරන්න, SA නැවත ස්ථාපිත කරන්න, සහ එක් පරිශීලකයෙකුට නැවත සම්බන්ධ වීමට ඉඩ දෙන්න. අර්ධ ආපසු හැරවීමක් තවදුරටත් නොගැලපෙන ටනලයකට යොමු වන මාර්ගයක් ඉතිරි කරයි, එය මුල් නිශ්ශබ්දතාවට වඩා කියවීම අපහසුය. OpenVPN 2.6 අත්පොත ඔබේ සංස්කරණය සඳහා push, route සහ iroute ලේඛනගත කරයි.