یک نقطه پایانی VPN از طریق Squid: یک استثنای محدود CONNECT

Squid به یک درخواست CONNECT با نخستین خط http_access که مطابقت دارد پاسخ می‌دهد، و آن خط می‌تواند یک رد باشد. همین واقعیت توضیح می‌دهد که چرا یک استثنا برای نقطه پایانی VPN معمولاً در نخستین تلاش شکست می‌خورد، چون درخواست هرگز به اجازه‌ای که کسی در پایین افزوده است نمی‌رسد. یک اصلاح محدود نگهبان‌های موجود درگاه را حفظ می‌کند و به آن‌ها یک منبع، مقصد و درگاه بازبینی‌شده را می‌آموزد. بقیه چیزها روی پراکسی دقیقاً مثل قبل رفتار می‌کنند.

چگونه Squid درباره یک درخواست CONNECT تصمیم می‌گیرد

یک درخواست CONNECT یک میزبان و یک درگاه را نام می‌برد، و Squid خطوط http_access را به ترتیب می‌پیماید تا یکی از آن‌ها مطابقت کند. یک ردِ منطبق ارزیابی را بی‌درنگ پایان می‌دهد و کارخواه از پراکسی 403 دریافت می‌کند. به همین دلیل جایگاه یک قاعده از عبارت‌بندی آن مهم‌تر است. جابه‌جا کردن همان خط یک پله به بالا می‌تواند نتیجه را کاملاً تغییر دهد.

نگهبان‌های متعارف هر چیزی بیرون از Safe_ports را رد می‌کنند و CONNECT را بیرون از SSL_ports رد می‌کنند. این نام‌ها ACLهایی هستند که در پیکربندی خودتان تعریف شده‌اند، پس محتوای آن‌ها از آنِ شماست نه پروتکل. یک توزیع می‌تواند گستره وسیعی از درگاه‌ها را به‌عنوان Safe_ports مجاز کند و در همان حال CONNECT را جداگانه محدود کند. پیش از آنکه فرض کنید درگاهی بر اساس طراحی مسدود است، مقدارهای زنده را بخوانید.

تأیید کنید که پراکسی همان مؤلفه‌ای است که درخواست را رد می‌کند. یک 403 که Squid تولید می‌کند هیچ شباهتی به هشدار TLS از سرور VPN ندارد، و ادغام این دو در یک مشکل، ساعت اول را می‌بلعد. خط گزارش دسترسی مربوط به درخواست را بررسی کنید، چون هم کنش و هم قاعده‌ای را که آن را پدید آورده ثبت می‌کند.

به جای سه ACL جداگانه یک تطبیق ترکیبی بسازید

استثنا را از سه واقعیت بسازید: یک محدوده منبع تأییدشده، یک نشانی مقصد تأییدشده و تنها درگاهی که نقطه پایانی روی آن گوش می‌دهد. دو ACL جداگانه و یک تطبیق ترکیبی سیاست بسیار متفاوتی می‌سازند، چون آنچه ارزیابی می‌شود ترکیب است. ACL ترکیبی را بر پایه آنچه مجاز می‌کند نام‌گذاری کنید، نه بر پایه روشی که حمل می‌کند.

شکل زیر از محدوده‌های مستندسازی استفاده می‌کند که باید با مقدارهای بازبینی‌شده جایگزین شوند. Squid هیچ‌یک از این نام‌ها را رزرو نمی‌کند، پس انتخاب آن‌ها و نگه‌داشتنشان به‌صورت سازگار با شماست. این دستور کار به Squid 6 و 7 محدود است که پیکربندی مستندشان گروه all-of را پشتیبانی می‌کند. مرجع کنونی آن بخشنامه‌ها را در Squid 8 ناموجود می‌داند، پس با این مانند یک دستور کار وابسته به نسخه رفتار کنید نه یک مسیر مهاجرت، و پیش از اعمال، بخشنامه را با مرجع نسخه خودتان بررسی کنید.

acl pvpn_src src 192.0.2.128/25
acl pvpn_dst dst 198.51.100.77/32
acl pvpn_port port 1194
acl pvpn_ok all-of CONNECT pvpn_port pvpn_dst pvpn_src

گروه all-of تنها هنگامی مطابقت دارد که هر عضو مطابقت داشته باشد، یعنی منبع، مقصد و درگاه در یک خط بررسی می‌شوند. گروه به‌خودی‌خود چیزی نمی‌بخشد و درخواستی که تنها با دو مورد از سه واقعیت مطابقت دارد نمی‌تواند آن را برآورده کند. همین ویژگی استثنا را زمانی که کسی بعداً دروازه دومی می‌افزاید محدود نگه می‌دارد. یا مقصد تازه آگاهانه افزوده می‌شود، یا درخواست به نگهبان‌های اصلی بازمی‌گردد.

نگهبان‌های درگاه را خم کنید بدون آنکه بردارید

