نام کاربری (USERNAME)

username daemon

تعیین کاربری که sniproxy با هویت آن اجرا خواهد شد. هنگامی که sniproxy با کاربر ارشد (سوپریوزر) راه‌اندازی شود، دسترسی‌های خود را به این کاربر کاهش می‌دهد.

فایل شناسه فرآیند (PIDFILE)

pidfile /var/run/sniproxy.pid

مسیر فایل PID را مشخص می‌کند؛ این دایرکتوری باید توسط کاربری که sniproxy با آن اجرا می‌شود قابل نوشتن باشد.

گزارش خطاها (ERROR_LOG)

error_log {
    syslog daemon
    priority notice
}

نحوه مدیریت پیام‌های خطا را تعیین می‌کند. پیام‌ها می‌توانند با استفاده از دستورالعمل syslog به لاگ سیستم ارسال شوند که مشخص می‌کند لاگ‌ها باید به کدام تسهیلات (facility) در syslog فرستاده شوند. متناوباً می‌توان با دستورالعمل filename مسیر فایلی را برای ذخیره لاگ مشخص کرد؛ این دو گزینه مانعه‌الجمع هستند. دستورالعمل priority مشخص می‌کند چه سطحی از شدت پیام‌ها باید ثبت شود. اولویت‌های پذیرفته‌شده همان اولویت‌های استاندارد syslog هستند که به ترتیب افزایش سطح جزئیات عبارتند از: emergency، alert، critical، error، warning، notice، info و debug.

گزارش دسترسی‌ها (ACCESS_LOG)

access_log {
    filename /var/log/sniproxy/access.log
}

نحوه ثبت گزارش اتصالات را مشخص می‌کند و می‌تواند در هر شنونده (listener) خاص بازنویسی شود. اتصالات پس از بسته شدن سوکت‌های کلاینت و سرور ثبت می‌شوند. دستورالعمل‌های syslog و priority می‌توانند همانند بخش error_log در اینجا نیز به کار روند.

تحلیل‌گر نام (RESOLVER)

resolver {
    nameserver 127.0.0.1
    mode ipv6_first
}

نحوه تفکیک و وضوح‌یابی پرس‌وجوهای DNS را مشخص می‌کند؛ این بخش تنها در صورتی لازم است که از نام‌های میزبان به عنوان آدرس در پیکربندی استفاده شود یا از بک‌اندهای الگو (wildcard) بهره گرفته شود. در صورت عدم تعیین، تنها پرس‌وجوهای IPv4 با استفاده از سرورهای نام پیش‌فرض سیستم انجام خواهند شد.

چهار حالت پشتیبانی می‌شود:

ipv4_only: پرس‌وجو برای رکوردهای A، استفاده از اولین رکورد A بازگردانده‌شده (به دنبال رکوردهای CNAME).

ipv6_only: پرس‌وجو برای رکوردهای AAAA، استفاده از اولین رکورد AAAA بازگردانده‌شده (به دنبال رکوردهای CNAME).

ipv4_first: پرس‌وجو برای هر دو رکورد A و AAAA، انتظار برای تکمیل هر دو استعلام، استفاده از اولین رکورد A در صورت وجود و در غیر این صورت استفاده از اولین رکورد AAAA.

ipv6_first: پرس‌وجو برای هر دو رکورد A و AAAA، انتظار برای تکمیل هر دو استعلام، استفاده از اولین رکورد AAAA در صورت وجود و در غیر این صورت استفاده از اولین رکورد A.

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

شنونده (LISTENER)

listener 192.0.2.10:80 {
    protocol http
    reuseport yes
    table http_hosts
    fallback 192.0.2.100:80
    bad_requests log
    source 192.0.2.10
    access_log {
        filename /var/log/sniproxy/http_access.log
    }
}
listener [::]:80 {
    protocol http
    ipv6_v6only yes
    table http_hosts
    fallback unix:/var/run/http_fallback_unix.sock
}

تعریف آدرس شنود برای پذیرش اتصالات جدید از کلاینت‌ها. آدرس‌ها می‌توانند به صورت یک مقدار IPv4 به همراه شماره پورت TCP، مقدار IPv6 به همراه شماره پورت TCP، یک شماره پورت TCP تنها، یا مسیر سوکت یونیکس با پیشوند ':unix' مشخص شوند.

دستورالعمل protocol مشخص می‌کند که درخواست کلاینت برای به دست آوردن نام میزبان درخواستی چگونه باید تجزیه شود؛ دو پروتکل http و tls پشتیبانی می‌شوند.

دستورالعمل reuseport تعیین می‌کند که پورت در حالت SO_REUSEPORT باز شود یا خیر، که این امکان را می‌دهد چندین نمونه از sniproxy روی یک جفت ip:port یکسان اجرا شوند. این قابلیت توزیع متوازن بار (load-balance) اتصالات ورودی را بین این نمونه‌ها بدون نیاز به پروکسی خارجی ممکن می‌سازد. به هسته لینوکس 3.9 به بالا نیاز دارد. تنظیم reuseport به "yes" این قابلیت را فعال می‌کند.

دستورالعمل ipv6_v6only کنترل می‌کند که آیا شنود روی آدرس همه مقاصد '::' در IPv6 اتصالات به هر آدرس IPv4 را نیز بپذیرد یا خیر. این مورد زمانی کاربرد دارد که کاربر پیکربندی متفاوتی برای IPv4 و IPv6 بخواهد یا تمایل داشته باشد ترافیک IPv4 را با سرور/پروکسی دیگری مدیریت کند. این فقط برای شنوندگان IPv6 قابل اعمال است و روی سایرین نادیده گرفته می‌شود.

گزینه table نام جدولی را مشخص می‌کند که برای یافتن این که اتصال باید بر اساس نام میزبان استخراج‌شده از درخواست اولیه کلاینت به کدام سرور فوروارد شود، به کار می‌رود. اگر جدول مشخص نشود، از جدول پیش‌فرض بدون نام استفاده خواهد شد.

دستورالعمل fallback سروری را مشخص می‌کند که در صورت عدم امکان تجزیه درخواست کلاینت، نیافتن سرور در جدول برای نام میزبان مشخص‌شده یا عدم امکان تحلیل نام میزبان به کار رود. این مقدار باید یک آدرس IP و پورت یا مسیر سوکت یونیکس باشد.

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

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

پیکربندی access log می‌تواند روی هر شنونده به صورت اختصاصی بازنویسی شود.

جدول هدایت (TABLE)

table http_hosts {
    ^example\.com$ 192.0.2.101
    ^example\.net$ 192.0.2.102
    ^example\.org$ 192.0.2.103 proxy_protocol
}

جدول‌ها نحوه نگاشت هر نام میزبان به یک سرور بک‌اند را مشخص می‌کنند. نام میزبان هر درخواست به ترتیب با رکوردهای جدول مقایسه می‌شود تا زمانی که تطابقی یافت شده و از آن سرور استفاده گردد. آدرس سرور می‌تواند IP، ترکیب IP و پورت، مسیر سوکت یونیکس، یک نام میزبان یا '*' باشد. در صورتی که پورتی مشخص نشود، از پورت شنونده‌ای که اتصال روی آن دریافت شده استفاده خواهد شد.

گزینه اختیاری proxy_protocol یک هدر پروتکل HAProxy PROXY v1 را به ابتدای اتصال پروکسی‌شده اضافه می‌کند و به وب‌سرورهای پشتیبانی‌کننده اجازه می‌دهد آدرس IP و پورت مبدا و مقصد اتصال TCP ورودی اصلی را به دست آورند.