د دفتر او VPN لپاره یو URL؟ ولې د اجازې لست افسانه ناکامه کیږي

ټنل وصل کړئ، هماغه بک مارک پرانیزئ، او اجازت لرونکی سایت په سمه توګه هغسې ځواب ورکوي لکه چې له دفتر څخه یې ورکاوه۔ دا هغه انګیرنه ده چې ډېری د لرې لاسرسي پلانونه پرې په چوپتیا تکیه کوي، او یوازې هغه وخت پاتې کیږي چې درې جلا شیان په یو وخت کې سم وي۔ له دې څخه هیڅ یو د VPN کلینټ ځانګړتیا نه ده، او هیڅ DNS ریکارډ نشي کولی له دې څخه یو هم برابروي۔ کله چې په کور کې بک مارک ناکام شي، براوزر تاسو ته یوه عمومي تېروتنه درکوي، که لامل ورکه لاره وي، یا ناسمه منل شوې وتلو پته، یا هغه پراکسي چې هغه سرچینه یې بدله کړې چې دا یې راپور ورکوي۔ د دې دریو د یوې ستونزې په توګه ګڼل هغه لاره ده چې یو کوچنی د تګلارې سمون د اجازې لستونو پراخولو یوې اونۍ ته اړوي۔

هغه ډیزاین چې د ریښتیني دفتر شبکې سره په تماس کې پاتې کیږي له انګیرنې څخه تنګتر دی: درې کرښیز روښانه پریکړه لړۍ، یو پلي کولو ټکی چې نشي کولی له پامه وتښتي، او یو د رد ازموینه چې یو څه ثابتوي۔ د انګیرنې ماتول لومړی راځي، ځکه چې له هغې وروسته هر څه په دې پوهیدو پورې اړه لري چې کومه طبقه سرچینه ناسمه وړاندې کوي۔

افسانه: وصلیدل لارښوونه نه ده

یو ټنل جوړیږي، او کلینټ د ځینو پری فکسونو لپاره لارې نصبوي۔ وصلیدل همدا څه کوي۔ ایا یوه بې اړیکه HTTPS غوښتنه د ټنل له لارې تیریږي، او کله چې ورسیږي له کومې عامې پتې څخه راغلې ښکاري، دا هغه پریکړې دي چې وروسته نور اجزاوې کوي: د لارو لړۍ لاره ټاکي، او وتل سرچینه ټاکي۔

له همدې کبله دفتر او د پخلنځي مېز د یوې لپټاپ، یوې براوزر پروفایل او یو بک مارک سره جلا کیږي۔ په دفتر کې غوښتنه د یوې ساتل شوې عامې پتې له لارې وځي چې د سایت چلوونکي پرې موافقت کړی۔ د بشپړ ټنل له لارې دا د VPN وتلو څخه وتلی شي، چې بېله پته ده او تر څو چې څوک یې اضافه نه کړي، ناسمه منل شوې ده۔ د ویشل شوي ټنل له لارې دا کېدای شي ټنل ته هېڅ ونه ننوځي۔ له هغو دریو لارو څخه یوازې دوه کله هم د سایت مالک سره د تړون برخه وه، او دریمه هغه نیمګړتیا نه ده چې په اضافي allow کرښې سره پټه شي۔

د غوښتنې درې حالتونه، دوه منل شوي وتل

د فایر وال د لمس کولو دمخه میټریکس ولیکئ، ځکه چې لړۍ ډیزاین دی او قاعده یوازې د هغې یو پلي کول دي۔ لاندې پتې د اسنادو سیمې دي؛ هغه د خپلو ساتل شوو ارزښتونو سره بدل کړئ او هلته یې وساتئ چې د سایت مالک یې کتنه وکړای شي۔

د دې پلانونو ډېری په منځنۍ کرښه کې ماتېږي۔ مهمه هغه پته ده چې پلي کوونکی وسیله یې ویني، نه هغه شخصي پته چې لپټاپ یې د ټنل په داخل کې ساتي او نه د هغې 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 اسانه ساتي په داسې حال کې چې د سرچینې قاعده د اټکل پرځای پریکړه پاتې کیږي۔