ඔබේ LAN එක VPN සේවාදායකයක සේවාවකට ළඟා නොවන්නේ ඇයි

ඔබේ ටනලය ක්‍රියාත්මකයි, සේවාව සවන් දෙමින් සිටී, නමුත් කාර්යාලයේ LAN එකට තවමත් ආපසු කිසිවක් ලැබෙන්නේ නැත. කිසිවෙකු VPN එක කැඩුවේ නැත. LAN පැත්තෙන් බලන විට, ලැප්ටොප් එකේ ටනල් ලිපිනය LAN එකට එයට ළඟා වන ආකාරය කියා දෙන තෙක් නොපවතී, සහ පිළිතුර ඉල්ලීම පිට වූ එම මාර්ගයෙන්ම ආපසු එිය යුතුය. කිසිවෙකු ආපසු මාර්ගය දෙස බැලීමට පෙර මිනිසුන් සම්පූර්ණයෙන් සුවපත් ටනලයක් තෙවරක් නැවත ගොඩනඟන අයුරු මම දැක ඇත්තෙමි.

කැඩුණේ ටනලය නොවේ

දෙකෙළවරම පුද්ගලික පරාසවල වාඩි වී ඇත, එය සාමාන්‍ය අවස්ථාවයි, වැරදි වින්‍යාසයක් නොවේ. 10.8.0.6 වැනි ලිපිනයක් ටනලය තුළ සැබෑය, වෙනත් කොහේවත් නොපවතී, එබැවින් LAN එකට එහි යමක් යැවීමට හේතුවක් නැත. මාර්ගගත කිරීම ස්පර්ශ කිරීමට පෙර, සේවාව ටනලය තුළ කෙසේ හෝ ළඟා විය හැකිදැයි තහවුරු කරන්න: සේවාදායකයේ ss -ltn මගින් සවන් දෙන්නා 127.0.0.1, LAN අතුරුමුහුණත හෝ ටනල් ලිපිනයට බැඳී ඇත්දැයි පෙන්වයි. loopback වෙත පමණක් බැඳුණු ඩීමන් එකක් තමා හැර කිසිවෙකුට පිළිතුරු නොදේ, සහ කිසිදු මාර්ගයක්, DNAT එකක් හෝ තොටුපළ යළි පෙරළීමක් එය වෙනස් නොකරයි.

80 හෝ 443 තොටුපළේ ප්‍රොක්සියක් වෙනත් දෘශ්‍යතාවක් සහිත වෙනත් මෙවලමකි. එය ඉල්ලීම් ගෙන යයි, පැකට් නොවේ, එබැවින් අමු දත්ත සමුදාය සම්බන්ධතාවයකට එය වැරදි ස්තරයයි, සහ එය වෙත අත දැරීම නම් කිසිවෙකු යමක් මනින්නට පෙර මෙම ගැටලුව මෙවලම් තුනක් ගැඹුරට යාමේ මාර්ගයයි.

මාර්ගයේ හැඩය: තටාකය කොහේදැයි LAN එකට කියන්න

LAN ගේට්වේ එකේ ස්ථිතික මාර්ගයක් LAN එක සහ ටනල් තටාකය එකිනෙක මුණ නොගැසෙන විට වඩාත් පිරිසිදු පිළිතුරයි. තටාකය ටනලය අවසන් කරන යන්ත්‍රය දෙසට හරවන්න:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

සේවාදායකයා පිටුපස නොව එක් සේවාදායකයෙකු පිටුපස ඇති උපජාලයකට, සේවාදායකයාට පද්ධති මාර්ගයක් සහ එම සේවාදායකයාගේ ගොනුවේ iroute සටහනක් (client-config-dir යටතේ) දෙකම අවශ්‍යයි. iroute නොමැතිව, OpenVPN උපසර්ගය පවතින බව දන්නවා, එය අයිති කුමන සේවාදායකයාදැයි නොදනී: පැකට් පැමිණෙනවා, ඩීමන් එකට ඒවා ගැළපීමට කිසිවක් නැත.

මෙන්න නමක් දීමට වටිනා මිථ්‍යාව. මාර්ගයක් ලිපිනයක් ළඟා විය හැකි කරයි; එය විරුද්ධ පැත්ත පිළිතුරු දීමට කැමති නොකරයි. අඩවි-සිට-අඩවි සහකරුවන් ඊට තවත් ස්තරයක් එකතු කරයි, මන්ද දුරස්ථ ගේට්වේ එක එහි ප්‍රතිපත්තියේ ලැයිස්තුගත උපසර්ග තුළ ඇති මූලාශ්‍ර පමණක් පිළිගනී, සහ ගෘහ තටාකයකින් පැමිණෙන ලැප්ටොප් එකක් ඒවා තුළ නොවේ.

NAT හැඩය: ඇතුළට DNAT, සහ හැමෝම මඟ හරින SNAT පේළිය

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

තෙවන පේළිය නම් නැති වන පේළියයි. එය මඟ හැරියොත් සේවාදායකයා මුල් LAN ලිපිනය මූලාශ්‍රය ලෙස දකී, එහි පෙරනිමි මාර්ගයෙන් පිළිතුරු දෙයි, සහ එම පිළිතුර LAN දෙසට ආපසු යාම වෙනුවට ටනලයට යයි. සම්බන්ධතාවය ඉතිරි වේද නැද්ද යන්න එවිට ඔබ කිසිදා සැලසුම් නොකළ මාර්ගගත කිරීමක් මත රඳා පවතී. SNAT සමඟ සේවාදායකයා සේවාදායකයේ ටනල් ලිපිනය දකී, එබැවින් පිළිතුර ටනලය හරහා ආපසු පරිවර්තනය අවලංගු කළ හැකි එකම සත්කාරකය වෙත යයි.

