یک URL برای دفتر و VPN؟ چرا افسانهٔ فهرست مجاز شکست می‌خورد
اتصال 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 را راحت نگه می‌دارد در حالی که قاعدهٔ منبع تصمیمی می‌ماند نه حدسی.