در جایگاه‌های کنونی‌شان، دو خط نگهبان متعارف چنین به نظر می‌رسند. آن‌ها معمولاً پس از احراز هویت و پیش از خطوط سیاستی که همه چیز را مجاز می‌کنند قرار دارند.

http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports

تطبیق ترکیبی نفی‌شده را به هر یک بیفزایید تا یک استثنای منطبق از نگهبانی که در غیر این صورت آن را رد می‌کرد جان سالم ببرد. تنها خطوط نگهبان تغییر می‌کنند، و هر یک فقط با یک شرط افزوده.

http_access deny CONNECT !SSL_ports !pvpn_ok
http_access deny !Safe_ports !pvpn_ok

شرط‌های یک خط دسترسی با هم ترکیب می‌شوند، پس خط اکنون تنها درخواست‌هایی را رد می‌کند که هم در بررسی اصلی و هم در استثنا شکست می‌خورند. درخواست برای نقطه پایانی تأییدشده عبور می‌کند و هر درخواست دیگری رفتار قدیمی درگاه را نگه می‌دارد. این باریک‌تر از افزودن درگاه به یک فهرست سراسری SSL_ports است، که آن درگاه را برای هر مقصدی مجاز می‌کرد. اگر درگاه از پیش در آن فهرست باشد، این ACL چیزی را تنگ نمی‌کند و اجازه قدیمی‌تر و گسترده‌تر همچنان برای مقصدهای دیگر برقرار است، پس پیش از ادعای اینکه استثنا درگاه را باز کرده، فهرست زنده را بخوانید. همچنین برگشت‌پذیر است، چون دو خط به شکل پیشین خود بازمی‌گردند. مرجع کنترل دسترسی ترتیب و نگهبان‌های متعارفی را که این تغییر به آن‌ها وابسته است مستند می‌کند.

جایی که استثنا نباید گذاشته شود

وسوسه این است که یک اجازه بالای نگهبان‌ها بگذارید و کار را تمام کنید. این جای‌گذاری همچنین از محافظت‌های احراز هویت و مقصد محلی که معمولاً نزدیک بالای یک پیکربندی کارآمد قرار دارند می‌گذرد. نتیجه یک استثنای محدود نیست، یک حفره با یادداشتی بالای آن است. هر اجازه تازه را در همان مرحله بازبینی‌شده‌ای نگه دارید که بقیه سیاست کارخواه در آن است.

بررسی کنید درخواست پس از نگهبان‌های درگاه هنوز به چه چیزی نیاز دارد. یک حساب احراز هویت‌شده، یک نشانی کارخواه مجاز و یک سیاست مقصد همگی همچنان اعمال می‌شوند و استثنا هیچ‌یک را تغییر نمی‌دهد. اگر پراکسی شما از پیش به حساب تأییدشده اجازه می‌دهد به مقصدهای دلخواه برسد، نگهبان درگاه هرگز کنترل واقعی نبوده است.

در نظر بگیرید که آیا نقطه پایانی اصلاً TCP است. یک استثنای CONNECT جریان‌های TCP را حمل می‌کند و نمایه OpenVPN که از UDP استفاده می‌کند از آن راه دسترس‌پذیر نخواهد شد. نمایه را تنها زمانی به TCP تغییر دهید که سرور به این شکل گوش می‌دهد و گرداننده تفاوت رفتار را می‌پذیرد.

مرز را با تجزیه‌گر و یک درخواست واقعی بررسی کنید

پیکربندی را پیش از بارگذاری دوباره تجزیه کنید و در این حین یک نشست دوم باز نگه دارید. یک خطای نحوی در زمان بارگذاری دوباره می‌تواند پراکسی را روی پیکربندی قدیمی بگذارد یا پیکربندی تازه را یکسره رد کند. تجزیه‌گر خط ردشده را گزارش می‌دهد، که بیش از چیزی است که خطای کارخواه به شما می‌گوید.

سپس دوباره بارگذاری کنید و یک CONNECT واقعی را از یک منبع تأییدشده از طریق پراکسی بفرستید. اجرای تجزیه‌گر نخست می‌آید، چون بارگذاری دوباره با یک غلط تایپی چیزی درباره سیاست به شما نمی‌آموزد.

squid -k parse
squid -k reconfigure
curl -v -p -x http://proxy.lab.internal:3128 https://vpn.lab.internal:1194/ --max-time 5

سه حالت را بیازمایید: منبع و حساب تأییدشده، منبع تأییدنشده، و مقصدی متفاوت روی همان درگاه. حالت سوم همان است که ثابت می‌کند استثنا محدود است، چون درگاه را بدون تطبیق مقصد می‌آزماید. برای هر سه گزارش دسترسی را بخوانید نه پیام کارخواه را. یک CONNECT موفق تنها یک جریان TCP برقرار می‌کند و نه بیشتر، پس دست‌دهی VPN یک آزمون جداگانه می‌ماند.