පාරිභෝගික ස්ථිරාංග මෘදුකාංග එහිම දාම නාම භාවිතා කරන අතර එම පරිවර්තනය ඔබ වෙනුවෙන් සාදන්නේ නැත. Tomato හි, ඇතුළට එන රීතියක් WANPREROUTING වෙත වැටෙන අතර පසුව wanin වැනි පෙරහන් දාමයකට, සහ සම්පූර්ණ ලෙස පෙනෙන රීති කට්ටලයකට තවමත් අතින් ලියූ POSTROUTING පේළියක් අවශ්‍යයි. එය ස්ථිරාංග දෝෂයක් නොවේ; එය ඇතුළට එන ගමනාගමනයට පමණක් ලියූ රීති කට්ටලයකි.

නිවැරදි ලෙස පෙනෙන රීතියක් තවමත් පැකට් එක ඉවත් කරන්නේ ඇයි

මෙම අසාර්ථකතාවලින් බොහොමයක් ඔබ බලා සිටින රීතියේ නොවේ. මෙම අනුපිළිවෙලින් කරුණු හතරක් පරීක්ෂා කරන්න, සහ නොගැළපෙන පළමු එකේ නවතින්න:

• දාම අනුපිළිවෙල. iptables -I ඉහළින් ඇතුළු කරන අතර -A අවසානයේ එකතු කරයි, එබැවින් කලින් ඇති අවසර දෙන හෝ අවහිර කරන රීතිය පළමුව තීරණය කරයි.
• වැරදි දාමය. රවුටරයටම යොමු කළ ගමනාගමනය INPUT හරහා යයි, සහ යළි යවන ගමනාගමනය එය කිසිදා ස්පර්ශ නොකරයි. එක් සේවාවක් ප්‍රකාශයට පත් කිරීමට දෙකෙහිම රීති අවශ්‍ය විය හැක.
• දිශා ධජ. -i tun0 සේවාදායකයන්ගෙන් එන ගමනාගමනයට ගැළපෙන අතර -o tun0 ඔවුන් දෙසට යන ගමනාගමනයට ගැළපේ. වැරදි ධජයක් සහිත REJECT ඔබ අදහස් නොකළ දෙයක් අවහිර කරයි.
• මූලාශ්‍ර සීමාව. එක් සේවාදායක ලිපිනයක් පිළිගන්නා යළි පෙරළීමක් එම සේවාදායකයාගෙන් ක්‍රියා කරන අතර අනෙක් සෑම මූලාශ්‍රයක්ම වචනයක්වත් නොකියා ඉවත් කරයි.

ශුන්‍ය පැකට් ගණකයක් ඇති රීතියක් මාර්ගයේම නොමැත, සහ ගණක කියවීම වැරදි-දාම ගැටලුවක් වැරදි-රීති ගැටලුවකින් වෙන් කිරීමට ඇති වේගවත්ම ක්‍රමයයි.

දේශීය යළි පෙරළීම, LAN එකේ කිසිවක් වෙනස් කළ නොහැකි විට

SSH දේශීය යළි පෙරළීම මුළු ප්‍රශ්නයම මඟ හරියි. එයට LAN එකේ මාර්ගයක්, සේවාදායකයාගේ ගිනිපවුරේ සහයෝගය, සහ කොහේවත් ප්‍රකාශිත තොටුපළක් අවශ්‍ය නැත:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

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

තවත් රීතියක් එකතු කිරීමට පෙර දිශා දෙකම තහවුරු කරන්න

පරිවර්තනය සලකුණු ඉතිරි කරයි, ඒවා කියවීම අනුමාන කිරීමට වඩා හොඳය. VPN සත්කාරකයේ, conntrack -L පරිවර්තනය සිදු වූවාදැයි පෙන්වයි, iptables -t nat -L -n -v ගණක චලනය වූවාදැයි පෙන්වයි, සහ tcpdump -ni any port 3000 කුමන මූලාශ්‍ර ලිපිනයක් සැබවින්ම පැමිණියේදැයි පෙන්වයි. සේවාදායකයේ, ss -ltn සවන් දෙන්නා ටනලයට ළඟා විය හැකි ලිපිනයක සිටින බව තහවුරු කරයි.

පසුව ඔබ තබා ගන්නා හැඩය තෝරන්න. එක් ප්‍රකාශිත තොටුපළක්, මුළු තටාකයටම මාර්ගයක්, සහ එක් පරිපාලකයෙකුට යළි පෙරළීමක් යනු වෙනස් බැඳීම් තුනකි, සහ ඒවා මිශ්‍ර කිරීම නම් ක්‍රියා කරන සැකසුමක් මාස හයකට පසු කිසිවෙකුට විස්තර කළ නොහැකි එකක් බවට පත්වන මාර්ගයයි. කුමන ලිපිනය කොහෙන්ද ළඟා විය හැකිදැයි ලියා තබන්න, සහ මෙය ඩීබග් කරන ඊළඟ පුද්ගලයා ටනලය වෙනුවට පිළිතුරෙන් ආරම්භ කරයි.