iptables --uid-owner با سوکت‌های محلی Squid منطبق است، نه کاربران LAN
هنگام استدلال درباره خروجی Squid از معنای سازنده سوکت محلی --uid-owner استفاده کنید و بسته‌های LAN ارسال‌شده را جدا نگه دارید.
تطبیق owner در iptables می‌تواند بسته‌هایی را که سوکت یک فرایند محلی ساخته است شناسایی کند. برای نمونه، -m owner --uid-owner 1234 به سوکت محلی متعلق به UID 1234 اشاره دارد؛ نام کاربری پروکسی HTTP را شناسایی نمی‌کند.
روی ماشینی که Squid اجرا می‌کند، این مسیرها را از هم جدا کنید:
| ترافیک | تمایز مرتبط |
|---|---|
| یک کلاینت روی همین ماشین به Squid وصل می‌شود | اتصال ورودی به شنونده پروکسی |
| Squid اتصال مقصد را باز می‌کند | سوکت خروجی ساخته‌شده به‌صورت محلی |
| یک کلاینت LAN مستقیماً از این ماشین مسیریابی می‌کند | ترافیک ارسال‌شده بدون سوکت سازنده محلی |
این افزونه در OUTPUT و POSTROUTING معتبر است. بسته‌های ارسال‌شده برای این تطبیق سوکت محلی مرتبط ندارند، بنابراین قاعده FORWARD نمی‌تواند با پرسیدن UID مربوط به Squid کاربر رایانه دور را کشف کند.
پس سیاستی که سوکت‌های خروجی خود Squid را مجاز می‌کند تنها یک بخش از طراحی شبکه‌ای را پوشش می‌دهد که فقط بر پروکسی تکیه دارد. ارسال از طریق دروازه، دسترسی شنونده، سایر سرویس‌های مجاز و حساب واقعی سرویس پروکسی باید در محدوده مناسب خودشان رسیدگی شوند.
به‌جای فرض اینکه Squid با هویت nobody اجرا می‌شود، از هویت زمان اجرای پیکربندی‌شده استفاده کنید. چند فرایند می‌توانند یک UID را شریک شوند، پس مجوز مبتنی بر UID یک مرز حساب است، نه دلیلی بر اینکه یک فایل اجرایی مشخص همه اتصال‌های مجاز را ساخته است.