කාර්‍යාලය සහ VPN සඳහා එකම URL? අනුමත ලැයිස්තුවේ මිථ්‍යාව අසාර්ථක වන්නේ ඇයි
VPN සම්බන්ධතාවයක් අනුමත අඩවියක් දකින ලිපිනය වෙනස් නොකරයි. URL එකක් එකතු කිරීමට පෙර සැබෑ පිටවීම, විශ්වාසනීය ප්‍රොක්සි පිම්ම සහ IPv6 මාර්ගය පරීක්ෂා කරන්න.
ටියුනලය සම්බන්ධ කරන්න, එකම පිටුසලකුණ විවෘත කරන්න, එවිට අනුමත අඩවිය කාර්‍යාලයේ සිට පිළිතුරු දුන් ආකාරයටම පිළිතුරු දෙයි. මෙය බොහෝ දුරස්ථ ප්‍රවේශ සැලසුම් නිහඬව රඳා පවතින උපකල්පනයයි, සහ වෙන වෙනම කරුණු තුනක් එකම වේලාවේ සත්‍යව පවතින තාක් පමණක් එය පවතී. ඒවායින් කිසිවක් VPN සේවාලාභියාගේ විශේෂාංගයක් නොවේ, කිසිදු DNS වාර්තාවකට ඒවායින් එකක්වත් සැපයිය නොහැක. ගෙදරදී පිටුසලකුණ අසාර්ථක වූ විට, හේතුව අස්ථානගත මාර්ගයක් වුවත්, අනුමත නොකළ පිටවීම් ලිපිනයක් වුවත්, එය වාර්තා කරන මූලාශ්‍රය ප්‍රතිස්ථාපනය කළ ප්‍රොක්සියක් වුවත්, බ්‍රව්සරය එක් සාමාන්‍ය දෝෂයක් පමණක් ලබා දෙයි. එම තුනම එකම ගැටලුවක් ලෙස සැලකීම නම් කුඩා ප්‍රතිපත්ති නිවැරදි කිරීමක් අනුමත ලැයිස්තු පුළුල් කිරීමේ සතියක් බවට පත්වන මාර්ගයයි.
සැබෑ කාර්‍යාල ජාලයක් සමඟ ස්පර්ශයට ඔරොත්තු දෙන නිර්මාණය උපකල්පනයට වඩා පටුය: පැහැදිලි පේළි තුනක තීරණ වගුවක්, මඟ හැරිය නොහැකි එක් බලාත්මක කිරීමේ ලක්ෂ්‍යයක්, සහ යමක් ඔප්පු කරන ප්‍රතික්ෂේප පරීක්ෂාවක්. උපකල්පනය ගලවා දැමීම මුලින්ම එයි, මන්ද ඉන් පසු සියල්ල රඳා පවතින්නේ කුමන ස්තරය මූලාශ්‍රය වැරදි ලෙස ඉදිරිපත් කරන්නේද යන්න දැන ගැනීම මතය.
මිථ්‍යාව: සම්බන්ධ වීම යනු මාර්ගගත කිරීම නොවේ
ටියුනලයක් ස්ථාපිත වේ, සහ සේවාලාභියා යම් පූර්ව නාම කට්ටලයක් සඳහා මාර්ග ස්ථාපනය කරයි. සම්බන්ධ වීම කරන්නේ එපමණයි. අසම්බන්ධ HTTPS ඉල්ලීමක් ටියුනලය හරහා ගමන් කරන්නේද, සහ පැමිණි විට එය කුමන පොදු ලිපිනයකින් පැමිණි බව පෙනේද යන්න පසුව වෙනත් අංග ගන්නා තීරණ වේ: මාර්ග වගුව මාර්ගය තෝරයි, පිටවීම මූලාශ්‍රය තෝරයි.
එබැවින් එකම ලැප්ටොප් පරිගණකය, එකම බ්‍රව්සර පැතිකඩ සහ එකම පිටුසලකුණ සමඟ කාර්‍යාලය සහ මුළුතැන්ගෙයි මේසය වෙනස් වේ. කාර්‍යාලයේදී ඉල්ලීම අඩවි නියාමකයා එකඟ වූ නඩත්තු කරන ලද පොදු ලිපිනයකින් පිටවේ. සම්පූර්ණ ටියුනලයකින් එය VPN පිටවීමෙන් පිටවිය හැක, එය වෙනත් ලිපිනයක් වන අතර කිසිවෙක් එය එකතු කරන තෙක් අනුමත නොකළ එකකි. බෙදුණු ටියුනලයකින් එය ටියුනලයට කිසිසේත් නොපිවිසිය හැක. එම මාර්ග තුනෙන් දෙකක් පමණක් කිසිදා අඩවි හිමිකරු සමඟ ගිවිසුමේ කොටසක් විය, තුන්වැන්න අමතර allow පේළියකින් පැලස්තර කළ යුතු දෝෂයක් නොවේ.
ඉල්ලීම් තත්ත්ව තුනක්, අනුමත පිටවීම් දෙකක්
ගිනිපවුරක් ස්පර්ශ කිරීමට පෙර න්‍යාසය ලියන්න, මන්ද වගුව යනු නිර්මාණයයි, රීතිය එහි එක් ක්‍රියාත්මක කිරීමක් පමණි. පහත ලිපින ලේඛන පරාස වේ; ඒවා ඔබේම නඩත්තු කරන ලද අගයන් සමඟ ප්‍රතිස්ථාපනය කර අඩවි හිමිකරුට පරීක්ෂා කළ හැකි තැනක තබන්න.
| Request path | Source the site sees | Intended decision |
|---|---|---|
| Office, no tunnel | Office public exit | Admit to the application login |
| Remote, approved full tunnel | Approved VPN egress | Admit to the same login |
| Remote, ordinary connection | Neither approved address | Deny at the network boundary |
මෙම සැලසුම් බොහොමයක් කැඩෙන්නේ මැද පේළියේදීය. වැදගත් වන්නේ බලාත්මක කරන උපාංගය දකින ලිපිනයයි, ලැප්ටොප් පරිගණකය ටියුනලය තුළ තබා ගන්නා පෞද්ගලික ලිපිනය නොවේ, එහි LAN ලිපිනයද නොවේ. 10.8.0.6 වැනි අගයක් පොදු අඩවියකට කිසිවක් අදහස් නොකරයි, 192.168.1.44 ද එසේමය. ටියුනල ලිපිනය යනු ටියුනලයේ ලිපිනකරණ විස්තරයකි, අඩවියට පරීක්ෂා කළ හැකි සුදුසුකමක් නොවේ.
ඔබේ VPN ට ස්ථාවර, ලේඛනගත පිටවීමක් ලබා දිය නොහැකි නම්, න්‍යාසයට වලංගු මැද පේළියක් නොමැති අතර කොපමණ අනුමත ලැයිස්තුවක් වුවද එකක් නිර්මාණය නොකරයි. එම මොහොතේ අවංක විකල්ප වන්නේ පැහැදිලි පෞද්ගලික මාර්ග හරහා ළඟා වන පෞද්ගලික අඩවියක්, නැතහොත් යෙදුම ඉදිරිපිට අනන්‍යතාව දන්නා ප්‍රවේශ ද්වාරයකි. දෙකටම පොදු අනුමත ලැයිස්තුවකට වඩා වෙනස් ගිවිසුමක් ඇත, දෙකම විගණකයෙකුට පැහැදිලි කිරීම වාසනාවෙන් ක්‍රියා කරන තෙක් වර්ධනය වූ ලැයිස්තුවකට වඩා පහසුය.
තීරණය ගන්නා තැනම මූලාශ්‍රය කියවන්න
සීමාව ඉල්ලීම අවසන් කරන උපාංගය මත තබන්න, වෙනත් මූල මාර්ගයක් එය මඟ හරින්නේ නැති බව තහවුරු කරන්න. Nginx ප්‍රවේශ මොඩියුලය allow සහ deny උපදෙස් පිළිවෙලට ඇගයයි, පළමු ගැළපීම ජය ගනී, සහ වට කරන කොටසකින් උරුම වූ රීති location තුළ තවදුරටත් බලපවත්වයි. එකම තැනක පටු allow එකක් ළඟ පළල් allow එකක් තිබීම සාමාන්‍යයෙන් අදහස් වන්නේ පළල් එක තීරණය කරන බවයි. එහි එක් පේළියක්වත් සංස්කරණය කිරීමට පෙර එම location සඳහා සම්පූර්ණ ඵලදායී වින්‍යාසය කියවන්න.
server {
listen 443 ssl;
server_name intranet.example.com;
set_real_ip_from 10.20.0.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;
location /app/ {
allow 203.0.113.24; # office public exit
allow 198.51.100.77; # approved VPN egress
deny all;
proxy_pass http://app_backend;
}
}පැටවුම් සමතුලිත කරන්නෙකු හෝ ප්‍රතිලෝම ප්‍රොක්සියක් පිටුපස එම රීතිය ප්‍රොක්සිය දකී, ඔබ එයට වෙනත් ලෙස නොකියන්නේ නම්. අමතන්නාගේ ලිපිනය ආධාරක විශ්වාසනීය-ප්‍රොක්සි ක්‍රියාවලිය හරහා පමණක්, ප්‍රොක්සි ලිපිනවල පැහැදිලි ලැයිස්තුවක් සමඟ ප්‍රතිස්ථාපනය කරන්න. අනුමත ලිපිනයක් යැයි කියන ඉල්ලීම් ශීර්ෂය අමතන්නා එය හිමිකර ගනී යැයි සාක්ෂියක් නොවේ, පොදු ශ්‍රාවකයක් මත වලංගු නොකළ යැවූ ශීර්ෂය අනුමත ලැයිස්තුව සැරසිල්ලක් බවට පත් කරයි.
පසුව අනෙක් ලිපින පවුල පරීක්ෂා කරන්න. IPv4 පමණක් ආවරණය කරන රීති කට්ටලයක් AAAA මතද පිළිතුරු දෙන ධාරක නාමයක් සඳහා අසම්පූර්ණ තීරණයකි, ක්‍රියාකාරී IPv6 ඇති සේවාලාභියෙක් ඔබ කිසිදා සමාලෝචනය නොකළ මාර්ගයකින් එම යෙදුමට ළඟා වේ.
බෙදුණු ටියුනලය: කිසිදා ඇතුළට නොඑන ඉල්ලීම
බෙදුණු ටියුනලයක් එහි ලැයිස්තුවේ ඇති පූර්ව නාම පමණක් ගෙන යයි. කාර්‍යාලයේ අභ්‍යන්තර උපජාල සාමාන්‍යයෙන් එම ලැයිස්තුවට එයි; පොදු වෙබ් අඩවියක් එන්නේ නැත. බ්‍රව්සරය නාමය විසඳයි, තෝරාගත් ලිපිනය මාර්ග වගුව සමඟ සසඳයි, එසේ වුවද ඉදිරිපිට පවතින දේශීය පෙරනිමි ද්වාරය සොයා ගනී.
එබැවින් ඉල්ලීම පරිශීලකයාගේ ගෘහ සම්බන්ධතාවයෙන් පැමිණ, ප්‍රතික්ෂේප වේ, වාර්තාව කියන්නේ VPN කැඩී ඇති බවයි, නමුත් ටියුනලය එය වින්‍යාස කළ කාර්‍යය හරියටම කරමින් සිටී. නිවැරදි කිරීම් දෙකක් නීත්‍යානුකූලය: එම ගමනාන්තය ටියුනලය හරහා යවා අනුමත පිටවීමට එය ගෙන යාමට ඉඩ දෙන්න, නැතහොත් අඩවියට සෘජුවම ළඟා වන බව පිළිගෙන දුරස්ථ පරිශීලකයන්ට ප්‍රවේශ ද්වාරය වැනි තවත් අනුමත මාර්ගයක් දෙන්න. ගෘහ ලිපිනයක් අහම්බෙන් ඇතුළත් වන තෙක් අඩවියේ පොදු අනුමත ලැයිස්තුව පුළුල් කිරීම ඉන් එකක්වත් නොවේ, එය නිර්මාණය බලාත්මක කළ යුතු මායිම ඉවත් කරයි. පළමු දෙක න්‍යාසය අවංකව තබා ගනී; තුන්වැන්න එයින් පේළියක් නිහඬව මකා දමයි.
ප්‍රතික්ෂේපය ඔප්පු කරන්න, පසුව ප්‍රතිසාධනය
වගුවේ සෑම පේළියකම සිටින සේවාලාභියෙකුගෙන් සැබෑ තීරණය ක්‍රියාත්මක කරන ඉල්ලීමක් සමඟ පරීක්ෂා කරන්න. අදාළ නොවන ලිපිනයක් පෙන්වන යම් පිටුවකට එදිනෙදා ළඟාවීමේ පරීක්ෂාවක් කිසිවක් ඔප්පු නොකරයි, මන්ද එම ගමනාන්තය යෙදුමට වඩා වෙනස් මාර්ගයක් ගත හැක.
curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'මායිමේ ප්‍රවේශ වාර්තාව වගුව අනාවැකි කී දෙය සමඟ සසඳන්න. පසුව ටියුනලය පහත හෙළා ප්‍රතික්ෂේප විය යුතු නව ඉල්ලීමක් කරන්න; දැනටමත් පූරණය වූ පිටුවක් හෝ දැනටමත් විවෘත සම්බන්ධතාවයක් කිසිවක් පරීක්ෂා නොකරයි. ප්‍රතික්ෂේපයක් නොපෙනේ නම්, බලාත්මක කිරීමේ ලක්ෂ්‍යය ඔබ සිතන තැන නොවේ.
ජාලයට ඇතුළත් කිරීමෙන් පසුවද යෙදුම් සත්‍යාපනය තබා ගන්න, මන්ද කාර්‍යාල පිටවීමක් සහ VPN පිටවීමක් එකක් බැගින් බොහෝ මිනිසුන් නියෝජනය කරන අතර කිසිවක් පුද්ගලයෙකු හඳුනා නොගනී. පරිශීලකයන් සඳහා උපදෙස කෙටියෙන් පවතී: අනුමත ටියුනලය ඔසවන්න, පසුව නැවත උත්සාහ කරන්න. එයම එක් URL එකක් පහසුවෙන් තබා ගන්නා අතර මූලාශ්‍ර රීතිය අනුමානයක් නොව තීරණයක් ලෙස පවතී.